I need to learn more about web accessibility, but if you completely ignore it (and other sane practices) HTML looks really simple.
I think the design of HTML is just too much. There’s so many tags that don’t do much. It’s like w3c decided that any common thing people use in websites needs a tag. The end result is more and more tags…
Can anyone convince me otherwise? It screams design red-flags to me.
PS: I love the web and think it’s the best platform and future platform we have at the moment. It’s just quirky and loves not breaking old websites!
lol, you should actually read the HTML spec, there are good explanations of all the elements. The whole point of defining semantics is that elements have meaning independent of their default appearance (or any appearance).
> I need to learn more about web accessibility, but if you completely ignore it (and other sane practices) HTML looks really simple.
Everything looks really simple when you ignore vast amounts of the subject and nuance.
Your rules don't mention keyboard or focus behavior, the only mention of either is the association between <label> and its <input>. <output> does have functionality, it's an HTML-native ARIA live region (that can be associated with a <label>).
Oh that’s great. It’s an opinionated view that focused strictly on the behavior of the tags wrt layout and appearance.
I’ve noticed that discussions of semantic meaning of tags often contain the word “feel.” Nothing wrong with that, taste matters, but it does point to the non-functional goals that are being pursued when people disagree.
<ol> vs <ul> - they are both ordered, because markup is ordered. One gets decorated differently than the other by default. Is the difference semantic or typographical?
A <ul> is a list of things whose order makes no difference to its meaning. Rearranging a <ul> would change the presentation, not the information. Rearranging an <ol> would change both.
<ul> Players
<li> Alice
<li> Bob
<li> Carol
</ul>
<ol> Leaderboard
<li> Bob
<li> Alice
<li> Carol
</ol>
HyperText Markup Language is semantic. You're marking up a document to show what information it contains, where it contains it, and how it relates to other documents or information. Reading markup causes browsers to display things, but that's incidental.
In theory.
In practice, no one cares about semantics and the choice of tags is based on how a target set of browsers happens to display them.
Your question about who interprets markup is exactly right. In theory, you have no idea. Maybe it's a browser, maybe it's assistive software, maybe it's a browser printing, maybe it's some custom knowledge base with different views of documents for different users. In theory, you're supporting all of that by only marking up semantics and allowing the consumer to interpret them, because there isn't one right answer.
In practice, your client is Chrome.
In theory, that's irrelevant because you're using CSS to style semantic markup so it works in Chrome and still makes sense to other clients.
In practice, you're writing a web application, using a framework, and nothing in the stack wants you to do that.
I dunno, I guess I’m a caveman. If it looks right and works (including accessibility) then I figure I’m pursuing something that doesn’t matter a lot.