Discussion
It’s kinda sad thad smolweb.org Adële put so much work into smolweb LLM skill, with actually readable and actionable data on smolweb buried among the heaps of AI dung. Like, you could make it a JSON or s-expressions so that everyone benefits from this machine-readable data, but no, it’s AI-ified Markdown shit.
I’m disappointed.
It’s also discouraging because smolweb.org is an extremely sane and kind type of standard! Many other alternatives like Gemini <https://aartaka.me/gmi-a11y.html> and @h3rald ‘s SubWeb (mentioning for fairness) are not really concerned with Accessibility nor semantics. smolweb balances stuff really well… unless it’s AI that’s not kind in any imaginable way.
@aartaka well... for SubWeb, that's where the simplicity of it comes into play: I wanted something more expressive than Gemini but that could remain simple and work in browsers like Dillo (which AFAIK doesn't provide much accessibility support).
The point is: aria-* attributes, tabindex, etc. are not explicitly forbidden by the spec, you can definitely use them, but they are not mandatory.
That goes back to the whole issues in whether to list all *allowed* attributes and elements in the SubHTML spec. For now I just listed mandatory and recommended ones, for simplicity's sake.
And again, simplicity and lack of browser support are the main reason why I am against semantic elements: a div with a class works just fine, you don't have to learn the semantics of aside vs section etc.
@h3rald kinda fair, yeah. This one, however, is contradictory:
> And again, simplicity and lack of browser support are the main reason why I am against semantic elements: a div with a class works just fine, you don't have to learn the semantics of aside vs section etc.
Semantic elements are almost fully gracefully degrading and working everywhere even without explicit support (ignoring the block vs. inline display for now.) _However_, wherever they work, they add another useful dimension (semantic, duh) to the page. That’s a clear win in my book—you don’t need to support anything extra but get nice things if you do. Simple and useful.
I’m coming from the scraping background, so I do care about how a machine (in the most forgiving and benign interpretation, of course) perceives the page and extracts the information from it. Screen readers are “machines” too, for me. Semantic elements are important, because they enable easier processing and (again, in my broad interpretation) bigger net benefits for humanity.
A concrete use-case I long to implement for a long time now: parsing <nav>-s and presenting them as an Omnibar™-type menu instead of whatever the web designer made them look like. With fuzzy search and all. This use-case would be impossible to implement if there weren’t <nav>-s—heuristically parsing the page to guess where the navs are is… not trivial.
<main> is a huge help in fulltext extraction akin to what FullTextRSS does, while <section> is the basic block for structured TOC creation (headings are purely linear, so it’s not enough information.)
But I digress. Just that I care about these semantics as both an a11y person and parsing kid.
@aartaka Hmm OK, point taken. Maybe the whole semantic subset deserves a dedicated section explaining how to deal with them. The biggest problem right now is that Dillo & older browser will render unknown/unsupported elements like section or aside as inline elements. I am not sure if this can be fixed via CSS though, so as long as you provide appropriate CSS to say "hey, this is a block-level element", then we are probably OK.
The key for me is that semantic elements are not *mandatory* and maybe not even *recommended*, but they could be *allowed* if you can make sure that Dillo or a similar browser renders them correctly.
And believe me, I debated a bit even about em/strong (which are listed as part of the SubWeb spec) vs i/b (they are not listed. I get the nuance but I wanted to keep things simpler) -- in these cases, even though <span class="emphasis"> could technically work instead of em... well, that's just weird. 😉
@h3rald interestingly enough, Dillo renders these as block for me. w3m doesn’t, to be perfectly fair.
Styling of “unknown” elements is inconsistent across browsers, despite it being standard since… some time ago? But hardcoding block vs. inline elements and ignoring the rest is an implementation strategy, so no blaming from me.
I’m kind of indecisive. If we’re putting the burden on the web designer, then yeah, make them wrap things into additional <div>-s. If we’re putting the burden on implementor, then just make them add five more names to the list of block elements. I believe that the latter is more productive and easiest for everyone.
Compatibility with older browsers is a good point, but, like, security conflicts with that. Older browsers are not safe by definition, so if they cannot add five more constants, they likely are dead and dangerous to use. Yeah, I know, not a perfect heuristic. But it’s close enough.
@aartaka @h3rald For me the real issue is lack of awareness of and care for accessibility issues. In a universe where 90% or more of both developers and users judge a page by its visual appearance and nothing else, accessibility just won't happen. You can't enforce it via lower-level markup language semantics unless there is a real diversity of clients AND users whose interests intersect only in the realm of semantics.
@aartaka @h3rald The idea of separating semantics from presentation is as old as document markup languages and has consistently failed. People always find something that the formal semantics don't cover, and lift it into the presentation layer. And then they go meta and describe their presentation conventions in their documents ("in the following, the questions I reply to are displayed in green"). Unless they get negative feedback on such practices, they will continue.
Install bonfire.cafe
Get the full app experience
