I work on an older project with some folks that never got the memo about tables being evil for layout. In my experience, they've actually been quite easy to work with. Granted, we develop for a fixed screen width. Why were tables declared evil?
Aside from the semantic HTML movement, they're clunky and verbose, more difficult to break up into reusable components, and table rendering is more expensive than the equivalent layouts with non-table elements and CSS (at least that was my experience last time I tried profiling a table with hundreds of rows).
Edit: they also have a lot of intrinsic layout behavior that can be difficult to predict once you start getting into more complex layouts than header, sidebar, and footer.
They didn’t flex like flexbox. When smaller laptop screens and eventually mobile devices appeared on the scene, tables would often extend past the screen’s boundaries.
They mix content and presentation. If you separate content from presentation, then you can have a presentation for desktop an another for mobile. Also, you can totally change the layout without the need to change your HTML, as showcased in http://www.csszengarden.com/
The whole concept of separated “content” form “presentation” in UI is a bunch of nonsense. Maybe it works somewhere in some very limited sense, but I’ve yet to see anything complex that separates these things.
In the specific case of html and css I agree that it rarely works. There are a few examples like subreddit css, but in general html does to much layout to meaningfully separate content from layout. Xml and XSLT is a much better separation, with Xml containing pure content and Xslt transforming that into XHTML with CSS for presentation. But that never got much adoption.
In other domains separating content from presentation works well. But in web development the incentives don't align with that idea.
Agreed. The real answer, as you noted, is that presentation really is HTML+CSS. You can join it with content in JSON (or XML if you want) via client or server side templating.
It actually gets you pretty close to MVC or whatever MVVC is maybe? Is that still a thing?
It’s really not nonsense. Make a text file with line breaks to force a line length, and then make a non-trivial edit to the content. You’ll have to move all the line-breaks too. It’s awful.
If you’d instead left presentation to the display tool, you’d only need to change the content.
The HTML presentation/content argument is this scaled up.
> Make a text file with line breaks to force a line length, and then make a non-trivial edit to the content. You’ll have to move all the line-breaks too. It’s awful.
Your editor is also your presentation tool here, and it knows where all the line breaks should be, so it can do the edits for you. It works those around the content. If you hadn't included the line-breaks in the first place, it wouldn't even have needed to do that (well, ok, it would to "soft-wrap").
If you passed/copied the file to someone who prefers a 78 character line to your 100 character line (or uses a machine from the early 80s for retro-cyberpunk chic), when they render the file, several things could happen:
- their viewer/wditor might add temporary line-breaks to soft-wrap, in which case they'll see some short and some long lines
- their viewer/editor might add hard-wrap line-breaks at 78 chars. This would remove all your 100 char ones, and could potentially break your content because it might not see the difference between a "wrap" and a "new paragraph".
In the second case, when you get the file back later on, the content wont suit your preference for 100 character lines.
When the presentation is kept out of the content, none of this happens.
My point was that even in something as simple as a text file, adding presentation commands (line breaks), adds work, or hinders accessibility.
Scale that up to HTML and the wider range of possible presentation options. Say you used the old-school inline colouring options. Maybe you find green text on red backgrounds really fun to read. You encode that into the content (the markup). Pass this file on to someone with red-green colourblindness (c7% of XY-chromosome carrying humans[0]) and they wont be able to read your file at all.
The separation of content from presentation is one of the primary purposes of MVC frameworks. The model (content) is separated from the view (presentation) by an abstraction layer (controller).
Screen reader pedantry, I think; also they're "not semantic markup". The idea was that tables should only be used if the content was genuinely a table.
You're right, it's unnecessarily abrasive. But it is, as far as I can tell, a very minority use case, and these days most of the reader software has adapted. If you see some of the DOM horrors inflicted by Facebook, then suddenly tables look positively readable.
Perhaps what should have happened was the defining of a "table-layout" tag that behaves exactly the same as "table" except it's understood to be for visual presentation only. Flexbox almost achieves this, but for some reason isn't as popular.
One answer reveals itself by just switching two lines around:
> Why were tables declared evil?
> Granted, we develop for a fixed screen width.
Personally, I was always more disturbed by the anti-semanticism of the layout use of tables. But I guess at some point the web developer community just really stopped caring about such issues. Or at least that's my takeaway of the common atrocity of style attributes on individual elements that css-in-js approaches frequently produce.
I think the people really pushing for the Semantic Web kind of gave up. You hardly ever hear that term anymore.
I guess the value proposition of "You can add a whole bunch of complexity to your webpage that won't affect what people see so robots can scrape your page easier" didn't really resonate with developers. Also, the proposals I saw were much too granular and focused on people writing scientific papers on the web. It wasn't a good mesh for the "garbage" web, which is like 99% of everything.
There’s nothing non-semantic about inline styles. And most css-in-js convert thise inline styles to a separate stylesheet with classnames.
I’d say web developers care much mire about semantics now than they did ten years ago. At least now you can finally have meaningful conversations around accessibility and screen readers.
