alexpetros
Joined 4 years ago
Karma
432
Submissions
87
Member since
Apr 20
Recent submissions
Comment · 13 days ago
option+shift+dash, baby: https://github.com/alexpetros/dotfiles/blob/2f3fb68add60cdd1...
Comment · 3 months ago
Totally, this is part of the problem I'm trying to solve. I wrote a little about these "call to action links" that you're describing in the proposal.[0] The tl;dr is that I think it would be easier to hold the line that "links should look like links" if we supported the legitimate use cases for navigating with buttons.
I would love more feedback from the accessibility engineering community so please look up my email or comment on the proposal if you think I've missed something.
[0] https://triptychproject.org/proposals/button-actions#what-ab...
Comment · 3 months ago
> Cancel doesn't navigate. In fact, neither of them do.
This is correct. The point of the proposal is that you should be able to implement this pattern with just navigations, and that implementing it differently doesn't change the user semantics.
> If you've taken the twenty lines of css to make a button look like anything other than the default browser styles, you can add the two lines of progressive enhancement JavaScript to handle space.
One important stakeholder for the proposal is governments and other websites that care about building accessible web experiences that work without JavaScript enabled. There are also many differences in the behaviors that can't be rectified with JavaScript (some examples are in the original article as well as the linked proposal).
Comment · 3 months ago
What if I want the cancel button to be to the left of the submit button? This is how GitHub lays out those buttons, for instance. There's fundamentally no reason why a button's functionality should be dictated by its position on the page.
The proposal has an in-depth explanation of why this and other workarounds (like using the `form` attribute and a bunch of dangling forms) aren't sufficient.[0]
[0] https://triptychproject.org/proposals/button-actions#existin...
Comment · 3 months ago
I'm not entirely sure what you mean by "in-between" element, but that's not what this proposal does. This proposal simply augments the button's existing ability to navigate the current context by removing the need to wrap it in a form. This is useful because sometimes buttons are already the right semantic element to use, but you can't use them to do this without JavaScript.
Also, that link has a lot of wrong information and is not an official W3C site. It even has a LinkedIn page.[0]
Comment · 3 months ago
You linked to `formaction`, which allows buttons to control the action of their nested form. This proposal allows buttons to make actions independent of forms, and the blog has an example of how independent button actions compose nicely with the existing `formaction` and `formmethod` controls.
Comment · 3 months ago
> And that's partially because "Cancel" is pretending you're in a desktop app with desktop idioms. No real, actual person designs websites like this.
If I click "Edit" on a GitHub comment, it shows me two buttons, "Cancel" and "Update Comment." Patterns like this can be found all over the web on sites you certainly use.
> There's functionally no reason to do this. It doesn't add anything for the user, it only takes things away in the name of making it feel "more native".
There are many functional differences between buttons and links and it's not true that links are strictly more capable. Buttons, for instance, can be activated with the spacebar.
> I've been building websites for 25 years and I've literally never had this problem.
I included a link that showcases how this problem exists both in Django itself and for developers who build websites with Django.[0] This is representative of a durable, hypertext-driven, webapp design that the proposals are intended to support.
[0] https://www.djangoproject.com/weblog/2026/jul/15/supporting-...
Comment · 3 months ago
> This seems to conflate appearance with semantics. If an element causes a navigation, I make it a link.
Neither of my examples work with links. Logout buttons must be buttons because they trigger unsafe requests, and "search" buttons are buttons because they submit the form as a query parameter. Both of these examples, are, however, navigations.[0]
> Whether it looks like a button is irrelevant, that’s CSS.
It's not irrelevant, because even if you style a link like a button (or vice versa), it will still behave like the thing it actually is. That's why it's important to have native HTML behavior that lets people use the right semantic element.
[0] https://html.spec.whatwg.org/multipage/browsing-the-web.html...
Comment · 5 months ago
Thank you!
Comment · 5 months ago
I'm not as familiar with Magic, but I've always been curious if that community has tooling at a comparable level of maturity to Pokemon Showdown.
Comment · 7 months ago
For what it's worth, I think that an embedded DSL to represent most expressions tersely is a worthwhile idea to explore—it's just a more expensive one. That's a cost-effective choice at a some levels of resourcing, but not every level of resourcing.
Comment · 7 months ago
In the blog I link to a Prolog post I wrote in January because I am very interested in the possibility of using Prolog to prove things about the Fact Graph. I have a personal branch where I try to build some tools for it with DCGs. The nice thing about XML is that I can easily explore it as Prolog terms with committing the entire project to Prolog.
Comment · 7 months ago
In the context of the article, "cheap" means "easy to set up" not "computationally efficient." The article is making the argument that there are situations in which you benefit from sacrificing the latter in favor of the former. You're right that it's annoyingly slow to parse though and that does cause issues I'd like to fix.
Comment · 7 months ago
This is a good question! We do it, it works, and it's definitely an advantage of XML over alternatives. I just personally haven't had the time to dig in and learn it well enough to write a blog post about it. In practice I think people update the Fact Dictionary largely based on pattern matching, so that's what I focused on here.