Incomplete list of mistakes in the design of CSS

Posted by OuterVale 1 day ago

Counter189Comment123OpenOriginal

Comments

Comment by anonymars 1 day ago

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

Comment by Angostura 1 day ago

> Related: I also love when I can't paste tabular data into Excel/etc. anymore

Except that’s exactly where tables should be used. So if you can’t, someone has really misunderstood CSS.

Use it for tables, not for layout.

Comment by wanderingstan 23 hours ago

I’ve gotten in several arguments over the years where webdevs insisted on showing tabular data using flexbox or hardcoded div widths or worse. They insisted that html tables were never ever to be used and couldn’t be persuaded.

Comment by idbehold 22 hours ago

If you try to render tables with millions of cells the browser does a really poor job and the performance is abysmal. The only solution when you need to render that many cells is to virtualize the table and only have the visible cells (plus some buffer) actually in the DOM at a time. That plus weird restrictions browsers put on certain table elements (looking at you thead) that prevent them from being "sticky" headers means that the developer is left with absolutely positioned divs as the only solution. Blame browser vendors for not providing a native way to present tabular data with more than a few hundred thousand rows without causing performance issues.

Comment by pornel 20 hours ago

there's table-layout:fixed that makes rendering of large tables much faster.

I'd argue that if you have so many rows that DOM can't handle, humans won't either. Then you need search, filtering, data exports, not JS attaching a faked scrollbar to millions of rows.

Comment by MrJohz 22 hours ago

In fairness, the default `display: table` setup is often a pain to work with, so I can understand why people would opt for flexbox instead. One better option, though, might be to use `table` elements under the hood, styled with `display: grid` (and judicious use of subgrid for the intermediate elements) to get more precise control over the layout, while still using the right semantic elements underneath.

Comment by pornel 19 hours ago

They are wrong, and didn't get the point of separating semantics and presentation.

Comment by xboxnolifes 1 day ago

I think it was advised a bit too early, but ever since flexbox entered the scene, tables for page formatting became irrelevant.

And just in case, nobody ever said tables were dead. Tables were declared bad practice for page formatting, not for tabular data.

Comment by cluckindan 1 day ago

Do not use flexbox for page layout. It invites nested flexboxes, which eats your reflow performance.

Use grid instead.

Comment by easyThrowaway 1 day ago

Not the first time I hear of this, but I thought it was a blink-specific issue when using severely nested structures (e.g., html pages written using visual editors like Elementor or Webflow)?

Comment by throwaway77385 1 day ago

For quite a while, I had to keep using flexbox instead of grids, because grids killed performance, funnily enough. That seems to have been rectified with modern browsers though, funnily enough.

Comment by twsted 1 day ago

Useful insight: any sources?

Comment by dekoidal 1 day ago

From 2014 https://jakearchibald.com/2014/dont-use-flexbox-for-page-lay...

Comment by wk_end 1 day ago

Browser performance tips from 2014 mean very little twelve years on. Not only have machines gotten faster and networks gotten faster, rendering engines gotten faster. And I'm doubtful it nested flexboxes would've been all that much of a problem in most cases even then.

The most important thing is to use the right tool for the job. If grid lets you express what you want in the most straightforward way, use it; if flexbox does - even if it needs nesting - then use it instead. Don't shoehorn one into a situation where the other makes more sense. And sometimes either will work for a particular situation and that's fine too; use whatever you find most ergonomic. They're both very good in their own way.

Comment by mananaysiempre 1 day ago

The article is largely about layout shifts caused by flexbox during loading, and while networks have indeed gotten faster, they haven’t gotten faster uniformly across situations and people. Being able to show things properly while they are still downloading remains useful.

Comment by cluckindan 1 day ago

Try resizing a browser window with nested a flex layout.

Comment by tim1994 1 day ago

Should you optimize for resize performance? I guess that depends on the app. Use the tool that fits the requirements.

Comment by cluckindan 1 day ago

Resizing is not the optimization target, it just makes reflow performance visually apparent.

Comment by zwnow 1 day ago

Flexbox is great and having nested flexboxes is also great. It makes building responsive pages a bliss. Learn it if you are having trouble with it, it is really not that difficult. Grids are much more error prone and allow for much less flexibility.

Comment by rcxdude 1 day ago

Even for layout, CSS took a long time to catch up with tables in some areas. Tables were not designed for layout, but there's a lot of aspects to them which are easier to grasp and work with than trying to get the same effect with early CSS.

Comment by KevinMS 1 day ago

They shamed everybody into the torturous use of floats for layout and then eventually, about 15 years later, added layout features back into a layout language.

Comment by lucideer 1 day ago

> I will never understand

I think it's fairly easy to understand if you understand what it was a backlash against. Tables today are used sensibly, for the most part, but the pre-CSS world was truly absurd in its table use.

The reaction may well have been over-the-top, but it wasn't disproportionate given the state of table usage at the time.

CSS's initial forays into layout seem bad today because people think of tables in terms of their intended use (not the now long-gone monstrosities the community actually extracted from them), but in comparison to the previous ecosystem, floats were a relative godsend.

Comment by wongarsu 1 day ago

Tables as a layout primitive are fine. Lots of modern layout engines are based around vstacks and hstacks, which are just single table rows and columns. Most paper forms use a 2d table layout, and newspapers arrange their articles in a 2d table layout.

There were some reasonable concerns. Using tables for both layout and literal tables removes semantic meaning, nested tables can get complicated to layout, and layout the whole page as a giant table makes it difficult to adapt to screen size. But the first could easily be solved by adding a tag that works exactly like table but is for layout, the other two are about overuse of tables in the absence of viable options. We could have easily kept table layouts for the parts where it makes sense and augmented it with something css-like for the parts where it doesn't.

Comment by mrdatawolf 16 hours ago

Thanks, I was going to say the same thing. The developer cultural context, back then, really matters.

Comment by PunchyHamster 22 hours ago

This is somehow worse than "never use goto"; because there are plenty of good uses for tables, and CSS was lacking features for forever after the clowns declared "tables bad" and the other clowns followed without thinking

Comment by erfgh 1 day ago

The killer argument at the time (and even now most likely) is that screen readers could not distinguish whether the table was used for layout or for data and therefore sight-impaired users would have trouble.

The argument doesn't make sense because it is not too hard for a screenreader to understand whether a table is used for layout and even if it was hard the problem would more easily be solved by just adding an attribute to the table to indicate that it is used for layout.

Comment by afavour 1 day ago

Tables aren’t dead, they never were… when displaying tabular data. When it comes to layout I think you might be wearing rose tinted glasses. Remember having to put a 1px image in a table cell to avoid it disappearing? Remember “best viewed at 800x600”? I’m personally not nostalgic for either.

Comment by tobr 1 day ago

For what it’s worth, the very page we’re on here still uses tables and spacer gifs, in 2025. (EDIT: I don’t mean to imply that this is good, just an inescapable observation in this context)

Comment by Popeyes 1 day ago

Probably why there are endless reworkings of the site.

Comment by anonymars 21 hours ago

I imagine it's also why its size is measured in kilobytes and loading time in milliseconds

Comment by erfgh 1 day ago

There were better solutions to those problems than the CSS debacle.

Comment by eviks 1 day ago

> Remember having to put a 1px image in a table cell to avoid it disappearing

Isn't this a trivial problem to solve that doesn't require introducing any new layout mechanisms?

Comment by dahcryn 1 day ago

at least they were specific

Today it's usually implicitly designed for iphone, designed for 1080p, or ipad, and you have to guess, strong correlation with whatever device the designer uses in his personal life.

Comment by afavour 22 hours ago

...no? Today's sites use responsive design and adapt to pretty much any screen size.

Comment by dspillett 20 hours ago

> Today's sites use responsive design and adapt to pretty much any screen size.

Today sites certainly can and some (many) so. But some (also many) definitely don't…

A lot are locked to a maximum width, which is OK enough as l……o……n……g lines of text are unpleasant to read, but only because browsers hack the meaning of dimension settings to make text zoom work consistently.

A lot also have an effective minimum width (even if they use responsive styling to move/ minimise/hide side decoration before a certain point) that is not always convenient. Try browsing with a thin window so you can have something in the other side of your screen. Some assume no one on desktop will ever have a browser window less wide than 1280 pixels (or equivalent on a zoomed higher res screen) - not the case on my 1080p portrait screen and I sometimes want things thinner than 1280 on my 2560x1440 screen. You could say I'm just odd and they can't cater for everyone, but 1080 or a bit less wide is hardly miles away from many devices physical layout so if a design can't display nice in that can it really call itself "responsive" (I suspect any such design would fail on many mobile devices too - 1080px effective width is rather common there, as are smaller widths).

Comment by agumonkey 1 day ago

sidenote: as a teen, i would regularly layout posters and presentations in excel.. the page preview dashed-border and the grid stability was such a relief compared to word

Comment by 6510 1 day ago

On commodore 64 the screen is just a fixed size grid of characters. No one ever had issues making an ui. We pretend but flexible viewport size is not actually possible. If you are making a painting for example the size of the canvas greatly influences what can and can be done.

I made a stunning landscape photo one time that looked great only when displayed at roughly the size of a hand. If made larger undesirable details became visible (littering), when smaller important details were lost (a formation of birds over a fishing vessel).

Comment by oneeyedpigeon 1 day ago

> We pretend but flexible viewport size is not actually possible.

Not beyond a point, but it's still very useful to be flexible up to that. For example, I'm very grateful that a web page will reflow text rather than print everything on one line and force horizontal scrolling.

Comment by Timwi 1 day ago

Yet, for some reason, mobile browsers do not reflow when you zoom in, but instead insist on horizontal scrolling, unlike their desktop counterparts. I've never understood that.

Comment by hypertele-Xii 23 hours ago

Firefox has a "Desktop site" switch that when disabled changes this behavior.

Comment by Vinnl 1 day ago

> the ability to reliably center things. Assuming one agrees that we even did regain it.

Is there anyone who does not agree that we can reliably center things in CSS nowadays?

Comment by pglevy 23 hours ago

At least one person. https://tonsky.me/blog/centering/

Comment by Vinnl 23 hours ago

Haha fair, we do still suck at properly centering text, I'll give you that.

Comment by ModernMech 1 day ago

My favorite part about that is how we came back around to display:grid

Comment by windows2020 1 day ago

Until then, display: table kept everyone calm.

Comment by spartanatreyu 1 day ago

No, dealing with tables was like trying to build a house out of tempered glass.

With css grid, I can tell each element which area or column+row to occupy.

If I add or remove a random element, the rest of the elements stay in the correct place.

But do that with a table and you end up trying to glue your house back together shard by shard whilst trying not to cut yourself or breaking things more.

Comment by friendzis 1 day ago

> If I add or remove a random element, the rest of the elements stay in the correct place.

This complaint highlights how absurdly not fit-for-purpose html+css actually is. Okay, you may want to do "responsive" design, but you have the semantic layout fixed, therefore you try and contort a styling engine into pretending to be a layout engine when in reality it is three stylesheets in a trenchoat.

Comment by pbowyer 1 day ago

> Okay, you may want to do "responsive" design, but you have the semantic layout fixed, therefore you try and contort a styling engine into pretending to be a layout engine when in reality it is three stylesheets in a trenchoat.

I need to write this up properly, but one of my bugbears with responsive design is that it became normalised to push the sidebar down below the content on small screens. And if you didn't have a sidebar, to interweave everything in the content no matter what screensize you were viewing on.

What I want is a way to interleave content and asides on small screens, and pull them out into 1+ other regions on larger screens. Reordering the content on larger screens would be the icing on the cake but for now I'll take just doing it.

This CSS Grid approach adds gaps: https://codepen.io/pbowyer/pen/azNarbZ

Using named grid-template-areas stacks the items you move to the sidebar on top of each other, so you only see one of them.

'Good' old floats get most of the way, but put the item in the sidebar exactly where it falls. Plus they're a pain to work with overall: https://codepen.io/pbowyer/pen/jEqdJgP

Comment by bryanrasmussen 1 day ago

>This complaint highlights how absurdly not fit-for-purpose html+css actually is. Okay, you may want to do "responsive" design, but you have the semantic layout fixed,

this not fit for purpose may in fact be historically superseded usages that still are baked in to some usages affected by the relatively rapid change of the various platforms that must interact and use the respective technologies, the specification version of "technical debt"

that is to say some subsets of the numerous technologies can be used to construct something fit for the purpose that you are describing, but as a general rule anything constructed in a solution will probably be using other subsets not fit for that particular purpose, but maybe fit for some other purpose.

Comment by 6510 1 day ago

I try to politely debate the proponents with each hype cycle giving them the benefit of the doubt. They lost the "lets get rid of tables" debate quite miserably. I would quickly slap something together in jsfiddle, they would try recreate it. Adding some col- and/or rowspan programmatically for cells with the same value. Give an rgba color to rows and nth cells (columns). Resizing columns by size of cell content. It took tons of ugly css to replicate. Pasting the table into a wysiwyg editor is something they can never hope to re-create.

Usually I declare victory when they say that tables might get depreciated in the future.

They at one point really wanted to get rid of framesets. I asked how to make the classic scrollable resizable side top bottom UI in pure CSS. We've tried for hours, everything we tried looked ugly and didn't fully work. framesets are here to stay now :)

I still have one of the funnier "how to make this without tables?" challenges. It's not a very good example of the use of tables but did make me laugh.

https://go-here.nl/omg-tables.html

Comment by bryanrasmussen 1 day ago

>Give an rgba color to rows and nth cells (columns).

that sounds like a use for tables, so I find it difficult to imagine a non-table layout that would want this.

>Resizing columns by size of cell content.

I can sort of see this as a requirement for non-table layouts that would not work well, however my experience from table time was that was one of the biggest irritants at least for me, that columns would haphazardly resize based on what was in them, and sometimes you wanted them to and sometimes not. As a general rule I found it better design wise to truncate text rather than have things expanding and contracting in response to what copy editors were doing.

>framesets are here to stay now

woo yeah, I see them a lot in the wild. I mean really the only time I really see frames used anymore are iframes and generally in eCommerce and similar security requiring solutions where the frame can be partially controlled by the storefront, but is more fully controlled by the payment provider. I just find the statement "framesets are here to stay now" really weird and triumphal for something that is so rarely used?

>I still have one of the funnier "how to make this without tables?" challenges.

I followed the link, I would think it is better suited to a "why would you make this" challenge. I'm not sure

1. it shouldn't be a table. seems like maybe it should be

2. why the freaky animation. or for that matter why the animation nearly crashed my browser.

I'm definitely sure lots of designs could not be adequately achieved without tables and framesets, but my experience seems to have run contrary to yours because for me CSS was a godsend in fixing the things I found irritating about those two technologies, this does not mean that I never encountered situations where I thought this would be easier with tables, but as soon as I tried putting tables back in I found all those irritants came back in.

From my experience tables and framesets were best suited to layouts that are rarely ever wanted, and when used to implement slightly different layouts had too many problems and irritants to be useful.

Your mileage has obviously differed, but I'm not sure that "here is a particular problem that people seldom wish to solve and which I have constructed, that plays to the strengths of my favored technology while avoiding its pitfalls" is as impressive an argument as you seem to think it is.

Comment by Izkata 1 day ago

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

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

Comment by nfw2 1 day ago

I'd like to propose for the list:

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

Comment by 0xfffafaCrash 1 day ago

moreover h* is just broken whenever dealing with more dynamic content — it simply can’t reasonably be made to work according to accessibility recommendations — and the accessibility guidelines around never skipping a level themselves are ridiculous given the practical reality that dynamic content exists and we have only h1, h2, etc. to work with — the readers and specs are what need to adapt here, not the entire internet

there should really be one header tag and its level should be based on some nesting depth

and don’t get me started on the maintainability mess that is z-index… better we have a system to centrally maintain an ordering list than a distributed one which only works reasonably consistently if you already know everything in the whole system

Comment by webstrand 1 day ago

I like how z-index works, currently. And though I agree with the article, it should apply to all elements by default, I'm not sure how you'd do stacking differently in a way that'd work any better than the current situation?

You can't do away with stacking contexts, you need those to isolate content you don't control to prevent it from breaking the stacking order of content you do control.

I completely agree with you about h* tags, though. I wish html5 sectioning hadn't been killed by the browser vendors. As is there's no safe way to put headings inside custom elements. We almost had it, it was specified and everything.

Comment by nfw2 1 day ago

The problem with trying determine heading depth automatically is the depth is not something that can be deduced just by the structure. If headings are siblings, for example, the may be on the same level semantically or not.

One way I've dealt with this in react is combine a Heading component with ContentGroup component. Each content group needs exactly one heading, and heading can't exist without it. Content group can contain other content groups. The tag for heading can then be determined by how many content groups are in the tree above it.

This works pretty well ime, but it can be hard to get devs to use (or think about accessibility at all).

Comment by wongarsu 1 day ago

That's how html should have been designed from the start. HTML is originally designed as a very flat hierarchy, e.g. h1 p p p h2 p p h2 p p h3 p h2 p just following each other. When really it would make much more sense to have h{p p p h{p p} h{p p h{p}} h{p}}.

Comment by yiiii 23 hours ago

That's what sectioning elements [1] like <section> and <article> where once introduced.Opposite to just using <div> elements their purpose was to create a real document outline, where it would have been possible to only use <h1> and their level would be determined by how deep the section is nested, but this approach was never really adapted.

[1] https://www.w3schools.com/html/html5_semantic_elements.asp

Comment by wavemode 1 day ago

That's sensible, but I think default styles for specific elements are not part of the CSS standard, and are instead dictated by the user-agent stylesheet of your browser.

Comment by quirino 1 day ago

This "headings closer to the content" suggestion is very good.

I came across it when reading Butterick's Practical Typography and it's possibly the lowest effort/clearest improvement guideline in the book.

Now I can't unsee websites that do it wrong.

Comment by IshKebab 1 day ago

> h1, h2, h3 should not have different styles. it's an anti-pattern that leads to broken accessibility

How does that hurt accessibility? Are you saying people use h3 in order to get its style even when they didn't mean h3?

I think the opposite could happen too - if they all have the same style then people might just use h1 everywhere which is probably just as bad. People tend not to use elements that have no obvious use, like <output> which apparently has better accessibility but does absolutely nothing else, so nobody bothers. The whole "semantic web" thing failed partly because of this.

Comment by nfw2 1 day ago

> Are you saying people use h3 in order to get its style

yes, and that people assume the purpose of having different tags is to control styling

Comment by IshKebab 22 hours ago

I mean, they aren't wrong. That is part of the purpose. Of course now we try and do it via CSS but it's definitely still fine to use <b> as bold and <i> as italic, even if the semantic pedants will insist that they mean "Bring attention to" and "Idiomatic" (that name's stretched so thin you can see through it!).

Comment by savolai 1 day ago

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.

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?

Comment by edent 1 day ago

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.

Comment by pornel 19 hours ago

Many of these mistakes weren't even made by any committee, but were stuff shipped in a rush by Netscape or Microsoft to win the browser wars.

There was some (academic) reaserch behind early CSS concept, but the original vision for it didn't pan out ("cascading" was meant to blend style preferences of users, browsers and page authors, but all we got is selector specificity footguns).

Netscape was planning to release their own imperative styling language, and ended up shipping a buggy CSS hackjob instead.

Once IE was dominant, Microsoft didn't think they have to listen to anybody, so for a while W3C was writing CSS specs that nobody implemented. It's hard to do user research when nothing works and 90% of CSS devs' work is fighting browser bugs.

Comment by Timwi 1 day ago

This is true, but my feeling is that with CSS, a lot of the weird decisions are for backwards compatibility with way back when HTML was just tag soup and browser implementations were haphazard.

Comment by mcphage 21 hours ago

This feels like the origin of a lot of these mistakes (and more besides): they weren't based on "what is it that lots of real designers are actually trying to accomplish?". Why did it take so long to get support for pinstriping, when prior to that there were 1001 different ways to try and accomplish it, because so many people wanted it? Why did it take so long to get layout functionality that even just matched the power of what CSS was intending to replace? Or vertical alignment, or drop shadows, etc, etc, etc. I like CSS and the intentions of it, but man, it was designed from a place of having no idea what people wanted to do.

Comment by yread 1 day ago

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

Comment by recursivecaveat 1 day ago

Imagine you have something like `width /comment/: /comment2 /12px /comment3/,`. Now you want to load your css into some kind of structured representation, rearrange it, then spit it back out again with that comment intact. The requirement to represent such comments in your structured format so you can retain them is really obnoxious. In html you can just view comments as another node in a uniform tree.

Comment by IshKebab 1 day ago

> In html you can just view comments as another node in a uniform tree.

When you parse an AST with comments (or a CST), they do become "just another node in a uniform tree". Think about it - in HTML you have a tree of nodes but comments can be anywhere, which is exactly as obnoxious to deal with as a CST where comment nodes can be anywhere.

This is a terrible reason to not support comments. If it was really important, then probably you should support comments in only a couple of places, e.g. on attributes or on selectors.

But I don't think it is very important. I can't think of a single tool that loads CSS, rearranges it, and then spits it back out in a form that would benefit from comments.

Comment by matt_kantor 20 hours ago

> in HTML you have a tree of nodes but comments can be anywhere

Maybe I'm misunderstanding, but no they can't. For example the comment here is not a comment, but part of the URL:

    <a href="https://example.com<!-- comment -->">click me</a>
And HTML like this is simply broken:

    <div<!-- comment -->>content</div>
Maybe you meant "they can be anywhere that a Node can be in the DOM", but I think that's more or less what the CSS "mistake" is suggesting should be true about CSS (just replace "DOM" with "CSSOM").

Comment by IshKebab 19 hours ago

Yes, anywhere in the node tree. Imagine if CSS was specified in HTML-style. We might write this selector:

  h1,
  /* don't forget h2! */
  h2 {
    color: /* I love red */ "red";
  }
Like this:

  <rule>
    <selector>
      <alternative>
         h1
      </alternative> <!-- don't forget h2 -->
      <alternative>
         h2
      </alternative>
    <selector>
    <attributes>
      <color><!-- I love red --> red</color>
    </attributes>
  </rule>
Which is pretty much exactly the same as what you'd get as a CST from parsing the CSS.

Comment by matt_kantor 18 hours ago

Problem is, the CSSOM models that more like this:

    <rule selector="h1, h2">
      <style>
        <property name="color" value="red" />
      </style>
    </rule>
Perhaps your takeaway from this is "the CSSOM is bad" (and I don't necessarily disagree), but it's what the "mistake" is talking about.

Comment by IshKebab 13 hours ago

I wouldn't say that, it's more that the CSSOM doesn't try to preserve comments, which is a perfectly reasonable thing to do. I think most uses cases for modifying CSS that care about comments (e.g. auto-formatters?) would need parsers that return the full CST anyway.

Comment by matt_kantor 12 hours ago

I see. I was under the impression that you were saying the "mistake" from the post was wrong in its premise. But I guess that's incorrect, rather you think that people shouldn't use the CSSOM for use cases when comments matter, and instead they ought to design their own parsers/representations.

Just curious: do you feel the same about HTML? Should HTML allow comments in more places? I can imagine alternate ways to represent an HTML document that could capture comments within attribute lists, etc (and the DOM could exclude them entirely).

Comment by IshKebab 5 hours ago

Nah I think HTML comments are fine. I don't think there would be a benefit to allowing comments in more places and it would make it more annoying when you actually do want to process comments.

If CSS had mandated that comments could only appear in certain places (e.g. before a rule or attribute) I think that would have been fine too, though maybe slightly confusing given the resemblance to C-style comments which are allowed almost anywhere.

Comment by matt_kantor 21 minutes ago

Seems like we have broadly-similar perspectives, though I do find it a bit incongruent that the DOM preserves comments while the CSSOM doesn't. It feels like they ought to be in alignment one way or the other (though I also understand the historical reasons why they aren't).

Comment by wedg_ 1 day ago

I'm guessing they mean that comments shouldn't be allowed everywhere, not that they shouldn't be allowed at all? i.e. CSS lets you put comments in many more places than HTML, in such a way that it's hard to practically impossible to represent in an AST? At least that's how I read it

Comment by systoll 1 day ago

The CSS Object Model.

HTML comments are basically just a HTML tag that isn't rendered. Tools that 'compile' the HTML code into a document tree, including browsers, preserve comments as nodes without any extra effort.

CSS comments can go anywhere:

    /*wow*/ .selector /*x*/ {animation /*z*/: 2s /*z*/ linear /*z*/ bounce;}
Tools that transform/parse CSS can either: 1. Strip comments before parsing, meaning anything based on the parsed version will lose the comments. 2. Dedicate a disproportionate amount of complexity to retaining the comments, and still not really have a good way to handle them through edits/transformations.

Comment by yread 1 day ago

But if it's valid CSS it has to be representable in AST/object model? It's a comment, it can't have any child nodes, it doesn't depend on anything - pretty trivial. And if it's in the tree you can transform it with proper tools. If you are transforming CSS you have to write a proper parser and not just a bunch of regexes

EDIT: also why is it useful to have comments in the object model in the first place? To access them from js?

Comment by nialse 1 day ago

Round-tripping to CSS and keeping information that may be useful to the user if they would inspect the content I would presume.

A similar issue is CDATA in XML which is not retained when round-tripped. Very annoying, but in line with the spec.

Comment by DonHopkins 22 hours ago

Same reason why JSON prohibits comments: When you parse it, there is no place to represent the comments in the JavaScript object and array tree, so they must be thrown away, therefore it's impossible to write it out with the same comments in the same places.

Same thing with white space: JSON can not round trip white space or comments the way XML or HTML can, because XML and HTML DOM represents comments and white space explicitly.

Also you can't put comments inside elements like <div <--! comment --> class="foo">. There is no way to represent a comment inside an element in XML or HTML DOM.

But CSS lets you, so you can't round trip comments in CSS.

Comment by shiomiru 1 day ago

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]

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

Comment by 3eb7988a1663 1 day ago

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?

Comment by jdthedisciple 1 day ago

Yea align and justify get me everytime.

I like that in Flutter they do exactly as you suggest: they call it mainAxisAlignment and crossAxisAlignment

Comment by eviks 1 day ago

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

Comment by Timwi 1 day ago

A lot of the behaviors should just have a toggle to turn them off. For example, there are many situations where margin collapsing is in the way and I keep wondering why there isn't simply a `margin-collapse: none`. It would also be nice to have something like `default-styles: none` that will remove all the default styling for h1/h2/etc. and em/strong/cite/etc. so I don't have to deal with browsers having differing defaults.

Comment by shiomiru 20 hours ago

> It would also be nice to have something like `default-styles: none` so I don't have to deal with browsers having differing defaults.

This already exists:

    *, ::before, ::after { all: unset }

Comment by groby_b 1 day ago

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"

Comment by semolino 1 day ago

This is what Cascade Layers was designed to solve:

https://developer.mozilla.org/en-US/docs/Learn_web_developme...

A lingering bit of weirdness is that all !important declarations, no matter the layer they appear on, are interpreted as being part of their own implicit layer.

Comment by dnpls 22 hours ago

There is no need for more priority levels, because precedence is already defined by inline > #ID > .class / [attribute=""] / :pseudo-classes / elements / ::pseudo-element / universal selector (*). And the order they're written, if both have the same priority. The !important just exists to override that order.

Comment by colechristensen 1 day ago

As opposed to the 15 levels of priority available in Chef.

5 different types (default, force_default, normal, override, force_override)

which can be in 4 different places (attribute, node, environment, role) but not all of the types can be in all of the places

PLUS the "automatic" type, which is from somewhere else entirely

Oh and there's inheritance and merging which does not behave intuitively at all because it's not exactly inheritance.

In other words I have early career trauma from someone's extremely unwise priority implementation and am deeply suspicious of ANY priority override system which isn't just code I've written in a normal programming language.

Comment by silverwind 1 day ago

Why not make a opt-in "strict mode" for CSS that fixes all these issues?

Comment by reddalo 1 day ago

Because writing such CSS would lead to broken results on most browsers.

Comment by kjgkjhfkjf 1 day ago

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.

Comment by redbar0n 1 day ago

How could CSS (or any language) have been designed so that these mistakes could have easily been corrected today in any case?

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?)

Comment by MrMetric 1 day ago

Simple: A version specifier, or feature specifiers. Backward compatibility concerns vanish when I can opt-in to a newer spec. Old code keeps working, and new code doesn't suffer for legacy nonsense.

For example, the Circle compiler extends C++ with its `#feature` directive: https://github.com/seanbaxter/circle/blob/master/new-circle/...

Sadly, the closest I've personally seen to this sort of thing in widespread use is `"use strict";` in JavaScript, which is only a single binary switch. You can't, say, turn on a new keyword, disable a keyword, switch to a different incompatible version of some browser API, etc.

I encourage all language designers to include a feature mechanism in a forward-compatible way. Don't overthink the difficulty: It doesn't need to do anything at first, it just needs to not be a parsing error. Treat it like a comment. FYI, this is the same as having a version number or header size in a binary file format's header, which all sane formats have (there are a lot of insane formats out there...).

Comment by felipc 1 day ago

Complete list of mistakes in the design of CSS: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference

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

Comment by Izkata 1 day ago

> Absolutely-positioned replaced elements should stretch when opposite offset properties (e.g. left+right) are set, instead of being start-aligned.

They do with left+right, and have done this for a very long time. You only get the anchoring if you additionally set width.

Comment by kuharich 1 day ago

Past comments: https://news.ycombinator.com/item?id=38363698

Comment by dang 1 day ago

Thanks! Macroexpanded:

Mistakes in the Design of CSS (2013) - https://news.ycombinator.com/item?id=38363698 - Nov 2023 (143 comments)

Incomplete List of Mistakes in the Design of CSS - https://news.ycombinator.com/item?id=25891435 - Jan 2021 (68 comments)

Incomplete List of Mistakes in the Design of CSS - https://news.ycombinator.com/item?id=18297757 - Oct 2018 (150 comments)

Incomplete List of Mistakes in the Design of CSS - https://news.ycombinator.com/item?id=10453850 - Oct 2015 (106 comments)

Incomplete List of Mistakes in the Design of CSS - https://news.ycombinator.com/item?id=7665667 - April 2014 (1 comment)

Comment by sakesun 1 day ago

Wow. An xhtml page.

Comment by chrismorgan 1 day ago

Only in name, not reality: it’s served as HTML. If it had been served as XHTML, they’d have immediately noticed how they didn’t close the meta viewport tag (since it wouldn’t have rendered) and fixed it.

Comment by nrhrjrjrjtntbt 1 day ago

Margin collapse... any good resources on this. Didnt know it was a thing until know but ive seen it happen and couldnt fathom why.

Comment by potato-peeler 1 day ago

Can’t these changes be still done? Maybe within 5-10 yrs these “mistakes” will deprecate eventually.

Comment by the_other 1 day ago

‘text-transform: uppercase’ should be ‘text-transform: UPPERCASE’, for the LOLZ.

Comment by DonHopkins 22 hours ago

Brilliant idea, but "case" is redundant, and upper/lower is incomplete, so there should be:

text-transform: CASE; text-transform: case; text-transform: Case; text-transform: casE; text-transform: cASe; text-transform: CaSE; etc...

I've wanted the latter to write headlines about NeWS and NeXT and NeRF.

Comment by MisterMusion 1 day ago

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

Comment by crazygringo 22 hours ago

Hard disagree. Not having access to true device pixels is a feature, not a bug -- especially when you consider that common screens today range from 90 dpi to 600 dpi. And then not to mention browser zoom on top of that.

Trying to optimize to some kind of perfect pixel alignment shouldn't be a goal anymore. We use antialiasing instead to ensure that widths and weights maintain proportionality no matter what resolution and zoom level you use. Trying to snap to pixels is an anti-feature with modern screens. It made sense when everyone used low-resolution screens and antialiasing wasn't commonly used in OS's and programs. But it hasn't made sense for well over a decade now.

Comment by MisterMusion 22 hours ago

You already have access to device pixels, you just have to calculate it yourself.

Anti-aliasing is not a good solution for orthogonal lines with low device pixel ratios like 1.25 or 1.5. which will be around for a long time. Browsers disagree with you - they don't use anti-aliasing for orthogonal measurements, they round. Which means they do in fact pixel-snap.

I agree that it can be misused like using device pixels for UI, but my suggestions makes the distinction more explicit.

Comment by jan_Inkepa 22 hours ago

>Trying to optimize to some kind of perfect pixel alignment shouldn't be a goal anymore.

If you're trying to display pixel art (or make games with pixel art), being able to have integral upsizing is very useful. Antialiasing doesn't cut it, and the eye notices when you do non-integral nearest-neighbour upscaling and some pixels are the wrong size.

Comment by hoten 1 day ago

> Table layout should be sane.

I wish that one were we elaborated on more :)

Comment by brador 1 day ago

All we had to do was use %s instead of px for distances and this could all have been avoided.

Comment by 6510 1 day ago

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

https://stackoverflow.com/questions/23154201/weird-behaviors...

Comment by TZubiri 1 day ago

Having units for pixels and centimeters, despite not being able to reliably control either of those measurements.

Comment by Devasta 1 day ago

For me, the mistake is having style attributes in html.

You should be able to write

<div color="red" font-weight="bold"/>

Instead of

<div style="color: red; font-weight: bold;"/>

Comment by netsharc 1 day ago

Guess who wasn't around when HTML3.2 was introduced...

How about to control the color of links, add the color attributes for links in body?

https://www.w3.org/TR/2018/SPSD-html32-20180315/#body

Comment by silverwind 1 day ago

These namespaces do not merge cleanly, for example `content`.

Comment by Devasta 1 day ago

Oh for sure, its way way too late to do it, but I don't think much of any of the modern web stack would be kept if we designed in the 90s with what we know now.

Comment by dbbk 21 hours ago

This literally exists. You can use the <font> tag if you really want.