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"
> 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.
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.
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.
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.
It depends which device you use to look at it. It tends to adapt poorly on large screens or smartphones (at least the ones I use). And this is the primary reason to not use table AFAIK.
For me, HN works better then 99% of all sites. On all of my devices. Desktop, tablet, phone. It always does exactly what I want it to do: Fill the whole window with content. So I can always resize the window to the exact size that is most comfortable for me. And it's blazingly fast.
A few years ago HN's nested tables led to random font sizes on mobile. So there have definitely been problems in the past.
But HN is also in a very unique position. It has 170 lines of CSS and thousands of talented web developers have inspected it for mobile problems. Every easy fix has been made. Most websites can't do that.
On a new app I'm developing I am using display: table and display: table-cell. These work great. I'm curious as to why this solution is not more widely used or discussed.
1. On many browsers, if you don't use `display: table-row` between those, it'll mess up your content.
2. CSS only almost exposes the HTML table layout system. e.g. There are no column groups, or column or row spans. There's no way to indicate a table header in CSS that would make a browser repeat it when printing a table over multiple pages.
3. People who learn by rote that table is evil without really learning why are likely to assume that using CSS to make something behave (almost) like a table is also evil.
