Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mistakes in the Design of CSS (2013)

wiki.csswg.org

Post reply on HN
Print view View original

21–30 of 147 posts

Re: Mistakes in the Design of CSS (2013)

#21

Post by Izkata »

> Box-sizing should be border-box by default.

It was in Internet Explorer, everything being misaligned because of this difference was one of the reasons it got the nickname Internet Exploder.

Edit: To be clear this was more of just a fun fact, I agree with this statement. The misalignment was because people would build to content-box without knowing it was different in IE. Worse still IIRC they acted differently even before this CSS attribute was exposed, so you had to make it work both ways if you wanted your site to look nice everywhere.

Re: Mistakes in the Design of CSS (2013)

#22

Post by giantrobot »

__jonas wrote: post #18
rusk wrote: post #11

Earlier quoted context omitted.

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

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.

Re: Mistakes in the Design of CSS (2013)

#24

Post by codedokode »

> The top and bottom margins of a single box should never have been allowed to collapse together automatically as this is the root of all margin-collapsing evil.

Disagree. All margins, including horizontal, should collapse. Typically you want 20px between buttons, not 20 + 20.

Re: Mistakes in the Design of CSS (2013)

#25

Post by __jonas »

giantrobot wrote: post #22
__jonas wrote: post #18

Earlier quoted context omitted.

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

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.

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

Re: Mistakes in the Design of CSS (2013)

#26

Post by giantrobot »

danielvaughn wrote: post #5

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…

First you need buy-in which means essentially Google needs to support the format in Blink. It needs to be sufficiently specified so Apple supports it in Safari on iOS as well (which means support on Mac and iPad).

Second you'll need a good reason for the new format instead of just implementing it in current browsers. Lots of fancy stuff on the web today is just something that draws to a tag and ignores a lot of actual HTML or CSS. We're already seeing a lot of traditionally "desktop" code being able to target WASM as a compile target.

Re: Mistakes in the Design of CSS (2013)

#27

Post by culi »

__jonas wrote: 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…

North East South West (never eat sour worms)

not

East South West North

Re: Mistakes in the Design of CSS (2013)

#28

Post by bryanrasmussen »

__jonas wrote: post #25
giantrobot wrote: post #22

Earlier quoted context omitted.

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.

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

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

Re: Mistakes in the Design of CSS (2013)

#29

Post by Jeema101 »

> z-index should be called z-order or depth and should Just Work on all elements (like it does on flex items).

Z-index is one of the most aggravating things I've run into with CSS. It should always Just Work as the author says and be absolute across the whole page and intuitive. But it isn't. And every time I run into a problem where it's not behaving in the way I expect, I have to once again Google 'z index not working' and refresh my memory on all the reasons why it might not be working with the specific example I'm dealing with.

Re: Mistakes in the Design of CSS (2013)

#30

Post by PaulHoule »

corethree wrote: post #2

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.

What's the alternative?

The 1990s style HTML form app that works like a green screen mainframe application? (It seems to be forgotten technology in the age of React like Stonehenge or the Egyptian Pyramids but I think it's quite appropriate for the kind of application it's capable of, which is more > 50% of what people use React for.)

Cross-platform frameworks like GTK, Qt, Tk, FLTK, wxWidgets (was that a winner in the world cup for "ugliest UI"?), Flutter, etc. (I did a shootout of x-platform UI frameworks and concluded that Electron really is the best of the bunch, is it any worse to make people download a 30MB Electron runtime than a 50MB Java runtime or a 25MB Python runtime?)

Apple fanboys inexplicably seem to like iTunes and MacOS, they all swear by xCode but even people who think "it is is all good" when it comes to fruit swear at the App Store when it comes to delays and restrictions. I'm pretty sure there is a good UI framework somewhere inside Windows but it might be hard to find in a maze of twisty little APIs that all look alike:

https://www.reillywood.com/blog/windows-ui-frameworks/

Compare that to the freedom of the web platform. I've lately been playing around with this framework with my Meta Quest 3:

https://aframe.io/examples/showcase/modelviewer/

which makes it straightforward to make an application that targets desktop, mobile, VR and AR headsets. Although it is based on React it has the same entity-component architecture as the Unity framework. I'm sure I could get better performance writing a more-or-less Android app based on Unity but dealing with Facebook's App Store seems like messing around with IBM cards, particularly when I want to target Apple Vision when it comes out and when I need to have an experience for people that don't have a VR headset because those aren't very common yet.

Post reply on HN