7 ms·

Incomplete list of mistakes in the design of CSS

197 points by OuterVale 10mo ago

edent 10mo 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.
- Timwi 10mo 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.
- mcphage 10mo 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.
- pornel 10mo 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.
kuharich 10mo ago
Past comments: https://news.ycombinator.com/item?id=38363698 https://news.ycombinator.com/item?id=38363698
- dang 10mo ago
  Thanks! Macroexpanded: Mistakes in the Design of CSS (2013) - https://news.ycombinator.com/item?id=38363698 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 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 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 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 https://news.ycombinator.com/item?id=7665667 - April 2014 (1 comment)
nfw2 10mo 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
- quirino 10mo 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.
- 0xfffafaCrash 10mo 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
  - webstrand 10mo 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.
anonymars 10mo 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
- ModernMech 10mo ago
  My favorite part about that is how we came back around to display:grid
  - windows2020 10mo ago
    Until then, display: table kept everyone calm.
    - spartanatreyu 10mo 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.
      - friendzis 10mo 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.
        pbowyer 10mo ago
groby_b 10mo 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"
- colechristensen 10mo 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.
- semolino 10mo ago
  This is what Cascade Layers was designed to solve: https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Styling_basics/Cascade_layers 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.
  - groby_b 10mo ago
    An excellent illustration of the German word "verschlimmbessern"
- dnpls 10mo 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.
savolai 10mo 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-tutorial-1.shtml 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?
3eb7988a1663 10mo 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?
- jdthedisciple 10mo 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
hoten 10mo ago
> Table layout should be sane. I wish that one were we elaborated on more :)
Devasta 10mo 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;"/>
- silverwind 10mo ago
  These namespaces do not merge cleanly, for example `content`.
  - Devasta 10mo 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.
    - dbbk 10mo ago
      This literally exists. You can use the <font> tag if you really want.
- netsharc 10mo 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 https://www.w3.org/TR/2018/SPSD-html32-20180315/#body
sakesun 10mo ago
Wow. An xhtml page.
- chrismorgan 10mo 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.
nrhrjrjrjtntbt 10mo 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.
felipc 10mo ago
Complete list of mistakes in the design of CSS: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference 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).
kjgkjhfkjf 10mo 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.
TZubiri 10mo ago
Having units for pixels and centimeters, despite not being able to reliably control either of those measurements.
silverwind 10mo ago
Why not make a opt-in "strict mode" for CSS that fixes all these issues?
- reddalo 10mo ago
  Because writing such CSS would lead to broken results on most browsers.
eviks 10mo 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?
- Timwi 10mo 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.
  - shiomiru 10mo 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 }
yread 10mo 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
- maattdd 10mo ago
  https://developer.mozilla.org/en-US/docs/Web/API/CSS_Object_Model https://developer.mozilla.org/en-US/docs/Web/API/CSS_Object_...
- wedg_ 10mo 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
- recursivecaveat 10mo 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.
  - IshKebab 10mo 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.
Izkata 10mo 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.
Izkata 10mo 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/Properties/display#syntax https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...
6510 10mo 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-of-css-floating-element https://stackoverflow.com/questions/23154201/weird-behaviors...
shiomiru 10mo 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-parallel-layout-in-servo.html 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.
redbar0n 10mo 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?)
- MrMetric 10mo 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/README.md#versioning-with-feature-directives 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...).
  - childintime 10mo ago
    Backwards compatibility is overrated. It should be future compatibility, so older browsers get to load a shim to implement new features. That way the onus of incompatibility falls on the older browsers, they get slower over time. Newer browsers get leaner. That's what you want.
the_other 10mo ago
‘text-transform: uppercase’ should be ‘text-transform: UPPERCASE’, for the LOLZ.
- DonHopkins 10mo 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.
  - the_other 10mo ago
    That's very neat. You'd probably need two words to represent camelCase. And then that might be hard to disambiguate from your `CaSE`.
brador 10mo ago
All we had to do was use %s instead of px for distances and this could all have been avoided.
MisterMusion 10mo 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).
- crazygringo 10mo 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.
  - MisterMusion 10mo ago
potato-peeler 10mo ago
Can’t these changes be still done? Maybe within 5-10 yrs these “mistakes” will deprecate eventually.

197 points by OuterVale 10mo ago

edent 10mo 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.

Timwi 10mo 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.
mcphage 10mo 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.
pornel 10mo 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.

kuharich 10mo ago

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

dang 10mo ago
Thanks! Macroexpanded: Mistakes in the Design of CSS (2013) - https://news.ycombinator.com/item?id=38363698 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 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 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 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 https://news.ycombinator.com/item?id=7665667 - April 2014 (1 comment)

nfw2 10mo 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

quirino 10mo 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.
0xfffafaCrash 10mo 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
- webstrand 10mo 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.

anonymars 10mo 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

ModernMech 10mo ago
My favorite part about that is how we came back around to display:grid
- windows2020 10mo ago
  Until then, display: table kept everyone calm.
  - spartanatreyu 10mo 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.
    - friendzis 10mo 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.
      - pbowyer 10mo ago

groby_b 10mo 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"

colechristensen 10mo 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.
semolino 10mo ago
This is what Cascade Layers was designed to solve: https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Styling_basics/Cascade_layers 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.
- groby_b 10mo ago
  An excellent illustration of the German word "verschlimmbessern"
dnpls 10mo 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.

savolai 10mo 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-tutorial-1.shtml 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?

3eb7988a1663 10mo 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?

jdthedisciple 10mo 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

hoten 10mo ago

> Table layout should be sane. I wish that one were we elaborated on more :)

Devasta 10mo 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;"/>

silverwind 10mo ago
These namespaces do not merge cleanly, for example `content`.
- Devasta 10mo 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.
  - dbbk 10mo ago
    This literally exists. You can use the <font> tag if you really want.
netsharc 10mo 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 https://www.w3.org/TR/2018/SPSD-html32-20180315/#body

sakesun 10mo ago

Wow. An xhtml page.

chrismorgan 10mo 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.

nrhrjrjrjtntbt 10mo 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.

felipc 10mo ago

Complete list of mistakes in the design of CSS: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference 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).

kjgkjhfkjf 10mo 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.

TZubiri 10mo ago

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

silverwind 10mo ago

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

reddalo 10mo ago
Because writing such CSS would lead to broken results on most browsers.

eviks 10mo 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?

Timwi 10mo 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.
- shiomiru 10mo 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 }

yread 10mo 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

maattdd 10mo ago
https://developer.mozilla.org/en-US/docs/Web/API/CSS_Object_Model https://developer.mozilla.org/en-US/docs/Web/API/CSS_Object_...
wedg_ 10mo 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
recursivecaveat 10mo 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.
- IshKebab 10mo 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.

Izkata 10mo 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.

Izkata 10mo 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/Properties/display#syntax https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...

6510 10mo 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-of-css-floating-element https://stackoverflow.com/questions/23154201/weird-behaviors...

shiomiru 10mo 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-parallel-layout-in-servo.html 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.

redbar0n 10mo 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?)

MrMetric 10mo 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/README.md#versioning-with-feature-directives 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...).
- childintime 10mo ago
  Backwards compatibility is overrated. It should be future compatibility, so older browsers get to load a shim to implement new features. That way the onus of incompatibility falls on the older browsers, they get slower over time. Newer browsers get leaner. That's what you want.

the_other 10mo ago

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

DonHopkins 10mo 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.
- the_other 10mo ago
  That's very neat. You'd probably need two words to represent camelCase. And then that might be hard to disambiguate from your `CaSE`.

brador 10mo ago

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

MisterMusion 10mo 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).

crazygringo 10mo 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.
- MisterMusion 10mo ago

potato-peeler 10mo ago

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