Makes you wonder why HN won't budge with those <table> tags in the source code. One day I hope to see "Table layouts are back with <table> tags" and the HN programmers would have saved themselves so much work.
Even without the accessibility in mind, go to http://csszengarden.com/ and try to replicate that with tables. Barely ten years have passed and the idea that not everything on the web is an app and sometimes it is nice to have ability to change the presentation without even touching the markup.
Flexibility is what allowed webpages to be "responsive" before media-queries even existed, and semantics is what allows accessibility, search engines, and other html parsing tools ("readability" in Firefox and Safari, ...) to function better.
The only advantage it has is that it's old and predictable. That's why it's still used to format emails for instance, it's reliable and works on most supports.
As far as I am aware no spider is looking at the DIV and gathering semantic information from it. Sure, it may look at the TABLE and initially assume it has tabular data in it, but a tiny bit of logic fixes that.
DIVs are not actively anti-semantic. They are just a-semantic. So they're not particularly right, they're just not actively wrong.
Or blind people using a screenreader?
DIVs aren't entirely semantic, but table is semantically wrong for how it's being used. It'd be like if I asked you to "get me the pencil off that thingie" and pointed at a chair with a pencil on it. As opposed to "get me the pencil off that table" while pointing at the same chair with a pencil on it.
That said, CSS layout should have been based on tables/grids from the get go, ie. specify a set of blocks as rows and cells, with colspan and rowspan. It took way too long to get to this point.
ungrid.css [0]
@media (min-width: 30em) {
.row { width: 100%; display: table; table- layout: fixed; }
.col { display: table-cell; }
}
I changed it to a real TABLE, since that's far more accessible -- most users can cut and paste into their spreadsheet, and a screen reader might give options to avoid reading out all the data.
Another time, a web developer changed all my <i>Homo sapiens</i> to <em>Homo sapiens</em>.
<span lang="la">
"The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, transliteration, a thought, or a ship name in Western texts."
https://www.w3.org/TR/html5/text-level-semantics.html#the-i-...
https://www.w3.org/TR/html5/text-level-semantics.html#the-i-...
For example, further down the page:
"Authors are encouraged to consider whether other elements might be more applicable than the i element, for instance the em element for marking up stress emphasis, or the dfn element to mark up the defining instance of a term."
As an element it used to be the way to italicize text, to emphasize that text, before CSS. These days it has had a semantic reason for its existence applied which is a slight variation of its original purpose under the HTML4 spec.
<table>
<tr>
<td>
<table>
<tr>
<td>
<table>
<tr>
<td>
This argument was over a decade ago and it's because it's a nightmare to work in tag soup.
I still have to deal with tables for layout on mail templates, bloody Outlook, and that extra 2 layers of tag nesting you have to do on every level quickly turns the code into an incomprehensible mess, even with careful indentation.
And if you're not very careful with indentation it turns into an utter nightmare.
<div class="container">
<div class="maincontent">
<div class="col-md-4">
<div class="row">
<div class="col-md-8">
<div class="row">
<div class="header">
<div class="text-center">
<div class="brand-text">Both are fixed in modern html5 which moves (back) towards simple, semantic, document layout (html-body-article-heading-etc).
With flex-box layout it's also quite easy to have the article/main content come first (possibly preceded by a header) - followed by sidebars and footer -- all as their own "top-level" boxes/containers.
In a classic table layout, there's an extra top level element in addition to "body" - the surrounding table.
And finally table layout is generally verbose and messy for other types of content than tabular data.
Honestly, for what I'm doing (a pretty complex web app with an almost desktop-style GUI with a bunch of buttons, text inputs and checkboxes everywhere) a Bootstrap-style div layout gets at least as verbose and messy as a table layout would. I especially hate having to always do HTML comments with class/id names after every </div> so I know what closes what when I'm near the bottom of the file. At least with tables you get </td></tr></table> instead of </div></div></div>.
But of course a div layout is at least partially semantic and mobile/small screen friendly.
In a classic table layout, there's an extra top level element in addition to "body" - the surrounding table.
In practice, any bog-standard div layout today has a <div class="container"> at top level which contains nothing but other divs and sets size and positioning for the whole page. This is roughly equal to a <table>, no?
> of course a div layout is at least partially semantic
That's contestable, <div> nowadays is absolutely unpredictable, <table>s are more semantic
Sometimes i wish HTML was like python hehe
Sometimes it's a redundant stand-in for "body > .content" or similar (eg: divs dropped directly in body) - and is prevalent because developers don't understand and care about css selectors (or there's that one person on the team that doesn't -- don't get me wrong -- I realize the real world is full of real co-workers, and making a change isn't always easy).
And partially it can be an artifact of abusing floats for "grid layout". Most typically though, the "container div" just ends up being a completely redundant extra "body" element.
Right. There's different contexts between an application an a (hyper)text document.
What's good semantic markup for one, will generally be bad for the other.
It's admirable (and desirable) to strive for adaptive layout and accessibility in applications - but they need a different type of framework than documents made for browsers. The browsers straddle this divide rather uncomfortably - being in part hypertext document browsers, and in part virtual machines for running general applications.
Approaches like web components[1] might help us move toward a standardised reality for "applications that happen to run in the browser", while css and html are still (more and more anachronistically) (hypertext) document markup and layout tools.
If you want to make a Web page/site (like alistapart.com) that's great. Swim with the current and draw inspiration from stuff like css zen garden[2]. With flex box, you can burn[4] most of the old complicated grid layout stuff, and comparatively easily make great sites.
That doesn't really help if you're a "front-end developer" making "apps" though. Even the few that make an effort to color within the lines are still fighting the browsers and the standard, trying to fit a code-on-demand app into a REST shoe[3].
[1] https://www.webcomponents.org/
[2] http://www.mezzoblue.com/zengarden/alldesigns/
[3] https://news.ycombinator.com/item?id=13500635 (I've said it before - the true tragedy isn't that too few read Fielding's thesis and never understood REST - It's that so many ignore that he covered a lot of other architectures that are more suitable for many applications than REST is)
[4] https://philipwalton.github.io/solved-by-flexbox/demos/grids...
<div class="container"> is one of my least favorite things to see in HTML, in particular. No shit it's a container; all HTML tags are containers. HTML5 introduced all these wonderful semantic elements precisely so that we don't have to pollute HyperText documents with thousands of divs.
Also, that "text-center" class drives me to drink :)
It's a standard component of Bootstrap ;)
<div class="tree">
<ul>
<li>
<a href="#">Parent</a>
<ul>
<li>
<a href="#">Child</a>
<ul>
<li>
<a href="#">Grand Child</a>
</li>
</ul>
</li>
<li>
<a href="#">Child</a>
<ul>
<li><a href="#">Grand Child</a></li>
<li>
<a href="#">Grand Child</a>
<ul>
<li>
<a href="#">Great Grand Child</a>
</li>
<li>
<a href="#">Great Grand Child</a>
</li>
<li>
<a href="#">Great Grand Child</a>
</li>
</ul>
</li>
<li><a href="#">Grand Child</a></li>
</ul>
</li>
</ul>
</li>
</ul>
</div>
I googled for a solution that I could add to and maintain myself and this was what The Internet threw up as the best solution, but it is far from good.
<ul>
<li>
<a href="#">Parent</a>
<ul></ul>
</li>
</ul>Side note: the top-level div isn't really necessary; you can just apply the `tree` class directly to the `ul` with a small tweak or two to the CSS.
To illustrate how HTML so ill suited to this structure, I had another look at the problem and found Treant, because yes, the easiest to do this on the Web and maintain it is to write an entire API.
(But then you'll hit a wall as you try to deal with the containers and subcontainers.)
Web apps aside [sigh], if one was to disable CSS (and thus all the blocks making it look pretty), the page should still make sense. An H1 as the main header, copy in paragraphs, headers dividing up the content, blockquotes, navigation in lists - and tabular data in tables (etc, etc).
It doesn't always work like that in practice, but that's the aim.
And webpages are a document presentation format. If jamming applications into documents made the web an application platform, than jamming grid layouts into tables made them a grid widget.
Calling a SPA a "page" is a larger and more ridiculous lie than calling the table tag a grid layout widget. Anyone still committed to the table tag lie should move all their apps out of the browser today.
Web developers can work around the table tag, but not the fact they're jamming apps into documents. So one of these lies is taken more seriously than the other.
If it ain't broke, right?
https://dxr.mozilla.org/mozilla-central/source/accessible/ht...
https://cs.chromium.org/chromium/src/third_party/WebKit/Sour...