It's neat, but during my dabbling in web dev I've noticed that you can use basically <whatever>...</whatever> instead of divs, spans, sections, and it still mostly just works.
Aside from the spec wanting you to provide a schema, this is pretty much what xhtml aimed to do. The idea was that you could make the tags describe the content in them, and not have to rely on what's built into a common spec.
HTML is and always was very error tolerant though.
Its not simply styling, it goes beyond that. XML was/still intended to be the equivalent of JSON - just the data. With XSLT you created entirely new structure based on the underlying XML.
You don't have to do it that way. You can embed arbitrary foreign (but appropriately namespaced) XML into an XHTML document and style it with CSS, untransformed. Or, as the sibling comment says, you can even avoid XHTML and style pure XML directly.
Aria should be the source of truth, the list of things is much simpler and straight forward than html tags. They ARE made for accessibility and accessibility only, unlike html which at worst treat accessibility as an after thought and at best just another overloaded function of the mark up.
Even the Aria docs say you should rely on semantics and only use Aria for when that's not possible...
I'd much rather use a <button> that exposes itself as such and has well known interaction functions, then create my own div and have to handle the clicks, keyboard navigation, navigation shortcuts and so on... That actually requires a lot more knowledge than HTML semantics, and unless you test frequently with expert and non-expert assistive tech users, you won't know what kind of UX issues you'll be creating for them...
> They ARE made for accessibility and accessibility only
Sure, but have you ever used a screen reader? Support for aira markup is often limited and if you confuse things with semantically muddled HTML you're almost guaranteed to degrade accessibility.
The more basic and "standard" you can keep your HTML the less likely users using assistive technology will run into problems.
Aria is great, especially the basic stuff like aria-label, but where you can avoid using it you should.
I've worked on accessibility projects for years, treating aria as a source of truth or something that can be relied on isn't a good idea. We might get there eventually, but we're not there today.
Someone says “accessibility software is brittle” and your response is based on a “should”?
Great. Another developer that sees accessibility as another specs compliance fetishism exercise instead of actually being way to make things easier to use for more people.
specs compliance fetishism would be semantic web. The reason so much has been written on it is that it's so messy and practically people never get it right. HTML is so overloaded for multiple functions (content, logic, presentation and now accessibility), so is it really a surprise that it sucks at all of these?
Just my personal experience: If anyone remembers how hard it was to make things render consistently across IE and Netscape, the current situation with different screen readers is 1000x harder.
I mainly test with NVDA on the latest Firefox ESR on Windows 10. Something always breaks if I upgrade any part of this chain in my testing VM. Few months ago I spent many days to make abbreviations in a table header to be read correctly. I tried the abbr tag, abbr attribute, aria-label and many other possibilities and found a super hacky solution that involves hiding the expanded form with some css while exposing it to the screen reader. Then sometime after that I updated the Firefox. At the same day a colleague questioned why we needed all these hacks, and I wanted to show her how broken it was without my hack, but voila it had started working with the non-hacky, semantic way.
I have many stories like this.
I also do test with other configurations but just before releasing. VoiceOver (mac) is 80% there. JAWS Inspect is giving some colleagues headaches. None work 100% without breaking others, so the most popular stack decides how we implement things.
When I saw this post, I thought perhaps doing everything with spans and adding necessary attributes like role would be easier. Well nobody is passing something like that through a code review :)
I am pretty sure in the end accessibility will more likely be solved by some smart LLMs (with vision) interpreting arbitrary web pages on the user side, rather than by web developers coding it by hand. Because the latter obviously doesn't universally work.
I would pay money for a browser plugin that restyles every web page to a single readable/accessible design that I like. Think "Reader Mode" on steroids (that could transform arbitrary GUIs, not just blog posts).
As much as I work painstakingly to implement highly intentional design systems… the browser should be your “user agent.” If it can agentically interpret semi-structured data to help you, it’s entirely the user’s right to have the browser do that for them.
You can even make up your own tags, according to specific criteria, and they will been seen as spans.
Eg:
<my-dalek>EX-TER-MIN-ATE</my-dalek>
You can style them, including setting them as block level elements.
Where it can make life a lot easier is when you have a large number of nested divs. If you give the div's distinct names, it makes debugging/editing the source easier, which is probably required if you have that many divs.
Yes you can do that and it will work. But for future-proofing you should use tag names with a dash in them (like <foo-whatever>) to avoid colissions if html adds an official <whatever> element in the future. (The html standard promises to never add an element with a dash in its name)
Tag names with at least one hypen and two words either side are reserved for custom element use... with a few exceptions that I assume were part of the HTML/svg/mathml spec before the custom element registry.
You can 100% do this, invent your own tags, no need for React to have custom component names. And it works for styling with CSS, just use your custom tag as selector instead of css class. And then the classes can be used for shared styles.
Browsers have always been lenient towards errors in markup. Unknown elements would just be rendered as <p> or <span> (can't remember which).
Much later this was codified in HTML 5: if a browser doesn't know an element, it will render it as basically a span (that is, inline element with default styling IIRC).
And if you're lucky, your `<whatever>` might even get upgraded from "you're using the wrong tag for that purpose" to "now your tag is mostly correct" <i class="icon-cough"></i>.
I think that is both the basic point of and minimizes the interesting point of the website - the actual element doesn't matter, it's the things you can do with them.
Yeah, you could replace every single span on this page with almost any other HTML element and it'd work fine. But I guess onlylists or onlyh1s or onlybolds doesn't quite roll off the tongue as well.
It has role and aria attributes, so I think it actually isn't that bad. It's just `<span role="heading" aria-level="3">` is an awfully long way to spell out `<h3>`.
Screen readers are basically everything you hated about developing for IE6, but in an alternate world where there are 3 different IE6’s each of which works completely differently.
Three? Definition lists are read completely differently in Firefox, Edge, or Edge-in-IE-mode in Windows 11 Narrator. Multiply JAWS, NVDA, Narrator, VoiceOver, Orca, ChromeVox by Firefox, Chromium, IE, WebKit, Opera Mini. (Some of those combinations aren't possible, but 20 isn't an overestimate.)
Then realise: it's not just screenreaders. It's Braille displays, sip-and-puffs, Magnifier, High Contrast mode, keyboard navigation, speech recognition… Seemingly nobody tested any of it before they gave it to the end-user, so now it's your job, as the web developer, to make something that works.
Good luck! I recommend settling for "doesn't make it worse", since that's almost achievable.
I don't really know much about this area of UI. Can you explain why this breaks accessibility? I did load it in reader mode (macOS Safari), and there were no paragraph breaks - is that similar to the experience of a screen reader?
Screen readers know how to deal with common page elements. So they know how to announce and interact with page breaks, headers, lists, buttons, links etc.
If everything is a span, everything becomes just text.
It doesn't only apply to screen readers. Regular actions like keyboard navigation becomes broken. For example, on the page, you cannot tab between "click to expand" "buttons".
Indeed. Good accessibility benefits everyone, even the non-disabled people. And that's even before we start the whole discussion on how everyone will be disabled at one point or another in their lives and so on :)
Yeah, it' a sad state of things. Since there's no real money in screen readers, no one invests enough to make them better (e.g. to work with highly dynamic interfaces). Since they don't work in a lot of situations, people are disinclined to implement features that don't work well with screen readers. It's almost an impasse
This is basically what was happening late 90s and early 2000s, except with the div. ARIA didn't exist at the time so this presented a major accessibility issue. We now have ARIA, but the "use the right element" cargo cult persists [there's nothing wrong with this cargo cult - it just fits the definition, CSSing it up is just as functional sans older and possibly text browsers].
Edit: it's also where table got a bad rap (for a while table wasn't even used for tables, it was completely taboo). Using table for layout completely wrecked accessibility.
I don’t think it fits the definition of a cargo cult. It’s about convenience. I can use a <header /> and the screen reader announces it as such. I could do that with ARIA, but why put in the extra effort? To use a more gross example, I could make a div into a text input or even a form with contenteditable, a bunch of CSS I’d otherwise get out of the box, and a lot of JS. Yet it would require much more work.
The only thing I’ll grant you is that my first example’s benefit is a marginal difference, but there is a benefit nonetheless. It was also probably pushed as much for the screen reader benefit as it was for the ability to parse and extract information if I’m feeling cynical, but I digress.
Yeah, it was a big learning moment for me as a web developer when I learned that elements could be reshaped to function however you wanted, and none of their intrinsic properties were set in stone aside from content categories.
It's neat, but during my dabbling in web dev I've noticed that you can use basically <whatever>...</whatever> instead of divs, spans, sections, and it still mostly just works.
Aside from the spec wanting you to provide a schema, this is pretty much what xhtml aimed to do. The idea was that you could make the tags describe the content in them, and not have to rely on what's built into a common spec.
HTML is and always was very error tolerant though.
I think you're thinking about XML + XSLT transforming the domain XML into XHTML in the browser.
You can also attach a CSS to a XML document to specify how to present it. No need to touch XSLT.
Its not simply styling, it goes beyond that. XML was/still intended to be the equivalent of JSON - just the data. With XSLT you created entirely new structure based on the underlying XML.
The W3schools example is fairly decent https://www.w3schools.com/xml/xsl_intro.asp
Somehwhat similar to how component based JS frameworks work nowadays. Anyone who was using at a CSS equivalent was missing the point.
You don't have to do it that way. You can embed arbitrary foreign (but appropriately namespaced) XML into an XHTML document and style it with CSS, untransformed. Or, as the sibling comment says, you can even avoid XHTML and style pure XML directly.
So XML in truth then?
Accessibility will be absolutely destroyed though
Not if you are good with ur aria tags.
That's not true. Aria isn't a replacement for proper markup.
Accessibility software is rather brittle even when you do everything right. It's a bad idea to push it.
Aria should be the source of truth, the list of things is much simpler and straight forward than html tags. They ARE made for accessibility and accessibility only, unlike html which at worst treat accessibility as an after thought and at best just another overloaded function of the mark up.
Even the Aria docs say you should rely on semantics and only use Aria for when that's not possible...
I'd much rather use a <button> that exposes itself as such and has well known interaction functions, then create my own div and have to handle the clicks, keyboard navigation, navigation shortcuts and so on... That actually requires a lot more knowledge than HTML semantics, and unless you test frequently with expert and non-expert assistive tech users, you won't know what kind of UX issues you'll be creating for them...
> They ARE made for accessibility and accessibility only
Sure, but have you ever used a screen reader? Support for aira markup is often limited and if you confuse things with semantically muddled HTML you're almost guaranteed to degrade accessibility.
The more basic and "standard" you can keep your HTML the less likely users using assistive technology will run into problems.
Aria is great, especially the basic stuff like aria-label, but where you can avoid using it you should.
I've worked on accessibility projects for years, treating aria as a source of truth or something that can be relied on isn't a good idea. We might get there eventually, but we're not there today.
Someone says “accessibility software is brittle” and your response is based on a “should”?
Great. Another developer that sees accessibility as another specs compliance fetishism exercise instead of actually being way to make things easier to use for more people.
specs compliance fetishism would be semantic web. The reason so much has been written on it is that it's so messy and practically people never get it right. HTML is so overloaded for multiple functions (content, logic, presentation and now accessibility), so is it really a surprise that it sucks at all of these?
That's althe funny bit, despite aria, I found in testing that some tags still behave differently with screen readers.
Just my personal experience: If anyone remembers how hard it was to make things render consistently across IE and Netscape, the current situation with different screen readers is 1000x harder.
I mainly test with NVDA on the latest Firefox ESR on Windows 10. Something always breaks if I upgrade any part of this chain in my testing VM. Few months ago I spent many days to make abbreviations in a table header to be read correctly. I tried the abbr tag, abbr attribute, aria-label and many other possibilities and found a super hacky solution that involves hiding the expanded form with some css while exposing it to the screen reader. Then sometime after that I updated the Firefox. At the same day a colleague questioned why we needed all these hacks, and I wanted to show her how broken it was without my hack, but voila it had started working with the non-hacky, semantic way.
I have many stories like this.
I also do test with other configurations but just before releasing. VoiceOver (mac) is 80% there. JAWS Inspect is giving some colleagues headaches. None work 100% without breaking others, so the most popular stack decides how we implement things.
When I saw this post, I thought perhaps doing everything with spans and adding necessary attributes like role would be easier. Well nobody is passing something like that through a code review :)
I am pretty sure in the end accessibility will more likely be solved by some smart LLMs (with vision) interpreting arbitrary web pages on the user side, rather than by web developers coding it by hand. Because the latter obviously doesn't universally work.
I would pay money for a browser plugin that restyles every web page to a single readable/accessible design that I like. Think "Reader Mode" on steroids (that could transform arbitrary GUIs, not just blog posts).
In the end? Maybe.
What about the people who can't use the web now?
> I would pay money for a browser plugin that restyles every web page to a single readable/accessible design that I like.
Sometimes designs you don’t like are intentional.
As much as I work painstakingly to implement highly intentional design systems… the browser should be your “user agent.” If it can agentically interpret semi-structured data to help you, it’s entirely the user’s right to have the browser do that for them.
Except Chrome doesn’t support user-stylesheets - which is an outrage (even Internet Explorer supported them).
I shouldn’t need to author my own Chrome extension just to set a minimum font-size on pages or disable fixed background images over remote-desktop.
Stylus is quite effective for this!
https://chrome.google.com/webstore/detail/stylus/clngdbkpkpe...
Add your styles to Custom.css in the "User StyleSheets" folder of your profile path. No extension authoring needed.
This doesn't seem to be documented anywhere - all of the mentions I find about this date from around 2013-ish.
There's nothing about it in Chrome's help site either: https://support.google.com/chrome/search?q=user+stylesheet&f...
https://support.google.com/chrome/search?q=Custom.css
hmm, when I get a chance I'll check that it still works, it's not something I still use and you're right that it's not documented
I’m sure they are, but that doesn’t mean they’re good or will work well for me
Interesting idea, and I’d think mostly only limited by cost/speed per token currently
A custom name like <whatever> is not any worse than <span> - both are semantically neutral.
You can even make up your own tags, according to specific criteria, and they will been seen as spans.
Eg:
<my-dalek>EX-TER-MIN-ATE</my-dalek>
You can style them, including setting them as block level elements.
Where it can make life a lot easier is when you have a large number of nested divs. If you give the div's distinct names, it makes debugging/editing the source easier, which is probably required if you have that many divs.
It actually 100% works, just with the caveat that those elements receive display: contents by default.
Yes you can do that and it will work. But for future-proofing you should use tag names with a dash in them (like <foo-whatever>) to avoid colissions if html adds an official <whatever> element in the future. (The html standard promises to never add an element with a dash in its name)
Just to note the reasoning why they've promised that because I thought it was kinda interesting:
https://html.spec.whatwg.org/multipage/custom-elements.html#...
Tag names with at least one hypen and two words either side are reserved for custom element use... with a few exceptions that I assume were part of the HTML/svg/mathml spec before the custom element registry.
You can 100% do this, invent your own tags, no need for React to have custom component names. And it works for styling with CSS, just use your custom tag as selector instead of css class. And then the classes can be used for shared styles.
When I was 12, I invented my own tag called <t> (I wanted something with no default styling but I didn't know how to do it).
What year was that? The custom tags thing used to have a lot more problems than it does now.
Browsers have always been lenient towards errors in markup. Unknown elements would just be rendered as <p> or <span> (can't remember which).
Much later this was codified in HTML 5: if a browser doesn't know an element, it will render it as basically a span (that is, inline element with default styling IIRC).
Up to IE7, non-standard elements couldn't be styled without a shiv.
My memory doesn't extend that far back :) Even though I've been "in the biz" since early 2000s
And if you're lucky, your `<whatever>` might even get upgraded from "you're using the wrong tag for that purpose" to "now your tag is mostly correct" <i class="icon-cough"></i>.
I think that is both the basic point of and minimizes the interesting point of the website - the actual element doesn't matter, it's the things you can do with them.
And you often don't even need a closing tag
Yeah, you could replace every single span on this page with almost any other HTML element and it'd work fine. But I guess onlylists or onlyh1s or onlybolds doesn't quite roll off the tongue as well.
only<em>s?
onlysubs?
onlyslots?
onlymarquees
I honestly miss them
And this https://imgur.com/2gF1cfl is how all those <spans> look in Reader mode.
Utterly broken in terminal-based browsers as well.
This is fun to see as an experiment but hopefully nobody does this in real life. This breaks accessibility, reader mode, screen readers, etc.
It has role and aria attributes, so I think it actually isn't that bad. It's just `<span role="heading" aria-level="3">` is an awfully long way to spell out `<h3>`.
Theory and practice hardly even exchange notes, when it comes to digital accessibility.
Screen readers are basically everything you hated about developing for IE6, but in an alternate world where there are 3 different IE6’s each of which works completely differently.
Three? Definition lists are read completely differently in Firefox, Edge, or Edge-in-IE-mode in Windows 11 Narrator. Multiply JAWS, NVDA, Narrator, VoiceOver, Orca, ChromeVox by Firefox, Chromium, IE, WebKit, Opera Mini. (Some of those combinations aren't possible, but 20 isn't an overestimate.)
Then realise: it's not just screenreaders. It's Braille displays, sip-and-puffs, Magnifier, High Contrast mode, keyboard navigation, speech recognition… Seemingly nobody tested any of it before they gave it to the end-user, so now it's your job, as the web developer, to make something that works.
Good luck! I recommend settling for "doesn't make it worse", since that's almost achievable.
I don't really know much about this area of UI. Can you explain why this breaks accessibility? I did load it in reader mode (macOS Safari), and there were no paragraph breaks - is that similar to the experience of a screen reader?
See this short section on semantic html: https://developer.mozilla.org/en-US/docs/Glossary/semantics#...
Screen readers know how to deal with common page elements. So they know how to announce and interact with page breaks, headers, lists, buttons, links etc.
If everything is a span, everything becomes just text.
It doesn't only apply to screen readers. Regular actions like keyboard navigation becomes broken. For example, on the page, you cannot tab between "click to expand" "buttons".
And so on and so on :)
In case someone happens to read my comment down here, I just want to highlight
> actions like keyboard navigation becomes broken
is also an accessibility issue. Not everyone can use a mouse. Keyboard navigation should be the easiest possible thing to test and ensure works…
Indeed. Good accessibility benefits everyone, even the non-disabled people. And that's even before we start the whole discussion on how everyone will be disabled at one point or another in their lives and so on :)
> Good accessibility benefits everyone, even the non-disabled people.
…until features start getting killed because they can’t be made to work well on screen readers. I’ve seen it happen and it strikes me as unfortunate.
Yeah, it' a sad state of things. Since there's no real money in screen readers, no one invests enough to make them better (e.g. to work with highly dynamic interfaces). Since they don't work in a lot of situations, people are disinclined to implement features that don't work well with screen readers. It's almost an impasse
This is basically what was happening late 90s and early 2000s, except with the div. ARIA didn't exist at the time so this presented a major accessibility issue. We now have ARIA, but the "use the right element" cargo cult persists [there's nothing wrong with this cargo cult - it just fits the definition, CSSing it up is just as functional sans older and possibly text browsers].
Edit: it's also where table got a bad rap (for a while table wasn't even used for tables, it was completely taboo). Using table for layout completely wrecked accessibility.
I still see a lot of fresh React/Vue code that is all divs with onclick handlers.
I don’t think it fits the definition of a cargo cult. It’s about convenience. I can use a <header /> and the screen reader announces it as such. I could do that with ARIA, but why put in the extra effort? To use a more gross example, I could make a div into a text input or even a form with contenteditable, a bunch of CSS I’d otherwise get out of the box, and a lot of JS. Yet it would require much more work.
The only thing I’ll grant you is that my first example’s benefit is a marginal difference, but there is a benefit nonetheless. It was also probably pushed as much for the screen reader benefit as it was for the ability to parse and extract information if I’m feeling cynical, but I digress.
This is one massive blob of text in reader mode. No line breaks show up.
Is there a practical application for this?
> External scripts can be fetched and evaluated using `eval`
No! `eval` has some legitimate use cases, but generally should be avoided:
https://www.digitalocean.com/community/tutorials/js-eval#rea...
Tho I get the onlyfans reference, why not only <u>?
I'm disappointed the author didn't use a Monty Python Spam Sketch reference — span, span, span, span and span.
lol, I enjoyed this greatly. Ended up spending the last hour making my own version of this site. Thoroughly enjoyed.
This spiritually equivalent to tailwind
Yeah, it was a big learning moment for me as a web developer when I learned that elements could be reshaped to function however you wanted, and none of their intrinsic properties were set in stone aside from content categories.
See also: https://stackoverflow.com/questions/30062864/where-do-the-bu...