I will never understand the bizarre scene of the web's smug collective declaration that tables were dead and not to be used juxtaposed against the years it took to regain the ability to reliably center things. Assuming one agrees that we even did regain it.
Related: I also love when I can't paste tabular data into Excel/etc. anymore
For the record, I don't hate the idea of stylesheets, but...sheesh
> The display property should be called display-type.
More importantly to me, "display" has been overloaded with two meanings: Display of the element this rule applies to/how it interacts with surrounding elements (none, block, inline, inline-block) and display of the contents of this element (flex, grid).
Which is why we now also have inline-flex and inline-grid.
Default heading styles should not have equal top and bottom margin. Headings should be closer to the content they label than to the content they are setting their content apart from.
h1, h2, h3 should not have different styles. it's an anti-pattern that leads to broken accessibility
This felt relieving. As in: some part of me had felt stupid for thinking some of this seems really unintuitive when using it in practice. Like z-index stuff, margins, vertical-align, border-radius, ...
Meanwhile, one of the linked pages mentioned bluegriffon, so I got curious if such editors can handle template languages such as django's.
While I don't know that yet (edit:no templates at all, what a shame), I also found this tutorial, and it was inspiring that such a pedagogical approach to online authoring still exists.
Edit: no seriously, why don't these editors support at least some established template language? I think dreamweaver had a concept of templates, which made using these editors make at least some sense.
Edit: oh wow dreamweaver still exists. Any of you have experience? Still good?
It is extremely funny to me that the list thinks the mistake about !important was using the exclamation mark sigil, and not the concept of a single priority level.
In the words of one of my CS profs, from a few decades ago: "There are only 3 numbers - zero, one, and infinity. And 'one' is often a mistake"
When I occasionally venture I to standards-land, I always ask "what user research have you done on this?"
So many weird design choices in computing are because one person said "this seems right to me" without considering other viewpoints or consulting with the wider community.
Sure, you probably dont want death by committee, but a tiny cabal engaging in groupthink often produces unhelpful results.
I don't understand the point about comments. Why shouldn't they be allowed? What object model?
>Comments shouldn't have been allowed basically everywhere in CSS (compare to HTML, which basically only allows them where content goes), because it makes them basically unrepresentable in the object model, which in turn makes building editing directly on top of the object model impossible
The greatest mistake IMO is the way float state leaks out of blocks, as this
is both extremely unintuitive and undesirable for performance reasons.[1]
Floats should've been restricted to inline formatting contexts, with all
in-flow blocks behaving as if they had `clear: both' set.
I also don't understand why they never specced the (much simpler)
`text-align: -moz-left/-moz-right/-moz-center' which already had precedent
in HTML with `<div align=left/right/center>'. It's the saddest part of the
"center a div" saga, all the W3C had to do to fix it is to assign a standard
keyword to a feature that everybody already implemented, but to this day
it still hasn't happened.[2]
[2]: After many long decades, they did finally specify block-level
`justify-items'. Two problems: a) it's backwards-incompatible with
text-align, b) it still doesn't work in Gecko.
Are they taking requests? I know just enough CSS to hang myself, but one thing I can never keep straight in flexbox is "align" vs "justify". Could not have used something like "main-axis" or "cross-axis"? Intentionally had to be somewhat obtuse from how it would be used?
> That should be corrected if anyone invents a time machine. :P
Why can't this be dealt with with CSS versioning/features where you can opt into your current-color and a lot of more substantive style behavior while leaving currentColor functional?
- Making elements somewhat act like they are not there should not have been display:none as as display: has other purposes.
- Values for properties with just two valid values available should have been true and false rather than having one more unique word combo to remember forEach.
- I cant quite describe them but float at times has some weird unexpected behavior.
It would be very interesting to see a post-mortem for each of the design mistakes, with links to the original design discussions and docs, and analysis of how the decision-making process went astray.
Just kidding. To me the biggest mistake was the standards' slowness in the early 2010s to provide badly needed new functionality such as a proper replacement for table layout, vertical alignment, etc. The cult of knowing specific tricks to get things working properly carried on for too long and made a lot of people annoyed at the semantic web (rip).
The biggest problem IMHO is how the unit system with regards to pixels and physical units is designed. A px is not a device pixel but a physical unit of length 1/96 inch. This nonsense is technical not a CSS-only thing but based on a 80s hack by Microsoft and Apple. As a result you can not specify device pixel sizes directly, (you have to calculate them from devicepixelratio in js), and physical units relate to UI scaling on screen.
A use case for specifying device pixel sizes are thin-lined grids, that can have inconsistent spacing and line width due rounding when you use px on hi-DPI.
How it should be (and OSes should do it) is:
- There is the device pixel e.g. "dp"
- There is a UI scaling unit "u" (the equivalent to CSS px, but not with a misleading name). It could be e.g. defined to be the height of a standard button. This is used for most screen-oriented elements, and u-based sizes can be optionally rounded to whole dp.
- There are physical units independent of u. There is a ratio of these to dp. For print the ratio is e.g. so that 1in = 300dp if it is a 300dpi print. For screen the ratio is based on the actual physical pixel density the OS can either derive from a display device, or the user calibrates it. Physical unit based sizes can optionally be rounded to whole dp.
- The user can obviously set the UI scaling and overwrite the physical unit scaling.
This way you can get display pixel based sizes simply and reliably, UI scaling is not based on a often misunderstood "virtual pixel", and physical objects can be displayed on screen with its actual size (or whatever scaling the user wants).
Incomplete list of mistakes in the design of CSS
(wiki.csswg.org)193 points by OuterVale 11 December 2025 | 128 comments
Comments
Related: I also love when I can't paste tabular data into Excel/etc. anymore
For the record, I don't hate the idea of stylesheets, but...sheesh
More importantly to me, "display" has been overloaded with two meanings: Display of the element this rule applies to/how it interacts with surrounding elements (none, block, inline, inline-block) and display of the contents of this element (flex, grid).
Which is why we now also have inline-flex and inline-grid.
Edit: Apparently we can now arbitrarily combine inline/block and flex/grid as two values to "display", no idea when this happened: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...
Default heading styles should not have equal top and bottom margin. Headings should be closer to the content they label than to the content they are setting their content apart from.
h1, h2, h3 should not have different styles. it's an anti-pattern that leads to broken accessibility
Meanwhile, one of the linked pages mentioned bluegriffon, so I got curious if such editors can handle template languages such as django's.
While I don't know that yet (edit:no templates at all, what a shame), I also found this tutorial, and it was inspiring that such a pedagogical approach to online authoring still exists.
https://www.thesitewizard.com/bluegriffon/bluegriffon-2-tuto...
Edit: no seriously, why don't these editors support at least some established template language? I think dreamweaver had a concept of templates, which made using these editors make at least some sense.
Edit: oh wow dreamweaver still exists. Any of you have experience? Still good?
In the words of one of my CS profs, from a few decades ago: "There are only 3 numbers - zero, one, and infinity. And 'one' is often a mistake"
So many weird design choices in computing are because one person said "this seems right to me" without considering other viewpoints or consulting with the wider community.
Sure, you probably dont want death by committee, but a tiny cabal engaging in groupthink often produces unhelpful results.
>Comments shouldn't have been allowed basically everywhere in CSS (compare to HTML, which basically only allows them where content goes), because it makes them basically unrepresentable in the object model, which in turn makes building editing directly on top of the object model impossible
I also don't understand why they never specced the (much simpler) `text-align: -moz-left/-moz-right/-moz-center' which already had precedent in HTML with `<div align=left/right/center>'. It's the saddest part of the "center a div" saga, all the W3C had to do to fix it is to assign a standard keyword to a feature that everybody already implemented, but to this day it still hasn't happened.[2]
[1]: https://pcwalton.github.io/_posts/2014-02-25-revamped-parall...
[2]: After many long decades, they did finally specify block-level `justify-items'. Two problems: a) it's backwards-incompatible with text-align, b) it still doesn't work in Gecko.
Why can't this be dealt with with CSS versioning/features where you can opt into your current-color and a lot of more substantive style behavior while leaving currentColor functional?
- Values for properties with just two valid values available should have been true and false rather than having one more unique word combo to remember forEach.
- I cant quite describe them but float at times has some weird unexpected behavior.
https://stackoverflow.com/questions/23154201/weird-behaviors...
If the mentioned mistakes or similar language design mistakes were made. Because mistakes will always be made.
(Unison lang comes to mind but it’s refactor failsafe seems narrow. How about: Antifragile language design? Self-correcting language?)
Just kidding. To me the biggest mistake was the standards' slowness in the early 2010s to provide badly needed new functionality such as a proper replacement for table layout, vertical alignment, etc. The cult of knowing specific tricks to get things working properly carried on for too long and made a lot of people annoyed at the semantic web (rip).
They do with left+right, and have done this for a very long time. You only get the anchoring if you additionally set width.
A use case for specifying device pixel sizes are thin-lined grids, that can have inconsistent spacing and line width due rounding when you use px on hi-DPI.
How it should be (and OSes should do it) is:
- There is the device pixel e.g. "dp"
- There is a UI scaling unit "u" (the equivalent to CSS px, but not with a misleading name). It could be e.g. defined to be the height of a standard button. This is used for most screen-oriented elements, and u-based sizes can be optionally rounded to whole dp.
- There are physical units independent of u. There is a ratio of these to dp. For print the ratio is e.g. so that 1in = 300dp if it is a 300dpi print. For screen the ratio is based on the actual physical pixel density the OS can either derive from a display device, or the user calibrates it. Physical unit based sizes can optionally be rounded to whole dp.
- The user can obviously set the UI scaling and overwrite the physical unit scaling.
This way you can get display pixel based sizes simply and reliably, UI scaling is not based on a often misunderstood "virtual pixel", and physical objects can be displayed on screen with its actual size (or whatever scaling the user wants).
I wish that one were we elaborated on more :)
You should be able to write
<div color="red" font-weight="bold"/>
Instead of
<div style="color: red; font-weight: bold;"/>