
Why is CSS the way it is? - BerislavLopac
https://increment.com/frontend/ask-an-expert-why-is-css-the-way-it-is/
======
inopinatus
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 document
styling language anyone would ever need.

Unfortunately following an incident with a broken Lisp machine, a liquid
lunch, and an unlicensed particle accelerator, I became trapped in a parallel
universe where the HTML ERB anointed CSS by mistake during a drunken night out
in Oslo.

The fundamental concept of CSS (best revealed by H.W.Lie's thesis IMO[1]) was
to create a rich and versatile and non-Turing-complete set of structural
selectors in lieu of DSSSL's recursive logic, and to allow styles to overlay
one another; two design choices that only by the application of gallons of
irony can explain why most web pages are composed of a bunch of nested DIV
elements with hashed IDs and overloaded semantic class attributes, and
everyone compiles their assets into a static file.

[1]
[https://www.wiumlie.no/2006/phd/css.pdf](https://www.wiumlie.no/2006/phd/css.pdf)

~~~
sixo
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

~~~
LoSboccacc
there's canvas, you can already write apps that target it both in unity and
Godot, the latter spring a wealth of languages

~~~
rikroots
Question: how do these engines address accessibility issues for, say, a
holiday booking site that uses the canvas element for its entire UI?

~~~
LoSboccacc
surprisingly there's some work being done for it

[https://godotforums.org/discussion/21963/early-access-of-
god...](https://godotforums.org/discussion/21963/early-access-of-godot-
accessibility-addon-now-available)

------
jandrese
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. But the problem was that when CSS came
out there it came with the mantra of _thou shalt not use tables for layout_ ,
but CSS was only specified enough to wrap text around an image, so designers
had to torture inline-blocks and floats to try to achieve even basic layout
tasks. This ended up bringing out a lot of edge case incompatibilities and
fights with the layout engine. CSS had made the hard things possible while
making the easy things hard.

It took _decades_ before browsers finally supported CSS grids. A feature that
should have been in the spec on day one.

As for those Unicode filters the syntax barely matters. Anybody who needs one
is going to Google the magic string for their language and paste it into the
document. Nobody wants to build one of those from first principles. That’s
true of anything Unicode related—-it’s too complex with too many weird edge
cases for mere mortals to handle.

~~~
matsemann
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 "faux columns" to make the columns seem to have the
same height.

Edit: It was the "Holy Grail" it was named
[https://en.wikipedia.org/wiki/Holy_grail_(web_design)](https://en.wikipedia.org/wiki/Holy_grail_\(web_design\))
So hard to do that it even has its own Wikipedia page, heh

~~~
Macha
I have a CSS book from that time, one I kept too long because I felt it was
one of the better CSS books in its time and hasn't been replaced as I keep a
certain amount of books for decorative purposes and haven't bought new
development books in a while.

The final chapter, in a "putting it all together" style spent most of its time
om a holy grail layout.

If I was writing a modern CSS book, this topic would be somewhere in the
second quarter in a chapter on grid and flexbox.

------
atoav
I have a weird relationship regarding CSS:

I kinda like it (although some things could be even a bit more powerful), yet
everybody I meet tells me how horrible and hard etc it is. I never had that
feeling at all, not even back when I started using it as a teenager to
customise my MySpace site.

I cursed at how hard common things like centering a image within a div were, I
cursed at the purposeful and ignorant incompatibilities of different browsers,
but with CSS3 I was sold, even more so when grid based layouts and flexbox
became a thing one could lean on.

The one thing that I miss is _a little_ bit more power when it comes to
selectors. E.g. there is no way to select a <p> which has only a <img> as a
child, which is coincidentally something that a standard conform markdown to
HTML converter will produce. So you cannot — say give your <p> a max-width of
120ch without also limiting the width of the <img> contained within it. AFAIK
there is a parent selector planned that might address this if I recall
correctly.

~~~
giantDinosaur
You can't work out the logical consequences of seemingly obvious properties.
That is unlike 95% of most programming I do in any programming language I've
ever used. Since I have zero interest in learning unintuitive interfaces to
GUI design, I have zero interesting in excusing CSS. It is not difficult to
learn, it is not difficult to understand in terms of _conceptual_
understanding, it is downright _tedious_ to learn though - and you don't get
anything unique out of it that can't be done in anything else: you get a nice
looking website. Amazing.

~~~
Izkata
Probably because very few learn CSS right. In particular: the box model.

All the devs I know that struggle with CSS don't understand it. The ones that
don't have issues have internalized it and don't need to think about it much
anymore.

The box model is one of those fundamental building blocks you really should be
learning very early on, a bit like an "if" statement in imperative languages -
you can hack around it with ternaries and single-iteration loops, but you're
never going to be as effective or have as strong an understanding of the
language as you should.

~~~
Davertron
You can learn to do arithmetic with roman numerals but that doesn't mean its
good.

~~~
acdha
This is more like saying you don't need to learn algebra and then saying you
hate math because it takes too much work to get the answer you need. A
surprising number of developers are under the mistaken belief that not
learning how the web works is saving them time and over the years I've been
amazed by how many people will instead unquestioningly spend years playing bug
whack-a-mole with megabytes of JavaScript sturggling to replicate built-in
behaviours.

------
mouzogu
The biggest issue with CSS I think for many is the emergent complexity from
the interaction of different properties. Especially those inherited through
the cascade. Much of this emergent complexity is not always consistent cross-
browser.

Additionally, there are often many ways to accomplish the same result but
fully understanding the implications of certain approaches over others is also
a headache at times.

Speaking personally, something touched on in this article, is that many things
don't really make sense to me or at least I don't find them intuitive - and
I've been working with CSS daily for 14 years. It does often feel like a
scatterbrained, horse designed by committee type of thing.

It's like CSS only makes sense when you learn to see the problem through the
eyes of whomever specced out that particular feature, which can also be said
for trying to read CSS written by another developer.

~~~
onion2k
_The biggest issue with CSS I think for many is.._

..that they haven't looked at it for years and assume it's still as hard to
use as it was when it was new. In any discussion about CSS _someone_ will
eventually post that "vertical and horizontal centring is really hard, and
that's why CSS is terrible"[1], and all it shows is that their skills are out
of date.

[1] Seriously, it's as easy as "display: grid; place-items: center;" these
days (if the element has width and height somewhere in the cascade).

~~~
philistine
I’m no expert here, but I think the model of always adding new syntax doesn’t
help people realize that CSS has gotten so much better.

~~~
onion2k
Given the choice between making life easier for developers who are too lazy to
learn some new syntax and literally breaking the whole of the internet because
websites stop rendering correctly with the changed meaning of things, I think
I'd side with the adding more syntax. It's not even a hard decision.

------
kerkeslager
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 video page, so I'd want to define that in the blog post and
video page styles, respectively.

Of course, where this gets complicated, is that there's not always a clear
boundary between style and layout. For example, I might always want the same
amount of space under the h1 between the h1 and the content it titles (style?)
but the top/left/right spacing is probably more dependent on the context
(layout?). There are some hard to communicate tradeoffs here.

~~~
dsego
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'.

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

~~~
Evansbee
Disagree. This is utility classing and you can target pseudo elements and deal
with responsiveness. Tailwind is pretty popular and uses this methodology.

------
myfonj
Article revealing origins of CSS should at least mention that one of its (at
least initial) primary goals was to set that "entirely different academic yet
simple presentation language" in a way it would __allow dialogue among at
least three agents expressing their visual preferences __. This mechanism,
cascade - the the "C" in "CSS" \- is that mechanism that sets rules how
different preferences should be merged together and conflicting resolved in
final visual presentation of documents.

Simply said, that what style sheets communicates are mere _suggestions_ for
appearance: browser has its "default" style sheet, users can set their own set
of rules, author sets their, but user and browser still have control what
author can and cannot change.

I see this "origin specificity" as very important fundament that explains a
lot about the way CSS emerged and evolved. This bit of information, however
"obsolete" it may feel nowadays in age of web applications (but not obsolete
standards-wise), is perhaps too obvious to most professionals, yet I see it
omitted from learning materials, or dug very deep in them.

(Sorry for repeating myself here at HN, and sorry if I overlooked it in the
article, I admit I've just skimmed it searching for this exact piece of
information.)

------
chrisallick
CSS is amazing. It's hilarious to watch the twisted ways people will work
around it, or spend time making libraries to find solutions to problems that
don't exist; without ever even trying to get comfortable with it. Its an
amazing and simple piece of technology. Kind of a shame. Id love a real
history and critical discussion on the "tools" we have now for web dev.

~~~
goatlover
I'd rather it be a programming language, which Netscape tried to do with
Javascript Style Sheets in the late 90s. Was way more flexible, but was never
accepted as a standard and of course, was not supported by IE.

~~~
chrisallick
and yet millions of people have expressed themselves, published information,
shared it, and benefitted. so... it works.

the corruption of the net is proportional to the corruption of the tools. a
shame really.

------
hardwaregeek
I was trying to articulate why CSS is so unpleasant for me. I've learned
enough tricks and techniques to tolerate it, but there's still plenty of times
where I despise it. There's a few glaring issues:

\- No way to style according to siblings. This is a big mental model shift.
Often times I want a div to be the same height as another div. Since CSS
doesn't really allow sibling communication, I need to get the parent div to
set the height and then tell the children to play along. Or manually set the
height on both children.

\- Error handling is so so bad. It sucks to have your styles break silently
due to an errant comma or space. Well typed styles like bs-css[^1] have made
this somewhat tolerable.

\- The weird tug of war between positioning yourself versus positioning your
child. I understand the reason for both but it's offputting having both as an
option.

\- Lack of z index positioning. Often I want to superimpose one element on
another, say a caption on an image. Right now I need to resort to position
absolute, then do the standard dance to center something by computing 50% +
half the size of the overlayed element. Not fun. I'd love a flex-direction:
into-page that does flexbox over the third dimension. It'd be a little tricky
to understand but honestly not too bad.

What's weird is that in some ways these issues have gotten worse with
components. Since I can reuse a component, I now need to think of how its
styles will work in every usecase. For instance I had forgotten to set my
component's background to white, since it was already white by default. When I
moved the component to a blue background, boom, it became garishly blue. Of
course this is my bad, but it sucks that we have to carefully engineer our
styles such that moving a component into a new context won't screw it up.

[^1]: [https://github.com/reasonml-labs/bs-css](https://github.com/reasonml-
labs/bs-css)

------
goto11
I think most of the complaints against CSS is because don't understand the
problems CSS is trying to solve. It is _not_ just a question of putting text
and colors on a screen. You can do that with Postscript or PDF or SVG or
several other comparatively simple technologies. CSS is trying to tackle a
_much_ harder problem:

\- Layout and typography which can be readable on various devices with wildly
different dimensions, aspect ratios and resolutions.

\- Incrementally rendered (i.e. the start of the document can be rendered
before the whole document has been loaded)

\- Allow users to enlarge the text size while keeping the text legible. (In a
PDF you can zoom, but then you will have to scroll vertically back and forth
for each line.)

\- Backwards compatible with the display model of pre-CSS presentational HTML

No other technology exist which solves all these problems. If you ignore one
of more of the above constraints you can probably devise a simpler and more
intuitive styling language.

------
lloydatkinson
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-...](https://adamwathan.me/css-utility-classes-and-separation-of-concerns/)

I'm sure some puritan naysayer will disagree but whatever. I value design
system focused and productive styling for frontend. It works very well.

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

~~~
lloydatkinson
I actually don't really like the cascade.

------
bobbyz
I have noticed a commonality between systems that are unintuitive to use like
git and CSS: they didn't sufficiently mimic nature, or common everyday
concepts.

Say you design a new relational DB. You want all the postgres and SQL people
to switch so you adopt SQL as the querying language. Your DB becomes so
popular that it eventually gains +80% market share. Many people now have to
learn SQL as their first querying language and now you've created another git.

Another scenario is a system being appropriated for something else like CSS
was (?).

Copying your competitors is simply not a guarantee that your system will stand
the test of time. The only constant is nature.

------
_greim_
CSS is a lot like JavaScript: cobbled together in a hurry and designed to be
excruciatingly easy to get started with, almost to the exclusion of all other
concerns.

It makes me wonder if it's even possible to design a language that's both easy
for abject beginners, while simultaneously being powerful, expressive and
productive for experts at scale. Is that even a topic of study in language
design?

~~~
leephillips
Julia

------
mwexler
Ever notice how the phrase "I love how CSS works..." is inevitably followed by
"but x or y really sucks, is too complex, is inconsistent..." I can't recall
meeting a cheerleader for CSS the way you do for, say, lisp/scheme or forth.

Sure, everything has gaps, and fans are the first to point them out... but CSS
fans always have a lot of fuel to bring up in the flaws dept.

It's starting to feel like css is approach emacs/vim level of argument-
starting tinder.

Is that because it's so good, or because we are stuck with it?

~~~
acdha
It's because CSS is a widespread distributed system which you don't entirely
control. Programming language fanboys are usually just not being entirely
forthright but they are also usually speaking from easy mode where they
control all of the parts of the system, can upgrade at will, and don't need to
support anyone else's projects.

Languages like Lisp, Scheme, or Forth have both a selection bias (mostly used
by fans) and they just aren't that widely used. If millions of people were
writing code expected to run with a standardized API on billions of clients
where it might take 5 years or more to drop support for an old version, they'd
find more things to complain about. It's not a coincidence that the best thing
which happened to CSS was the rise of the evergreen browsers shaving years off
of the time between a feature being released and someone being able to rely on
it existing.

------
talkinghead
Great read, a related and entertaining CSS talk is CODE GENIUS - Cascading
Shit Show by Jacob Thornton

[https://www.youtube.com/watch?v=iniwPUEbPUM](https://www.youtube.com/watch?v=iniwPUEbPUM)

~~~
moray
I also recommend Kevin Powell videos:

[https://www.youtube.com/kepowob/featured](https://www.youtube.com/kepowob/featured)

I learned some obscure CSS features from him.

------
kumarvvr
As a developer from 2005 or so onwards, I have only ever known the Markup +
Stylesheet system, having read a huge number of articles, where it was touted
having the document markup separate from the styling was the holy grail of web
design and productivity.

Nowadays, I see mixing of styling and content to be all the rage, which I
actually feel is easy to use. Of course, component systems still split out the
styling and document markup, but the line, and developer thought procress is a
lot blurrier.

I would love to know if there are any better systems of presentation, compared
to the document + markup paradigm.

------
martyvis
"People were excited just to see documents that lived on other computers
across the world—and not just in plain text, but with headings and lists,
too!" \- I remember that feeling so well.

------
ellis0n
We need a time travel machine to remove the CSS and add Objective-J.
Objective-J is great for people who don't want HTML / CSS hell. I asked the
Objective-J author about native browser support as JS/HTML/CSS because
performance was matter 10 years ago. And got the answer is "they wil never
browser builtin other than JS/HTML/CSS". And now we have multiple new
ecosystems, template engines, package managers, languages, reactive
frameworks, and other 15 standards

------
d_silin
To summarize the answer in a single line: "We added it to the specification,
thinking we could always improve it later"

CSS is not the only victim of this approach, just particularly bad case.

------
nayuki
Other articles about the history of CSS and how it came to be:
[https://eev.ee/blog/2020/02/01/old-css-new-
css/](https://eev.ee/blog/2020/02/01/old-css-new-css/) ;
[https://www.w3.org/Style/CSS20/history.html](https://www.w3.org/Style/CSS20/history.html)

------
nsm
As someone not at all involved in web development, if I wanted to learn CSS
properly, with all the new flexbox/grid support instead of fighting with
margins etc, what are some good recommendations? Like say I don't care about
browsers older than a year ago and I only want to use the sane parts of CSS.

~~~
kotojo
I haven't read this, but I know quite a few people who recommend this book by
John Duckett [http://www.htmlandcssbook.com/](http://www.htmlandcssbook.com/)

These are resources I used to learn grid and flexbox.
[http://cssgridgarden.com/](http://cssgridgarden.com/)
[http://flexboxfroggy.com/](http://flexboxfroggy.com/)

The site I inevitably have open looking some how to do something with css
[https://css-tricks.com/](https://css-tricks.com/)

------
ronanyeah
Some help can be found with typed CSS:

[https://package.elm-lang.org/packages/rtfeldman/elm-
css/late...](https://package.elm-lang.org/packages/rtfeldman/elm-css/latest)

[https://github.com/reasonml-labs/bs-css](https://github.com/reasonml-labs/bs-
css)

Or even a typed alternative to/subset of CSS:

[https://package.elm-lang.org/packages/mdgriffith/elm-
ui/late...](https://package.elm-lang.org/packages/mdgriffith/elm-ui/latest/)

------
torartc
In 2020 CSS is amazing and only getting better.

------
pcwalton
HSL is fine. More people are familiar with it than with CIE LCH, and
familiarity is the most important thing. There may be better color systems,
but to paraphrase the saying, there are also better alphabets.

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

------
Datsundere
I despise CSS. Typescript has made JS a lot better. But I despise CSS. It's
not engineering when you're writing CSS. it's all guess work.

------
cousin_it
> _Why is CSS the way it is?_

Because all its original creators were programmers and didn't think to invite
even a single person who'd ever worked an hour on visual design. Check on
Wikipedia, it's unbelievable but true.

------
justforyou
>> But despite our best efforts, frustrating or confusing features exist, and
in all likelihood will continue to be added.

The above statement makes me question both the sincerity and intensity of
"best efforts."

------
frankzander
I don't get it ... for me CSS is very easy. It's logic and clear. But yes you
have to learn and work with it. It's ok ... so not everybody can master it
drive-by and call themselfs an expert.

~~~
rikroots
My problem with CSS is not so much with its idiosyncrasies - though I still
find myself getting tripped up by ::pseudo-elements when they're used for
anything more than show-off quote marks.

Rather, it's with the way people use it.

For instance when working with a code base handed over to me for maintenance,
it's often been the case that the code has already passed through several
previous developers/companies. And a lot of those people have fixed
presentational bugs over the years by adding !important rules in various
places across the various CSS files that contribute to the site. It drives me
nuts! Also: commenting out huge swathes of CSS code in a file, but not
deleting it ... just in case it's needed again. Why??

The other thing that concerns me is the way new functionality gets added to
the CSS spec. Take animations - do they belong in the CSS code, or Javascript?
Yes CSS animations are (generally) faster, but the more complex the animation,
the harder I find it to understand a CSS implementation. And it's gonna get
worse in the future thanks to CSS Animation Worklets, which are being
developed as part of the CSS Houdini thing.

There comes a point when I have to decide: CSS or Javascript. I can't keep up
with developments in both, and I enjoy coding Javascript more than CSS. </end-
self-pitying-moan>

------
halotrope
I really appreciate the mobile version of this article. Clean, lightweight and
beautiful.

------
divan
Can we just embed Flutter in every browser? !important

~~~
pjmlp
It was called Flash.

~~~
chrstphrknwtn
Everyone loves to hate Flash, but as an environment to create things it was
actually great.

It was the player that wasn’t great.

~~~
johannes1234321
Yes, Flash was a great tool to create stuff. (I only used it in Macromedia
times)

This however also lead to an abuse and for a while you had websites, fully in
flash which broke so many things (deep linking/bookamrks, browser history,
etc.) combined with unintuitive navigation and slowness due to animations ...
plain overuse of an otherwise good technology.

~~~
AnIdiotOnTheNet
> broke so many things (deep linking/bookamrks, browser history, etc.)

Truly we have failed to learn from past mistakes.

~~~
johannes1234321
Modern JavaScript frameworks have support for this and a result of Flash's
experience is that browsers have specific APIs for that ... however: each new
generation of developers has to learn :)

~~~
treeman79
Yes but JavaScript generations are like every six months.

I took a 3 year break from anything Frontend. Felt like I had gone through a
time machine.

------
tinus_hn
These comments read like the opinions of people in a post communist country.
All the bad sides have been forgotten and all that’s left is nostalgia.

