Hacker News Reader

Comment by outop | Hacker News Reader

Before CSS people used to use tables, often nested, for all kinds of layout. Eg if your page had a header, a sidebar and a main text area, you would create a table with cells of the right relative widths, with invisible borders, and put each layout element in one possibly merged cell. This was essentially standard practice for a while.

CSS allowed layouts like this to be done without tables. It still supported tables, but for the case when you actually want to show tabular data which would appear like a table on the page.

View on HN

And then it took some 20-ish years for CSS to finally realize that aligning to a grid is a good idea and, through a long, painful, incremental process, eventually reinvent tables for layout.

I mean, semantics are also good! Yes, CSS grids are a lot like tables in some ways, but not having to add 25% more DOM elements to fake a table layout (display: table/table-row/table-cell; that's 3 divs for one row!) is also a thing to be celebrated. Plus, in practice, grid is a lot more powerful than doing a few common layouts. Grid took so long precisely because they were trying to think a little further ahead rather than just pushing something out into the world and hoping it works out. Thankfully web standards have matured and are more careful not to repeat mistakes like the debacle that was CSS property prefixes.

>I mean, semantics are also good! Yes, CSS grids are a lot like tables in some ways, but not having to add 25% more DOM elements to fake a table layout (display: table/table-row/table-cell; that's 3 divs for one row!) is also a thing to be celebrated.

Semantics in the context of CSS is a stupid idea web designers came up with. They heard the concept of "semantic", and had to fit it in, to appear smart. Should have asked actual developers.

(the so-called "semantic web" was another such failed idea dragged on for an eternity for research grands. Remember RDF? What fun!)

The semantics is not the job for HTML, which is the final artifact for display, and not a data interchange format, nor the format you store your info as. So there's no need for it to be semantically clean and "parsable/reusable" (to do what? web-scrap it? As for screen-readers, there are official metadata annotations for those - not to mention they wouldn't know to do anything special for each ad-hoc different "semantic" tag soup people come up with with the severely limited for that reason HTML5 tags, or worse divs).

The semantics belong to whatever backend and metadata you have your content in, before it gets rendered as HTML.

And if you need to also give it to users in parsable/reusable form, allow them to query a JSON (or structured) version.

Yeah, it's a joke. You can't take "HTML semantics" seriously when you often depend on actual element position IN THE HTML CODE to make things work, specially when modern web design demands elements to just JUMP AROUND all over the page when the width changes.

If they really wanted semantics you would think there would be actual support for that.

By the way, I've asked this question here some other day, but nobody has any idea if most "semantic" tags are being used for anything at all (and Wordpress naturally uses all of them wrong, so there is no point even bothering).

There's not much software that takes semantic HTML as input, because barely anyone writes semantically-valid HTML. It's a vicious cycle. (Look upon the parsing rules for a high-quality screen reader, and weep.)

No point making a semantic web browser before we get a semantic WYSIWYM HTML editor. Maybe those could be the same program, like in olden times?

Semantics is what makes both web crawlers and assistive technoligies know that <a href> is a link.

> but not having to add 25% more DOM elements to fake a table layout

I'm not the most current, but as I remember in CSS tables those table-internal elements generate the needed anonymous boxes of rows, tbodys and such, when those arent't specified:

https://drafts.csswg.org/css-display/#example-d11b97c3

Nah, semantics are worthless. The whole semantic web idea never took off for good reasons, HTML5 semantic tags don't have any meaningful semantics and you can't even reliably remove boilerplate from HTML without ML pipelines (a basic use case you'd expect any "semantic" document format to nail easily). Then the invention of LLMs killed it twice over.

HTML is a graphics rendering language in denial about its true nature.

Grid took a long time because everything takes a long time when you have to align mutually competing organizations and there's no profit motive involved with the actual work itself. There's no real technical benefits to CSS layout over table tags. A table tag isn't a heavy object. CSS cascade calculations on the other hand ...

I suggest you spend some time with a screen reader or have a look at the accessibility tab of you browser to get a feel of the worth of semantic web.

It's true you won't ever have a perfect semantic representation of a page (and I have no idea how blind people manage those infinite scroller), but in my mind having <nav> or <div role="nav"> instead of <div class="my_non_standard_nav_classname"> still helps a lot on that aspect.

I use Shortcat all the time which relies heavily on the accessibility tree.

Screen readers / accessibility tools don't use the semantic web. The semantic web doesn't exist, it refers to the Tim Berners-Lee vision of documents being XML or RDF data structures with schemas, transformed into pixels using stylesheets and XSL:T. It never happened for various reasons.

CSS tables can have grid-auto-flow as dense, which is quite helpful at rare times. You obviously could do that wit tables + js, but it's nice to not have to worry about the implementation details.

CSS have supported ‘display:table’ for 25 years, which is exactly “tables for layout”.

Funny thing is that it still easier, even today, to use a frameset rather for header, sidebar and main area rather than fiddle with the new grid system.

Use position: absolute; or position: fixed; for both header and sidebar. Main area gets margin as big as header and sidebar. No framesets needed. That's at least what I did in 2001 and it worked like a charm. Even matching background elements of header and sidebar without any gaps.

Are framesets even supported in modern browsers? They have been removed from the html standard.

They are still supported and works perfectly fine still. Remember that browsers supports different DOCTYPEs (HTML5, XML, HTML4 strict and non strict etc) and they are not going away anytime soon, probably thousands and thousands web sites out there that doesn't implement HTML5 and never will.

Frameset is deprecated in HTML5, but your index page can be of the older frameset DOCTYPE and each frame valid HTML5 page with a <!DOCTYPE html> declaration. This is why frames (and iframes) are actually great because you can mix old an new.

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" 
      "http://www.w3.org/TR/html4/frameset.dtd">
    <html>
    <head>
        <title>My page</title>
    </head>
    <frameset cols="100%" rows="10%,*,10%">
        <frame name="header" src="header.html">
        <frameset cols="20%,80%" rows="100%">
            <frame name="sidebar" src="sidebar.html">
            <frame name="main" src="main.html">
        </frameset>
        <frame name="footer" src="footer.html">
    </frameset>
    </html>

e.g main.html

    <!DOCTYPE html>
    <html>
        <head>
            <title>main</title>
        </head>
        <body>
            main
        </body>
    </html>

AFAIK no browser use the doctype for anything except for triggering quirks or standard rendering mode in css rendering.

But looking at MDN it seems you are correct, all mainstream browsers still support framsets.

Reply on news.ycombinator.com