[__jonas]

> 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 margin and padding short-hands work the exact opposite way I would expect, so sometimes I still mix them up because I type them 'correctly' and then flip them because I memorized it like that..

[culi]

North East South West (never eat sour worms)

not

East South West North

[__jonas]

That's actually a nice insight, I was so caught up in thinking in terms of screen space coordinates, it never occurred to me that it is based on cardinal directions.

It makes a fair amount of sense for the full shorthand with all 4 properties specified.

[culi]

I actually don't think it makes any sense to base it on the cardinal directions! But it's easy to remember and I have no preferred alternative haha

[Izkata]

Doesn't help for those of us who learned the order North, South, East, West.

[VPenkov]

Heh back in the day I memorized it by remembering that if I didn't know it, I could get myself in TRouBLe.

[russelg]

If you're Australian, you may have heard "Never Eat Soggy Weetbix" instead, very fun.

[rusk]

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

[__jonas]

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

[giantrobot]

Some drawing systems take coordinates in x,y but the origin is top left. Ascending coordinates go down and right. Then other systems have an origin at the bottom left so ascending coordinates go right and up. There's good reasons for both depending on the context and nature of the drawing.

[__jonas]

> Some drawing systems take coordinates in x,y but the origin is top left

Right, as I said, top left coordinate system makes sense to me (like in the browser), so does bottom left (like in OpenGL) it's just the fact that CSS expects (y,x) not (x,y) for margins and padding short-hands, regardless of the coordinate system that confuses me.

[bryanrasmussen]

>top left coordinate system makes sense to me

top left is where reading is assumed to start in Western societies, maybe other systems have the same because of the natural feeling this inspires.

[rusk]

> OpenGL 1.0

Not quite what I had in mind particularly because opengl was an abstraction layer designed to begin to resolve these kinds of issues in a more domain-oriented way. Go further back I’m thinking more about the 8-bit generation which is … yeah 80s

I don’t know why CSS didn’t try to resolve the issue too, just alluding to why it might have been at odds in the first place.

[valyagolev]

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

[unclebucknasty]

Would be interesting to view websites through a browser that transposes these values while rendering, or otherwise interprets CSS differently in thoughtfully considered ways.