3 ms·
Slightly OT nitpick: > In particular the arguments based on tags having semantic value were laughable when you consider that in most cases we just replaced tab
by lucideer 10y ago
Slightly OT nitpick:
> In particular the arguments based on tags having semantic value were laughable when you consider that in most cases we just replaced table/tr/td with div/div/div.
This comes up a lot and it niggles at me every time. div/div/div was a large semantic improvement over table/tr/td, not because it specifically describes the content you've put in divs better (it doesn't, obviously), but because it stops being explicit "dishonest" about the semantics of that content.
Defaulting to div/div/div over table/tr/td makes semantic specificity opt-in and explicit instead of opt-out and implicitly wrong for generic non-table content. It means devs who want to use specific tags for greater semantic specificity can do so, while most devs are using generics (divs) because they don't want/need the specific semantics. The previous alternative was that the majority were following a pattern that made intentionally semantic table content indistinguishable from generic[0] content.
Otherwise, good post. I'd like to see that list started and growing.
[0] By "generic" content I just mean any content where there isn't a strong desire/need on the dev side to describe it very specifically.
- k__ 10y agoWhat I don't understand, we have a whole bunch of semantic HTML elements for years now (<main>, <section>, <header>, etc.) and no need for <div class="main"> anymore, but they don't get used very often.
- bshimmin 10y agoThere are two reasons: 1) There's no real world benefit to using these elements, in any easily demonstrable way (maybe there's some sort of tiny accessibility or SEO advantage, but it's fractional in comparison with, say, just using H1/H2/H3 correctly), which mostly leaves them as an exercise in academic purity. 2) The definitions are really woolly and require far too much thought, especially given the previous reason. Why bother debating whether something is a SECTION or an ARTICLE or a MAIN when you can just use a DIV, with whatever probably overly specific `class` you were going to use anyway, and it will still work in exactly the same way?
- patates 10y agoTheir meaning changed through the design process very often, which is normal. But the whole process was too public and people started to play with them and we had so many different interpretations... In the end, I think the developers just gave up.
- lucideer 10y ago<main> came late - the others were developed while the HTML5 process was being actively watched and talked about (before people got bored following it) so noone really reported widely on the creation of <main> and as such it's rarer. Hence <div class="main"> <section>, <header> and <footer> are not too uncommon. <article> is by far the most used, and is also put to genuine use in parsing by things such as Firefox/Safari's Reader views and other such tools. <section> gets used similarly by some parsers I think, though I've no direct examples off the top of my head.
- err4nt 10y agoI see them get used all the time! Some of the most common layout tags I see are: header, main, footer, section, article, aside, nav Other things can have <footer> tags too. I've seen plenty of <footer> elements inside <blockquote> tags!
- parenthephobia 10y agoI use nearly the full set of semantic elements, but I think they're a pretty stupid idea in general. They only properly make sense when the actual semantics of your content happens to align with what the authors of the specification had in mind. For the high-level layout elements it's not so bad, but the <i> element being defined as indicating things such as "taxonomic designation, technical terms, foreign idioms, transliterations, thoughts, ship names, or dream sequences" renders it basically pointless. The HTML spec encourages you to use a class attribute to identify why <i> is being used, but then you might as well use <span>. Most browsers - maybe all modern browsers - actually accept made-up elements and let you apply CSS to them. There's no good reason - other than compatibility - why authors shouldn't create ad-hoc elements - e.g. <dream> or <tabs> - that match up with the true semantics of the content.