3 ms·
Well, that was what HTML was on track to give us. But once JS and CSS were introduced, semantic HTML that was actually semantic stopped developing, under the as
by kerkeslager 4y ago
Well, that was what HTML was on track to give us. But once JS and CSS were introduced, semantic HTML that was actually semantic stopped developing, under the assumption that if someone needed, for example, a tab area or slide show, they could develop those themselves with CSS/JS. What we've gotten instead is extremely vague elements like "section" that don't communicate what the elements are.
If HTML were truly semantic, browsers could implement accessibility features around it, but because they're so vague, there's no real way for browsers to do that, which offloads the responsibility onto web developers, who in most cases aren't granted budget to do it. There are a handful of features such as alt properties, but these are pretty limited.
So yeah, HTML should give us that, but that's part of what users gave up when we decided it was acceptable to allow random websites to run code on our machines and tell us how our content should be displayed.
- singpolyma3 4y agoI agree with you, but also I think the section tag is one of the biggest leaps forward we've had. Putting an id on a whole section instead of a name= crap for references, and actually using nesting for hierarchy. All the HTML5 input types are also an example of semantics impriving. It could be way better, but it's not a total stalemate
- kerkeslager 4y ago> I agree with you, but also I think the section tag is one of the biggest leaps forward we've had. Putting an id on a whole section instead of a name= crap for references, and actually using nesting for hierarchy. How does this differ from how <div> was being used before? I've switched to using <section> simply because it's a better name, but I'm not sure it's made any meaningful difference in my code. Another example of the pointlessness of this issue is <em> and <strong>. I've rarely seen code where these weren't used exactly the same as <i> and <b> were before. In rare cases, I've seen someone do something like make <em> a different color rather than italic, and that's almost always been a bad idea, because when HTML authors use <em> they almost always intend for it to be italic. In fact, I'd say we should just continue using <i> and <b> because those communicate intent better, but at this point I've worked in too many codebases that decided that <i> could be hacked to mean "icon" (i.e. using FontAwesome) which is a horrible, awful, no-good, bad, hack. > All the HTML5 input types are also an example of semantics impriving. It could be way better, but it's not a total stalemate That's true, but I think we'd be moving forward a lot more quickly if we weren't devoting most of standards development resources toward giving companies more fine-grained control of our browsers through CSS/JS.
- GoblinSlayer 4y agoMy e-book reader shows <em> text with teal color and I like it, it's better visible than italic and the font remains upright and readable, I doubt it will be comfortable to read lots of text in italic. I didn't notice any discrepancy with <i>. But for some reason <strong> doesn't override <em> and they multiply, though I saw it used once when an exclamation was repeated several times with increasing emphasis for extra dramatism.
- magicalist 4y agoThis...does not match history. There was never a golden era like you describe (it was a time of conflicting philosophies, people saying "eh, let's add this, that would be sweet", and browser vendors competing to add as much as possible to out "innovate" each other and the limited specs), semantic HTML helps in some cases but is never going to give you automatic accessibility, and a one size fits all browser style is still not going to give you what you need even as you add increasingly unsemantic tags to try to improve it (which is exactly what was happening pre-CSS).
- kerkeslager 4y ago> This...does not match history. I've been writing web code since 1997ish, so... > There was never a golden era like you describe (it was a time of conflicting philosophies, people saying "eh, let's add this, that would be sweet", and browser vendors competing to add as much as possible to out "innovate" each other and the limited specs) I did not describe a golden era of HTML, because a golden era of HTML never happened. Instead, it was precluded by the introduction of JS/CSS. Had JS and CSS never been invented, we might have achieved a golden era of HTML, but we would have needed web standards to mature before that could happen. What happened was, web standards did mature, but they matured to serve websites rather than users. As a result, mature web standards center around JS and CSS, leaving HTML anemic and weak. What we have now is a time of conflicting philosophies, with websites competing to add as much as possible to out "innovate" each other. Users still suffer the same inconsistent interfaces they did in 1997, it's just that instead of browsers being inconsistent, it's websites that are inconsistent.
- NoGravitas 4y agoWell, there was a previous garbage area, when HTML was, rather than being semantic, laid out using tables and \<color\> and \<font\>. I remember telling people to not do that, especially when the first version of CSS came out, and you could make websites look nice with semantic HTML that also worked in Lynx.
- Dalewyn 4y ago
- vlunkr 4y agoIt would be so great if there were more built-in interactive elements like tabs, modals, and tooltips. How many times have these incredibly basic things been re-created?
- NoGravitas 4y agoYeah, all this time browser vendors should have been taking a "pave the cowpaths" approach to natively implementing stuff that everyone ends up reimplementing in CSS and JS. And HTML5 did a little of this, with e.g. date and color input fields. But they could have gone farther.
- vlunkr 4y agoTo disagree with my own point a bit, it’s unfortunate that the controls HTML5 added look different in every browser, and can’t be styled with CSS at all.