Live data from Hacker News

Incomplete list of mistakes in the design of CSS

wiki.csswg.org

131–132 of 132 posts

Re: Incomplete list of mistakes in the design of CSS

#131

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

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 i…

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.

Re: Incomplete list of mistakes in the design of CSS

#132
post #7

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"

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.

An excellent illustration of the German word "verschlimmbessern"
Post reply on HN