Live data from Hacker News

Mistakes in the Design of CSS (2013)

wiki.csswg.org

11–20 of 147 posts

Re: Mistakes in the Design of CSS (2013)

#11
post #9

> background-position and border-spacing (all 2-axis properties) should take vertical first, to match with the 4-direction properties like margin. I hate that margin / padding short-hands, especially with 2 values, expect vertical first. In my head it's always (x,y) and (width,height) – always horizontal then vertical, I feel like it works like this everywhere else? Now my issue is that I've committed to memory that…

I think there’s a historical reason for this, that probably made more sense back in the 90s … I seem to remember learning computer graphics back then and being similarly frustrated by the reversed notation. My guess is it goes back to raster based calculations where you would go down a number of lines and then across. Oh yea orig is top left rather than bottom left as one would also naturally expect

Re: Mistakes in the Design of CSS (2013)

#12
post #3

The Entire front end web stack looks like a design mistake. Backend looks better only because of the flexibility. You can do anything in the back. But the front you're locked into multi decade old tech and the decade old wrappers written around it.

I disagree. First of all, all of computing is locked into decades-only technology: assembler language and machine instructions. Everything comes down to that whether you write front or back end and regardless of what other "tech" is in the middle. Today, we can do anything on the front end. Some of the most popular and complex apps in history are front end apps made with JS/HTML and web components (Discord, Spotify,…

> assembler language and machine instructions

Except no we're not, new processors bring along new features and drop/discourage old ones, on x86 they even run in different modes depending on requirements, and compilers can choose to target specifically new ones and drop support for older processors without them. This isn't a valid comparison.

I think it's a bad thing because even though "you can do anything" it doesn't mean you can do it well because the web was always designed to be narrow and restricted for privacy/security reasons. That's good, but there's large classes of applications (chat clients, music players, image editors, etc) where that shouldn't be an issue and the costs of running in a web-like environment. Which, even if you drop the security features, manifests as worse UX to users due to the layers of indirection you're dealing with between the developer and the host OS.

Re: Mistakes in the Design of CSS (2013)

#13

Backwards compatibility may be a fundamental design philosophy of the web, but wouldn't it still be possible to support a different document format with a new programming model that gives us a clean break from the past? It's a naive question, I realize, but it's tantalizing to imagine what we could have if we went that route. Then again, the cynic in me thinks we'd just endlessly fight over the design decisions anywa…

You’d have to get people to use it. Like any established warty system, the warts provide just enough of a moat for established practitioners to keep it just the way it is.

Re: Mistakes in the Design of CSS (2013)

#14

Backwards compatibility may be a fundamental design philosophy of the web, but wouldn't it still be possible to support a different document format with a new programming model that gives us a clean break from the past? It's a naive question, I realize, but it's tantalizing to imagine what we could have if we went that route. Then again, the cynic in me thinks we'd just endlessly fight over the design decisions anywa…

That's kinda what something like TailwindCSS is, no? Use their reset & their shorthands, and many of these problems are solved; then your build system translates to the actual CSS standard.

Re: Mistakes in the Design of CSS (2013)

#15
post #13

Backwards compatibility may be a fundamental design philosophy of the web, but wouldn't it still be possible to support a different document format with a new programming model that gives us a clean break from the past? It's a naive question, I realize, but it's tantalizing to imagine what we could have if we went that route. Then again, the cynic in me thinks we'd just endlessly fight over the design decisions anywa…

You’d have to get people to use it. Like any established warty system, the warts provide just enough of a moat for established practitioners to keep it just the way it is.

The thing is, you could use doctypes like a racket #lang to precisely opt into the new format. Same with the type attribute on style, script and link elements. I’ve always found it a bit sad that we haven’t really taken advantage of the built-in extension points of HTML and related technologies because they’re designed pretty well for breaking changes without breaking compatibility.

Re: Mistakes in the Design of CSS (2013)

#16
post #11
post #9

> background-position and border-spacing (all 2-axis properties) should take vertical first, to match with the 4-direction properties like margin. I hate that margin / padding short-hands, especially with 2 values, expect vertical first. In my head it's always (x,y) and (width,height) – always horizontal then vertical, I feel like it works like this everywhere else? Now my issue is that I've committed to memory that…

I think there’s a historical reason for this, that probably made more sense back in the 90s … I seem to remember learning computer graphics back then and being similarly frustrated by the reversed notation. My guess is it goes back to raster based calculations where you would go down a number of lines and then across . Oh yea orig is top left rather than bottom left as one would also naturally expect

it is quite sensible that origin is top left in potentially scrollable situations

Re: Mistakes in the Design of CSS (2013)

#17

Backwards compatibility may be a fundamental design philosophy of the web, but wouldn't it still be possible to support a different document format with a new programming model that gives us a clean break from the past? It's a naive question, I realize, but it's tantalizing to imagine what we could have if we went that route. Then again, the cynic in me thinks we'd just endlessly fight over the design decisions anywa…

That's kinda what something like TailwindCSS is, no? Use their reset & their shorthands, and many of these problems are solved; then your build system translates to the actual CSS standard.

No what I'm referring to is much, much broader. I'm talking about literally a different file extension + rendering engine + execution context. There are a whole host of issues that are outside the scope of just CSS.

Re: Mistakes in the Design of CSS (2013)

#18
post #11
post #9

> background-position and border-spacing (all 2-axis properties) should take vertical first, to match with the 4-direction properties like margin. I hate that margin / padding short-hands, especially with 2 values, expect vertical first. In my head it's always (x,y) and (width,height) – always horizontal then vertical, I feel like it works like this everywhere else? Now my issue is that I've committed to memory that…

I think there’s a historical reason for this, that probably made more sense back in the 90s … I seem to remember learning computer graphics back then and being similarly frustrated by the reversed notation. My guess is it goes back to raster based calculations where you would go down a number of lines and then across . Oh yea orig is top left rather than bottom left as one would also naturally expect

Interesting! I am not too annoyed by the coordinate system with flipped y-axis, but I understand that other graphics APIs handle it differently, the vertical-first order I really don't get though.

Out of curiosity, I just briefly looked at the OpenGL 1.0 specification from 1994 [1] and it seems it is also taking coordinates in the order (x,y), I wonder why CSS then decided to go the other way.

[1] https://registry.khronos.org/OpenGL/specs/gl/glspec10.pdf

Re: Mistakes in the Design of CSS (2013)

#19
post #13

Earlier quoted context omitted.

You’d have to get people to use it. Like any established warty system, the warts provide just enough of a moat for established practitioners to keep it just the way it is.

The thing is, you could use doctypes like a racket #lang to precisely opt into the new format. Same with the type attribute on style, script and link elements. I’ve always found it a bit sad that we haven’t really taken advantage of the built-in extension points of HTML and related technologies because they’re designed pretty well for breaking changes without breaking compatibility.

This sounds interesting - what do you mean by the "built-in extension points"?

Re: Mistakes in the Design of CSS (2013)

#20

I thought "!important" was always about appealing to the emotions of overwhelmed and confused CSS authors as it seems to make the computer "listen to you" when it doesn't seem to be. I remember this notorious book https://www.amazon.com/Creating-Killer-Sites-David-Siegel/dp... about techniques used to get pixel perfect results with HTML back in the 1990s. The author of that book was quite impressed with CSS as it rea…

`!important` was our ultimate weapon designing unbreakable embeddable widgets that other sites will drop in to their webpages at their whims.
Post reply on HN