Comment by andybak | Hacker News Reader

Comment by andybak | Hacker News Reader

Parent Full thread

I've been idly thinking about starting a list of 'cargo cult development ideas' - more specifically things that make sense or made sense in a specific domain but got passed around and became detached from their original intent.

There's a related idea that interests me - ideas that were useful mainly for killing something else. These two things overlap somewhat.

1. "Don't use tables for layout" - helped kill the most horrific era of web-design which was largely based on slicing large photoshop images into parts and reconstructing them in html tables. Responsive design would never have been possible if this practice hadn't have been vanquished. The actual arguments for not using tables for layout were much more nuanced and in some places - just wrong. 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.

2. REST. Most APIs are still only an approximation of 'true' REST - or just kind of cheating and sticking in some RPC-style endpoints when the going gets tough. The promise of machine to machine API usage without developer intervention is yet to be realised. However - REST stopped SOAP from taking over the world and for that we must be eternally thankful.

3. "Separate content and presentation (HTML/CSS)". Similar to (1) - this was based around a core truth about separation of concerns and maintainability. However it became a mantra rather than just one specific way you could attempt to reduce coupling and create less brittle markup. But it was easy to explain and easy to argue for and it stopped a lot of bad practices.

I had a few more but I can't recall them right now. Maybe the message is "simple to explain but partially inaccurate ideas are easier to transmit than nuanced and complex ones"

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.

What 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.

There 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?

<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.

I 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.

I 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!

Their 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.

Being dogmatic about anything is usually going to end up being wrong. But I think a lot of common advice is meant to serve as a baseline. It helps us take mental shortcuts while we familiarize ourselves with the field. Once you're more familiarized with everything, you start to question things more heavily. Otherwise you'll probably end up with decision paralysis.

> "Separate content and presentation (HTML/CSS)"

The wrong thing was the one-to-one mapping of the content, presentation and business logic to some specific technologies (them being HTML, CSS, JavaScript). That's why so many people got confused when they saw XML tags in React. OTOH, as you said, we usually need simpler rules. The moment people started to think that "now it's OK to put HTML in JS", we started seeing blog posts being written in React containers.

Flash replaced <blink>.

Reply on news.ycombinator.com