Hacker News Reader

Comment by bazoom42 | Hacker News Reader

It is a weird myth that CSS somehow discourages tables. CSS have supported styling html tables and ‘display:table’ (allowing a table-like layout without html-tables) for 25 years.

Float and clear was grandfathered into CSS since they were added to HTML by Netscape. They are fine for their intended purpose: placing images in a text and have the text flow around.

Other positioning systems you mention does not solve the same problem as CSS. CSS has to support viewports of any size and dimensions and allow text to scale independently of the viewport size and still remain readable.

View on HN

>It is a weird myth that CSS somehow discourages tables. CSS have supported styling html tables and ‘display:table’ (allowing a table-like layout without html-tables) for 25 years.

Not a myth in any way shape or form. Tables for layout (not tables in general) were discouraged with various arguments in favor of "float/clear", even decades before a sane substitute (grid/flex) was available.

>Other positioning systems you mention does not solve the same problem as CSS. CSS has to support viewports of any size and dimensions and allow text to scale independently of the viewport size and still remain readable.

None of those requirements is unique to CSS, and none of those requirements necessitates the stupid float/clear mechanisms that were shoved into people's throats for 15 years.

We're talking about the style language that had layout shoe-horned into it, and which tool decades to develop the most basic layout mechanisms available in GUIs for decades, grid layout and flex layout. And even when it did, it didn't it badly.

CSS never recommended float/clear as an alternative to table-based layout. CSS had ‘display:table’ for when you needed a tabular layout without the semantic baggage of the table-tag.

"CSS" (not sure what you're referring to here, the standards bodies?). Endless articles from the mid 2000s kept saying tables bad, here's how you layout without tables. All of them used floats for layout, not display:table. Partly I suppose this was because IE didn't support it until 2009, I think.

Nearly all layouts people actually want are table-like, and I think CSS really was misguided in its text-flow as layout approach.

The reason for the advice against tables was that the "semantic web" was all the rage (probably mostly because Google wanted to make it easier to index stuff). If you have tabular data, using tables was just fine. The issue was with using it solely to control the graphical presentation without any semantic basis for putting it in the table. Same reason you don't use <H1> just to make the text bigger.

>The issue was with using it solely to control the graphical presentation without any semantic basis for putting it in the table.

There shouldn't be any semantic basis needed.

HTML is not a semantic data exchange format, was not designed to be (the pathetic handful of semantic HTML5 tags added to be used ad-hoc included), and it inevitably includes content, style, and behavior (js).

The semantics should belong to data intergchanged (and storage format), and the reusability should be on the data storage/query backend, not to the markup language.

Adding semantics to the markup duplicates the semantics already present in your DB or JSON API scheme or query server/storage in general.

Semantic markup is what makes both web crawlers and screen readers recognize that <a href> is a link to another URL. The web couldnt work without it.

Yeah there was a period of time when IE didnt support display:table and ARIA hints wasnt as developed. So if you wanted to create accessible web sites with nice layout you had to resort to weird hacks, often using floats.

Floats was never intended for that purpose though, it was just a desperate hack to get around IE limitations.

But html tables was not a viable alternative for organizations which was required to have accessible websites.

(Today I believe it is possible to create accissible html tables through ARIA hints, but that was not an option at the time.)

> Nearly all layouts people actually want are table-like, and I think CSS really was misguided in its text-flow as layout approach.

I think this is the core misunderstanding in this discussion. CSS 2 supported both text-flow and tabular layout and both layout models were reverse-ingeneered from how Netscape rendered HTML.

There is this weird idea that CSS is somehow opposed to tables or tabular layout, while a significant part of CSS2 is actually the codification of how tables render.

I don’t think there’s much of a misunderstanding here. There are historical reasons why CSS was so weak on layout for so long, but there’s always reasons. To understand what was missing look at what they’ve added (flexbox and grid). I don’t like the implementation of either, but they are in the right space.

CSS is just a language + words of paper spec.

CSS, as in "CSS evangelists", influential web designers, guidelines in web development resources, books, and so on, recommended and advocated for the use of clear/float.

You might not have been there, but float layout was a big thing back then, and everybody was guilt-pressured to use that - neither tables, nor "display: table" (which was used by some, but also discouraged).

I never saw anybody discourage people from using display: table. The reason why nobody used it was because Internet Explorer 6 didn’t support it.

You are probably remembering advice from the dark age of IE6 dominance where display:table was not well supported. I have also seen advice againt using html tables in the early days of mobile browsers since they handled them badly.

The problem is people forget context. The advice “dont use tables <in this specific context under these specific constraints>” is remembered as “tables are bad, never use tables or anything which remotely looks like a table”.

'display: table' wasn't consistently supported and '<table>' for layout caused issues for screen readers because they (rightfully) expected content that's tabular in nature.

> everybody was guilt-pressured

What, no? I did a lot of web development in those days and read a lot of blogs. You just needed to filter out anyone who was obviously over-opinionated and lacked any nuance. Most pragmatic people used tables and didn't feel guilty about it. If you delivered working software with a decent UX, why on earth would you care what some shouty internet person said??

Many public institutions was mandated to follow the WCAG (Web Content Accessibulity Guidelies) which recommend against tables used purely for layout.

So it it not really about vague “guilt-pressure”, it is just that many web developers had to follow WCAG as part of their job.

Oof - I didn't know that. Kind of a weird requirement, were/are screen readers rendered so ineffective by the content being in a table as opposed to in divs?

Not inneffective as such, it just presented a confusing user experience because the screen reader would assume the table represented data structured in two dimensions and e.g present navigation options for going cellwise left/right and up/down.

This would be pretty confusing if the table was just used to create a margin and most cells only contained spacer gifs. Especially with deeply nested tables (as was the fashion at the time) it could be pretty confusing.

Today you can just add an ARIA-hint indicating a html table is used purely for layout and a screen reader can then treat it just as divs. But this did not exist at the time.

Of course the WCAG just assumed it was not a big deal to avoid tables for layout since CSS2 supported tabular layout through pure CSS. But the reality of a web dominated by IE6 made this a much larger problem.

Nobody was guilt-pressured into using floats. You might say some were guilt-pressured into writing accessible web sites but that is a significant destinction. Many public/government web sites were mandated by law to be accessible, so many developers had to write accessible html whether they liked it or not.

Of course for your personal Tranformers fan site you can use html tables to your hearts desire. Nobody is likely to complain.

But most web-design focused media is targeted professionals for whom it is a necesssary skill to be able to design pages which look good for most users and is accessible. During the dark age of IE6 it was necessary for developers to know and use a large array of hacks (including the abuse of floats) to achive this.

> Tables for layout (not tables in general) were discouraged with various arguments in favor of "float/clear"

Table markup was discouraged. There’s nothing intrinsically wrong with display:table from a CSS/semantic markup evangelist’s point of view, it’s just awkward to use, requires you to arrange and order your markup just so (sometimes contrary to semantics), and was rarely mentioned in the days of float/clear because IE screwed it up in various ways (that were more difficult to fix than those for floats). It works reliably now, but as far as laying out the page goes the requirements for ordering the markup will probably be incompatible between desktop and mobile. For insides of buttons and such, though, go nuts.

Meh, discouraged by some bloggers, sure. Those of us doing web development in that time (I built some pretty large websites in the days before flexbox) ignored obviously overbearing advice like that. I still occasionally use tables for layout, even when something isn't 100% a grid of data. Granted those cases are quite rare and generally flex is the right solution.

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.

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.

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

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.

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.

> 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

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

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.

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.

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.

I absolutely remember a ton of pieces about how we all needed to stop using tables (and 1x1 transparent gifs, too) for page layout because CSS was The Right Way

There is always a lot of confusion about this because “tables” can mean different things - it is both a set of structual elements in HTML and a layout model in CSS.

CSS is “the right way” to control styling and layout, but that does not mean you can’t use tables.

In the early days of the web people used the BLOCKQUOTE element to create margins since this was the only way. When CSS arrived, it became “the right way” to create margins - but that does not mean you can’t use blockquotes! You just need to distinguish beteen the semantics of a quote and the layou effect of margins.

But I’m sure someone understod this to mean that quoting things were bad.

But that is the point. CSS arrived, and people started saying you "just need to distinguish beteen the semantics of" a table "and the layout effect". Back then, the chant of the day was, "blood for the blood god, tabular data for the <table> god, layout for the CSS god".

And then it spiraled into general "separation of content and presentation" nonsense that, like in any good cult, people believed with their whole hearts, preached to make new converts, then did the opposite because reality demanded it, and couldn't see the problem. CSS Zen Garden notwithstanding, we ended up with div soups (later, semantic div-equivalent soups) inseparable from complex CSS, because form is function; your content is always designed with a particular form in mind.

Is accessibility for the visually impaired a cult? How could Google even work if content could not be seperated from its visual presention?

Layout tables were never a serious problem for screen readers, this has always been overblown. Screen readers adopted working heuristics to distinguish between layout and data tables early on, because tables were used for layout almost from the beginning (as soon as it was possible to remove the visible borders).

See for example WebAIM https://webaim.org/techniques/tables/: “It is sometimes suggested, even by some accessibility advocates, that layout tables are bad for accessibility. In reality, layout tables do not pose inherent accessibility issues.”

The heuristics described still depend on semantic html e.g the use of <th> or <caption> to signal a data table.

> How could Google even work if content could not be seperated from its visual presention?

Approximately. Like it did and does.

The simplest way is to just strip the markup (or, for purposes of indexing, just ignore any token that resembles a HTML tag). That'll easily get you 90% there. You'll lose important information that's tied to form, but that's a consequence of operating in plaintext land. If doing this to build an index of the web, you'll have problem with scoundrels stuffing irrelevant text made invisible to humans by markup/CSS/JS, but that's exactly the problem Google used to have for a long time, and the essence of what SEO is :).

How would you crawl the web in the first place if there was no way to recognize a link in the HTML?

Google never had a problem working with content that was blended with it's visual presentation. They literally doesn't care. They crawl anything even pdf and other non-html content.

The semantic web was born from a belief that it would enable a peer to peer web that never materialized. Accessibility was better solved by aria annotations a long time ago and the semantic web was never going to properly solve it.

FWIW, it's hard for a peer to peer web to materialize, where the web is almost entirely built and funded by entities who very much don't want a peer to peer web, and in fact actively fight it.

The issue is people taking “tables are bad for non-tabular layout” and just remembering the first three words. People like stark binary yes/no rules, so “tables are bad” was born and spread widely.

If your layout is intended to be a table, then a table (styled with CSS) is the way to go, otherwise use semantic HTML (styled with CSS) and you will (in theory) have an easier time making the design work well at different sizes/resolutions and in alternate UAs like screen readers.

Exactly this. People need to think critically and not just blindly follow whatever some popular bloggers are saying.

It's the same today though - half of HN is utterly convinced rebellious technologies like HTMX are going to save us from the evil of front-end libraries. People adopt guides or entire technologies without ever actually building something significant with them.

When people say not to use tables they mean <table><tr><td>for layout of the entire page</td></tr></table>

> they mean

They shouldn't had mean, they should had said that.

Because 99% of time we have a bunch of <p> in assortments of <div> representing a tabular data. Dozens of "web" "front-end" "frameworks" doesn't help it in any way, too.

Yes, table for layout and table for tabular data is different things. This was usually very clear in advices. Don't use <table> for layout. DO use <table> for tables.

They should not have advised against that either.

It was a much saner, simpler, and more efficient mechanism that the clear/float monstrocities imposed upon people in the period before grid, which reinvented the same thing (table layout) just without the actual tags.

You could use ‘display:table’ in CSS if you wanted a tabular layout without using the table-tags. This has been part of CSS for 25 years.

Grid is newer and more powerful.

display:table was never really evangelized for tabular layout. They were pretty much ignored and the literature and documentation missed the point. Tabular layout is really just another word for grid layouts. Grid layouts took forever to arrive. Tables were the only reliable way lay things out in a grid for a very long time and yet were discouraged regardless. There were people who knew about display:table and used it and some of us were nevertheless told we were doing it wrong because people got hung up on the word table.

Like many things in CSS features that should have been present in the original 2.0, when it became clear that the web wanted to be laid out like a magazine, Took multiple decades to actually appear. As a result we are still seeing the fallout of those failures in our ecosystem.

Sorry are you saying ‘display:table’ was not viable for grid-like layouts because someone might confuse it with the html <table> tag?

That is like saying Go is not a viable programming language because someone might confuse it with GOTO and consider it harmful.

I'm saying that CSS has always had really confusing messaging around what is considered good practice and what is considered bad. If CSS had actually had the equivalent of Go's stdlib and documentation with well established good practices that were pragmatic we would be having a very different conversation right now.

and instead we have a clusterfuck of <div> with tons of attrs.

This very website is built entirely on tables.

(which, unfortunately, is why is has terrible zoom support)

Tables usually have much better zoom support than css hacks of old...

Also, I often use 'zoom text only' in Firefox... that causes havoc on some sites. Also, I disable web site fonts by default.

Reply on news.ycombinator.com