Hacker News new | ask | show | jobs
by munificent 3061 days ago
I giggle a little bit inside when web designers say "We shouldn't use meaningless tags that exist only for layout. We should use semantic ones, like <header> and <footer>!". Except that, uh, "header" and "footer" themselves are layout terms. They're just a metaphor for a document as a body ("<body>") with the head at the top and the feet at the bottom. It's not like the contents of a <footer> tag have anything to do with feet. We call it "semantic" simply because the metaphor is old enough that we've internalized it and no longer see it.

Not that I think this detracts from the talk at all. Fewer, cleaner tags is good, regardless of how they're spelled.
8 comments
vanderZwan 3061 days ago
I do not see how the etymology of these words being a layout-metaphor argues against them having more semantic value now? The way you describe a footer makes it sound like the last block of text of any article (being at the bottom) is by definition the footer. Which is of course not the case: it is used for certain types of content.

Your own book uses <asides> very heavily[0]. They are not just literally aside the regular flow of the document (actually, about that, see the next paragraph), the type of content in them is different - it is reserved for tangential stuff like jokes or deeper information that would interrupt the pacing of the main narrative.

Aside about asides in your book: I bought the epub version when it came out, and although it was a symbolic purchase (I had read the whole thing already as you wrote it), I somewhat regret the format choice due to the sorry state of epub readers. Not all of them even support the aside tag. The one that does (the Firefox Epubreader extension) does not keep a margin for the aside but inlines them. This really disrupts the flow of the text. In traditional book layouts that use the full margin for the text, these asides would be printed as a smaller footnote at the bottom of the page. Surely with the right bit of code one could generate such a layout, based on the semantic meaning of <aside>. But like I said: epub readers are in a pretty sorry state. Should have gotten the pdf instead[1].

[0] http://gameprogrammingpatterns.com/introduction.html

[1] http://gameprogrammingpatterns.com/sample.pdf

link
munificent 3061 days ago
> The way you describe a footer makes it sound like the last block of text of any article (being at the bottom) is by definition the footer. Which is of course not the case: it is used for certain types of content.

That's a fair point. Since, historically, the convention has already been established that the stuff we put at the bottom of the page in a footer tends to be stuff about "X", we can now say with some confidence that "footer" has the semantic "about X".

> They are not just literally aside the regular flow of the document (actually, about that, see the next paragraph), the type of content in them is different - it is reserved for tangential stuff like jokes or deeper information that would interrupt the pacing of the main narrative.

Right, they are both. They are physically off to the side because they are unnecessary for the main line of the narrative. The form and the function are in harmony (as they should be!).

"Aside" is another funny word because it's also a spatial word. I'm not sure how it entered use for print. I could see it being simply because the text is to the side.

But "aside" also means an "an utterance not meant to be heard by someone; especially : an actor's speech heard by the audience but supposedly not by other characters". That conjures up a delightful image for me of an actor literally stepping to the side, leaning towards the audience and muttering a joke to them. That's the picture I always have in mind with the asides in my book.

I could see it entering print from that etymology too.

> I bought the epub version when it came out, and although it was a symbolic purchase (I had read the whole thing already as you wrote it), I somewhat regret the format choice due to the sorry state of epub readers.

I really appreciate you buying a copy! I agree, ePUB is about the worst format. But it works on eReaders, which is nice. If you aren't limited to one of those devices, the PDF or web version is probably better. If you'd like me to send you the PDF version, email me and I'd be happy to hook you up.

link
flooq 3061 days ago
We call them semantic because they have extra technical meaning in HTML (built in WAI-ARIA roles for example). For example, browsers expose them as landmarks for screen readers.

That said there are a lot of similar examples of magical beliefs that are unfounded. Extra <div> tags rarely matter and "semantic" CSS values don't do anything.

link
52-6F-62 3061 days ago
They've also been industry standard in publishing for much longer.
link
awj 3061 days ago
> Except that, uh, "header" and "footer" themselves are layout terms.

Doesn't that give them semantic meaning? When I see a "header" tag, that tells me something about its intended use. When I see a "div" tag ... I start reading ids and class names and hope for the best.

link
shripadk 3061 days ago
Semantic tags are required from an accessibility point of view. If not, there wouldn't even be a need for a <table> tag. Might as well just use <div> with display:table. Actually you could just about use <div> for everything! But by doing so, you are alienating those who use screen readers to browse your site.
link
rhencke 3061 days ago
That's not true, though. Semantic tags may make it easier to be accessible, but they are absolutely _not_ required.

WAI-ARIA defines the mechanisms to make existing webpages accessible, and they do not require using tags for their semantic meaning - quite the opposite. You use role attributes for this.

For example:

    <div role="button">Click me.</div>
is perfectly accessible, and will be interpreted as a button, though semantically it's a div.
link
gnud 3061 days ago
And if you have a set of well-defined roles, why not create tags for them, and replace all the divs? Seems a lot simpler.
link
shripadk 3060 days ago
WAI-ARIA has its limitations. When it comes to tables (which is the example I provided) there are no roles for demarcating headers (<thead>), body (<tbody>) and footers (<tfoot>). Instead there is a generic "rowgroup" role which doesn't indicate to the person using a screen reader if the row belongs to a header or body or footer. Also, without a header demarcation, it becomes the responsibility of the disabled user to keep a count of the table cells to be able to associate content with headers (which the blind user will have to assume is the first rowgroup). Complex tables (which have multiple header rows with some cells merged) are simply inaccessible to the user.

WAI-ARIA complements semantic tags. It doesn't contain replacement for all semantic tags. It doesn't stop at the table tags. How would you represent <main>, <aside>, <header>, <footer> using WAI-ARIA such that the screen reader picks up the intent? Also imagine trying to replace the <input> or <textarea> elements with <div> tags. You would have to use _contenteditable_ and then implement all the semantic features yourself. It's just not worth the effort and the end result will be buggy.

link
ams6110 3061 days ago
They are semantic in that <header> differentiates content in a way that <tr> does not, even though it may also have layout implications.
link
threatofrain 3060 days ago
I really don't see why we should have semantic tags to begin with, since semantics isn't obviously the psychological API by which future colleagues are going to operate on your code. Think about the interface by which colleagues wish to edit your code.

Do they care more about its structural position? Then name it by structural position. Do your teammates care more about a component's logical relation? Then name it by its logical relation. Do they care more about the actual content? Then name it the EULA component.

But one way or another, based on the modern way of web dev where an interface is divided into components, any team inheriting a project will need to understand Y components explaining X pages no matter what. Naming is helpful, but the distance from good naming to great naming won't be a big force multiplier.

link
commandlinefan 3061 days ago
> We shouldn't use meaningless tags that exist only for layout.

Well, honestly, using HTML for around 90% of what it's used for these days is the roundest peg in the squarest hole to begin with.

link
ben174 3061 days ago
It makes more sense when you think of “header” as newspapers think of “headline”.
link