Comment by kqp
1 day ago
This is going to be unpopular here, but life became easier when I quit trying to write semantic HTML. It’s just poorly designed, I’m sorry. Every time I’ve reached for a <dl> I’ve eventually regretted it because I wanted multiple levels of wrappers, or a divider between sections, or an icon, or a heading spanning multiple key-value pairs, etc. They make this stuff with some flexibility but nowhere near enough to actually cover the generalized concept it purports to. I still use the corresponding elements when there are observable benefits, of course, like <button>, <h1>, etc, but when all it’s going to do is not quite fit the data model and force me to override everything, it’s just not a practical choice.
It shouldn’t be so controversial to say that if 99% of usage routes around your API, it’s probably the API’s fault.
As a person who daily drives a screen reader, I so agree with this.
We'd all be better off if the W3 dispensed with all that ideological semantic purity BS and started doing more realpolitik. Think not about whether your API is semantically pure, but about what developers want to do, what hacks they'll use to achieve their goals despite your objections, and how to enable doing those things in a way that is maximally beneficial to everyone involved.
ARIA live regions are the perfect example. What developers actually want is `document.speakText`. What developers actually have is a weird API that announces text on the page as it changes. They have to bridge from one to the other, which is difficult and hacky, even when implemented well. But hey, at least that live region approach is semantically pure HTML...
I don't want that. I don't want to care about screen readers (unfortunately I have to). I want a system where I can pick well-defined rules and then css can style it, screen readers will understand it, automations can parse it, keyboard navigation is free.
Obviously thats not what we got, but I feel like the set of established UI patterns is manageable enough that it could be built.
A great example is the new <select> styling that developers styled in all kinds of creative ways. Now give me that for comboboxes, trees, data-grids etc...
There are already well-defined rules, you just don't like some of the rules, e.g. you can't (today) style <select> options. Keyboard navigation is free as long as you follow the rules about which elements are focusable.
You shouldn't have to care about screen readers the same as you shouldn't have to care which browser someone uses but you always have to care about people; people who can't see or hear what you create, people who can operate a keyboard (or keyboard-equivalent) but not a mouse or touchscreen, people who can use a touchscreen but not a physical keyboard, etc.
Good news! `.ariaNotify()` is basically a real implementation of your hypothetical document.speakText.
https://developer.mozilla.org/en-US/docs/Web/API/Element/ari...
Cool, waiting for browsers to pick it up nice and green
Sounds like it's CSS' fault then. I think that just like they introduced `display:contents` to remove wrappers, they should also introduce a way to group elements as if they had a common ancestor.
Proposal from 2016 (closed): https://github.com/w3c/csswg-drafts/issues/588
Seems the original ::contents proposal is where it's at now, though there hasn't been action on it for some time. Not sure if they hit a snag or it's just on the back burner
https://github.com/w3c/csswg-drafts/issues/2406
This proposal has the benefit of not violating the tree structure should multiple :wrap rules apply to overlapping elements.
With CSS Grid math you can fake it, at least. If your DL is `display: grid;` and if you have a few extra DIVs lying around at the bottom of the DL to be borders around combined cells you just have to math which rows/columns you want to draw a border around and make the div fit that combined shape.
Good idea. Together with ::after / ::before and content: (which can insert text into the website) it might then be possible to create a website without any HTML, only CSS.
I feel similarly about HTTP. The protocol maps really well to resource stores (stuff like S3). GET, PUT, DELETE all make sense. HTTP status codes are built exactly for this use case as well. But as web developers we're mostly not developing resource stores. Those are highly generic and can be built once and used by millions of apps. Most of the time someone is writing code that interacts with HTTP they are performing RPC. You can go for GraphQL, gRPC, or many other RPC systems that just shirk the whole thing. They make everything use a POST to a single endpoint and add another layer of abstraction so you don't need to return a 4XX/5XX error for some highly application-specific situation.
It's clear the RFC writers got a little out of hand. "402 Payment Required", "407 Proxy Authentication Required", "508 Loop Detected" look to me like attempts to work in functionality specific to certain types of apps or deployments. Why do these RFC authors get their specific needs implemented into the bedrock of the web and then expect me to find where my needs happen to overlap and then tuck every aspect specific to my app into "400 Bad Request" or "500 Internal Server Error"? Every time I see a web app actually utilize more than the bare minimum of HTTP status codes I roll my eyes. Put that shit into the application layer. The protocol wasn't made for you. It was made for LAMP-stack apps serving mostly static assets.