That's because CSS layout was designed by people who thought "float" and "clear" were a good idea, tables were bad, and, when in doubt, make it Turing-complete and dump the problem on someone else.
2D and 3D tools get this right. CAD programs, game engines, and animation programs are all far better at positioning things. They have far better layout engines and constraint systems. This is really a constraint problem. Autodesk Inventor and Fusion 360 have good 2D constraint solvers, ones that can put something on a centerline, or parallel, or whatever, including curve tools. Webland never got that far.
Man... whole generations just straight up either do not realize, or have forgotten that early CSS revolved around creating documents, not apps, and that all of those design paradigms originated from typesetting.
In the same way that one would float a figure to the left or right of lines of a paragraph, `float: left;` and `float: right;` allowed you to do the same.
Open a textbook and look at lines of a paragraph flowing (where content "flow" layout comes from) around a figure, such as an image or a diagram.
The World Wide Web was documents.
In this context, `float` was a genius idea. There's literally no other way in CSS to do this without a bunch of hacks.
Honestly, that itself sounds bad too. The concept of floating sounds like something invented back during manual typesetting or earlier.
I think anyone ever trying to write a paper or book with images in it using tools like LaTeX knows how bad it is to let the tool position images for you. It's always wrong, and one of the first things you learn is how to pin the image in between the text lines/paragraphs you wanted it to be between.
Text-to-diagram tools like PlantUML (and arguably even Graphviz) make this mistake too. The moment you put more than a couple things in your diagram, you discover that auto-layout can't ever make the result readable, and you look for ways to pin parts of the diagram relative to other parts; something these tools don't let you do either.
And then all three classes of tools here - HTML, typesetting, diagramming - violate the principle of least surprise in the nastiest of way: make one little change, add a letter or word somewhere, suddenly the result looks nothing like it was before, as the auto-layouting flips everything around.
A lot could be said. If there's a mistake, it was the economy not providing sufficient resources to solve this problem well. There was certainly awareness of this topic and some attempts to address it (for example North, Stephen C. "Incremental layout in DynaDAG." International Symposium on Graph Drawing, Berlin Heidelberg, 1995, or North, Stephen C., and Gordon Woodhull. "Online hierarchical graph drawing." Graph Drawing: 9th International Symposium, GD 2001 Vienna, Austria, Springer Berlin Heidelberg, 2002.
Successful systems like Tom Sawyer Software or yWorks have dynamic or incremental layout features. The market of course strongly rewarded work on interactive systems like Visio that were well integrated into larger platforms.
Not sure who remembers but high performance incremental constraint-based layout was one of the computer science lights that failed in the 1980s and 90s but with so many fundamental advances in technology (processors, algorithms, solvers, software platforms) and new emphasis on language-based approaches (in part due to LLMs) there might be a better opportunity now.
Anyway it's a hard problem, it's not as if nobody was aware of it.
But that is the fundamental problem behind all of web nowadays: It was initially designed for documents; there are precursors for this entire HTML stuff (hypercards and similar things). Funnily enough, there existed tech even back then that was much much better at dealing with actual applications and their requirements. Unfortunately, many stupid idiots decided to use the "web" for that instead and mangle something aimed at documents to hell and back to actually do apps with it. The amount of time (of humans) and resources (not humans, but computing power, energy, ...) wasted on creating and running kludge after kludge to coerce the "web" into "something for apps" is absolute insanity.
They weren't really idiots, though, that's quite harsh. People wanted to be able to share software but there were so many barriers to entry at the distribution/installation/update phases that they used the solution that didn't require any of that.
It was a hack but it worked better to serve the needs of the users.
Come on, there are so many native cross-platform solutions which are easy to go and much less bloated than web engine, e.g. Qt/GTK+/wxWidgets/Xamarin/etc.
Yes, this is how classic software works. It can download updates in the background, just like e.g. web browsers do. It will be more performant than web apps.
That's quite a lot of extra code to write. Any app you want to share this way now needs to think about networking, self updating, version management etc.
Now take that beautiful application you have made and your customers want, and beg the trolls who sit between you and them for permission to distribute it.
Assuming you get said permission some weeks later, now hand over double-digit percentages of your top-line revenue to these despicable rent-seekers, do the same with your tax payments and notice how you're left with less than 30% of the value you have created.
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.
>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.
> 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.
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, 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).
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.
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.
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??
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.
"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.
> 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.
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.
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.)
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.
>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?
> 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:
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.
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.
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.
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
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.
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.
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.”
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.
> 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 :).
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.
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.
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.
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.
Except for (vector) graphics design, desktop publishing, page layout designing and reporting software...
The reason is of course that most printed items are unica and non-variable, but
proper parametric and constraint-based would definitely be useful in report generation and signage where print formats vary or where designs need to be automatically adjusted based on texts and other content varying in size/length.
Do the tools you say do it better than html also handle the variety of clients html documents are expected to work with? Or handle accessibility better?
XAML/Silverlight was pretty fantastic. Significantly more sane layout model (by virtue of having more than a mote of sanity at all). It did handle a very wide gamut of clients during its time.
Why? Because it was designed for creating apps, not documents. HTML is great for creating documents, most of the examples in the post are not documents.
I don’t think it was that tables were bad. They were too formulaic and too strict and it was hard to do something that would stand out.
With CSS it wasn’t dumping problem on the others, it was giving the freedom. Problem with freedom is that it is never free and you also have to fix additional problems that come with it.
The problem I see with using tables for layout is that it fucks up the semantic meaning of the html file.
But that was an issue of philosophy that got trumped by practical needs.
However, nowadays we have css grids with template areas. So we can just write our HTML semantically correct as if it was more or less just about the content (as it should be IMHO) and still move things around using CSS depending on the type of device, size of screen, media used.
So the holy grail in my opinion is to write HTML that contains only content and metadata and next to no elements or attributes that are needed purely for semantically irrelevant layout and styling purposes — and then do all the layout and styling in CSS. Styling tags like <em> or the occasional <section class="notice"> are okay, one should never be too strict with such ideals.
The advantage here is that this provides the maximum decoupling between the content and the layout/styling which not only helps with future layout updates, but improves the accessability of the page.
One thing I also seem to remember from the very old days, was that browsers wouldn't render the table until it was completely downloaded. So if your whole content was in a table, there would be nothing to see until the whole page was loaded and it could do the layout. But without tables you would see parts pop in as it was loaded.
I've seriously considered doing websites in pdf too but still have to run into a situation dramatic enough for it to be worth it. Now that I think about it again "installing" a pdf on a pc could cover a lot of app like functionality. Most important is to make it as convenient as possible to remember your business exists and interact with it.
active (PDF) documents seem to have become a thing on eReaders, especially pen-based ones; mostly they leverage clever linking and bookmarking, and not much more, though.
I think (despite the article’s digs) iOS had the right idea with everything having a relative layout to parents and siblings. It makes it much easier to know what “center” actually means when you have a notion of what it’s supposed to be centered to.
They probably thought we would ditch HTML/CSS for something better but then PHP came around and fixed many of HTML's shortcomings and then AJAX came around and we kept sinking DEEP into this fundamentally broken ecosystem and now it's just too late to leave.
Although, honestly, how hard would it be for Chrome to support some new language called Super Text Markup Language that is designed for modern use with support for templating, portals, actual semantic layouts that don't rely on position on the code, etc.? Perhaps it's time.
> Although, honestly, how hard would it be for Chrome to support some new language called Super Text Markup Language that is designed for modern use with support for templating, portals, actual semantic layouts that don't rely on position on the code, etc.? Perhaps it's time.
"Google Web". Like what Google did to USENET. First they connected to USENET. Then they called it "Google Groups". Gradually, free USENET declined, and now, there is only Google Groups.
It would be so much more convenient. No more need for hosting providers, domain services, and most of AWS. Just host on Google Web.
It would be very hard and inconvenient to backport indeed. But webdev has moved much away from the initial HTML world anyway, so I believe it might be possible in a completely alternative rendering stack.
Funnily enough, Unity's latest UI approach is to just use web tech, with their 'UML' XML dialect plus CSS-like styling via the yoga embeddable C++ flexbox renderer.
Also, Fusion 360 is now known as just Fusion (it's cleaner that way?)
2D and 3D tools get this right. CAD programs, game engines, and animation programs are all far better at positioning things. They have far better layout engines and constraint systems. This is really a constraint problem. Autodesk Inventor and Fusion 360 have good 2D constraint solvers, ones that can put something on a centerline, or parallel, or whatever, including curve tools. Webland never got that far.