Why is CSS the way it is? • Hacker News Board

Re: Why is CSS the way it is?

#101

Post by im3w1l » Thu, Jul 23, 2020, 5:03 PM UTC

azangru wrote: post #96

ajross wrote: post #87

Earlier quoted context omitted.

Don't forget the gigabytes of code spent trying to work around the cascade and produce some kind of framework for styling "components" that doesn't leak crazy state from the enclosing context (but does inherit the good stuff). The "cascade" was, for sure, a mistake. Not being in this world, though, I do wonder why there's been no real attempt to fix this from the ground up? I mean... it wouldn't really be "hard" to c…

> The "cascade" was, for sure, a mistake. Aren't global styles only possible because of the cascade and the child elements inheriting from parent elements? Without cascade, wouldn't you have to re-declare your font size and font family, and line-height, etc. on every element of your markup?

    .big-list > li {font-size: 200%}

Re: Why is CSS the way it is?

#102

Post by dsego » Thu, Jul 23, 2020, 5:03 PM UTC

kerkeslager wrote: post #68

One thing I've been realizing is that layout and style are two different thing. Layout I almost always want done on the parent element, and style, I almost always want done on the child element. For example, I probably always want h1 elements to have the same font/weight/size. That's style, and should be defined on the h1. In contrast, the h1 within a blog post may be positioned very differently from the h1 within a…

And then you discover semantic classes for styling elements, eg `.amazing_h1.with_padding` and use nested selectors for layout like `.blog_post > h1` or maybe even utility classes `.amazing_h1.with_padding.centered'.

Re: Why is CSS the way it is?

#103

Post by im3w1l » Thu, Jul 23, 2020, 5:21 PM UTC

im3w1l wrote: post #101

azangru wrote: post #96

Earlier quoted context omitted.

> The "cascade" was, for sure, a mistake. Aren't global styles only possible because of the cascade and the child elements inheriting from parent elements? Without cascade, wouldn't you have to re-declare your font size and font family, and line-height, etc. on every element of your markup?

.big-list > li {font-size: 200%}

Replying to myself: What if you want to have a link or a span inside your list though? Wouldn't it look weird if they have different size than the surrounding text?

Re: Why is CSS the way it is?

#104

Post by btown » Thu, Jul 23, 2020, 5:24 PM UTC

oblio wrote: post #55

btown wrote: post #53

Earlier quoted context omitted.

Counterpoint: I think that if we'd solidified flexbox or grids too early, before people started making full-fledged single-page apps with toolbars and sidebars and panels oh my... we might have easily missed crucial use cases, and the "anti-table war" turning into the "anti-flexbox war" might have shattered the ecosystem. And the inevitable "display: flexierbox" to fix the shortcomings would be a recipe for disaster.…

That's not a valid counter point. Tk ( https://en.wikipedia.org/wiki/Tk_(software) ) first appeared in 1991. It predates the web. It had efficient and powerful layout managers from the start: http://zetcode.com/gui/tcltktutorial/layout/ The web basically offered... nothing. It just ignored everything else going on.

Not denying there was plenty of innovation in the layout manager space. But it's very possible that the standards committees for browsers weren't looking to those for inspiration at the time, especially before Gmail showed what was possible. Of course they might have done everything right, but just noting that hindsight is 20/20.

Re: Why is CSS the way it is?

#105

Post by Izkata » Thu, Jul 23, 2020, 5:25 PM UTC

jandrese wrote: post #36

rimliu wrote: post #24

Earlier quoted context omitted.

CSS clicked for me from the very start. It was always fun, I never had problems with it (aside from the browser bugs, of course). Maybe problem others have with it is not because of the nature of the CSS, but because of people ignoring that nature and refusing to learn it and trying to carry over their experience with other technologies to CSS.

You were never asked to implement a simple three column layout in CSS where the center column expands with the screen size? That’s often the first thing people were asked to do in the early days after being asked to replace the old table based layout. CSS grid/flexbox took way too long to arrive.

Negative margins wooo!

It's been long enough I don't remember the details of that earliest method, but even before flex/grid that layout was easy with calc().

Re: Why is CSS the way it is?

#106

Post by justinator » Thu, Jul 23, 2020, 5:27 PM UTC

sixo wrote: post #90

inopinatus wrote: post #27

This is a somewhat superficial history that only briefly touches on origins, and doesn't discuss the fundamental idea behind CSS, from which everything else is, directly or otherwise, a consequence. Two decades ago I was overjoyed to discover that Scheme was finally going to have a useful application beyond illustrating SICP and writing koans to amuse myself, because DSSSL was on the cusp of evolving into the last do…

Can we just start over on the entire web stack? 1. create a serious styling and scripting framework, basically React as a language since people seem to like it 2. implement an interpreter in WASM. Ship the interpreter with the website unless the browser says not to 3. over time, build the interpreter into the browser

> Can we just start over on the entire web stack?

Haha, so sorry, but: no.

And if we're starting over, when just start at the web stack?

Re: Why is CSS the way it is?

#107

Post by kanobo » Thu, Jul 23, 2020, 5:31 PM UTC

As flawed as CSS is, it's uniquely special in that you can get by through trial, error, and mimicry without having to read a single book or have any deep understanding.

Re: Why is CSS the way it is?

#108

Post by seaish » Thu, Jul 23, 2020, 5:39 PM UTC

lloydatkinson wrote: post #83

I've found that since using utility/functional CSS in the form of Tailwind that I actually enjoy making UI's now. Coupled with componentization in the form of a JS framework like Vue, I don't need to stress over CSS anymore. No more LESS or SASS, no more .header-container, .header-parent-inner crap. https://adamwathan.me/css-utility-classes-and-separation-of-... I'm sure some puritan naysayer will disagree but whatev…

This article would have much less of a problem with CSS if they actually used the cascade. All those instances of double underscore in class names should be two separate classes: ".author-bio__name" becomes ".author-bio .name". Then you can style the generic .name while also having control over specifically author names.

The end of the article comes to the same kind of conclusion (use multiple classes), while also using CSS as a style standard. But the beginning shouldn't even be an option.

Re: Why is CSS the way it is?

#109

Post by chaoticmass » Thu, Jul 23, 2020, 5:51 PM UTC

matsemann wrote: post #80

jandrese wrote: post #47

IMHO this article inadvertently shows why people hated CSS at the start. He spends a lot of time talking about color space conversions that few developers care about and Unicode filtering that even fewer people know about but glosses over basic layout by mentioning how floats allow for better inline images. It’s like the designers didn’t even think about layout because that problem was already solved with HTML tables…

I remember spending ages on various ways to implement "the golden layout" or whatever it was called. Edit: Holy Grail. One header on top, then three columns, and then a footer. And the middle of the three columns should scale with screen width and screen height, such that the rightmost column was at the edge, and the footer was at the bottom of the screen if content was less than screen height. And then a-list-aparts…

I miss those days. Such a simpler time.

Re: Why is CSS the way it is?

#110

Post by kerkeslager » Thu, Jul 23, 2020, 5:53 PM UTC

dsego wrote: post #102

kerkeslager wrote: post #68

One thing I've been realizing is that layout and style are two different thing. Layout I almost always want done on the parent element, and style, I almost always want done on the child element. For example, I probably always want h1 elements to have the same font/weight/size. That's style, and should be defined on the h1. In contrast, the h1 within a blog post may be positioned very differently from the h1 within a…

And then you discover semantic classes for styling elements, eg `.amazing_h1.with_padding` and use nested selectors for layout like `.blog_post > h1` or maybe even utility classes `.amazing_h1.with_padding.centered'.

If you're doing class='centered' or class='with_padding', I don't see any reason not to just do style='align-self:center;' or style='padding: 1rem;' instead. The class names communicate less (Is that centering the content of the element, or the element itself? Is that vertical or horizontal centering, or both? Is the text being centered?). And it doesn't allow you to make sitewide changes like a semantic class does (You might want to change all .blog-title elements from centered to left-aligned, but do you really want to change all .centered elements from centered to left-aligned?). I'd go so far as to say this is an antipattern.