
Incomplete List of Mistakes in the Design of CSS - zdw
https://wiki.csswg.org/ideas/mistakes
======
devwastaken
I don't think things like syntax and schemes are the real bad parts. The real
bad part is that CSS is in no way designed to be interacted with by anything
but CSS.

Just yesterday I was making a music player position bar, and using CSS
transitions to have it smoothely update itself. Set the duration of the
transition and it goes on.

But what about when the transition takes effect? JS doesn't know when a style
is actually updated and can then have a new property overwriting it to make
the transition happen. If you do properties too quickly the transition won't
happen. Such as if a user clicks on the bar to change the position, I have to
hack in a 100ms setTimeout to set the new transition duration _after_ stopping
the transition with transition:none;

Why can't I control a transitions location? Chrome's animation viewer can go
back and forth in time easily.

Why isn't interactivity seperate from CSS? CSS elements cannot effect those
outside of its scope. You require JS for just dumb simple things that should
be natively supportable. For instance you can make CSS do things based upon
URL hash names like #somename, but you can't set them in CSS. You can't change
attributes on elements, or classes or anything like that.

I think we've gotten to the point where JS is the 'programming language' of a
webpage that has intentions far beyond rendering and interactivity. Perhaps we
need a newer kind of CSS that's made for dynamic interactions. That way great
UI's can be built in a safer css-like environment.

~~~
_hardwaregeek
Yep yep. CSS in JS removes some of the pain points but still, fundamentally,
CSS cannot communicate with JS in a universal, elegant way. Honestly, CSS in
general is awful. How did we only _just_ get decent centering with flexbox?
How is flexbox still inconsistent across browsers? (Try setting a child of a
flexbox container to 100% height.) The days of needing separate constructs
because of bandwidth are over. We need something to unify CSS and HTML and JS
into a UI builder that doesn't make you want to tear your hair out when you
have to center a div over another div and give it an animation.

~~~
VonGuard
The thing i hate about CSS is how unstructured it can be. You just sorta list
whatever you want and it's suddenly a style sheet. No headers, no footers, no
must includes.... DO I use quotes around this value? Do I not? Does white
space matter? It's the most intimidating language I've ever used just because
it feels so open and uncontrolled and nonsensical... I always thought CSS was
some leftover abomination from the days of Netscape.

~~~
devwastaken
LESS is more how CSS should look like for styling. It's amazing we don't have
embedding of rules yet.

parent {

    
    
       child {
    
        }
    

}

is just so much more development friendly than

parent {

}

parent child {

}

~~~
gsnedders
The CSS WG earlier this year resolved to take on a spec defining this, and
there's implementer interest, so it's highly likely to happen.

(This is [https://github.com/w3c/csswg-
drafts/issues/2701](https://github.com/w3c/csswg-drafts/issues/2701) .)

------
combatentropy
Most of these are nitpicks. Some are preferences that I would oppose.

CSS is inspired by the style sheets of yore, of typeset publications made by
ink-smeared metal pressed into paper. A magazine or newspaper might have a
"style sheet" that said things like, "Paragraphs shall be 10-point Caslon" and
"all second-level headings shall be hanging headings, outdented 5 picas."
Before web browsers got a hold of them, stylesheets had already entered the
electronic world in desktop-publishing software like QuarkXPress and even
Microsoft Word.

The problem they were trying to solve was, how do you update the look and feel
your website easily? This was in the days when most websites were static HTML
files, and updating all your articles meant changing a file for every page.
The most famous and beautiful example of the power of Cascading Style Sheets
is CSS Zen Garden. In 2003 Dave Shea provided an unstyled page of HTML, and
then designers from around the world contributed stylesheets that transformed
the page into wildly different designs
([http://www.csszengarden.com/](http://www.csszengarden.com/)).

~~~
praptak
> CSS is inspired by the style sheets of yore

Which is in my opinion the reason why it sucks for most of its current use
cases. Layout of a paper document and layout of a web page are very different.
The web "page" often isn't even a page but rather a GUI for a computer
program.

~~~
combatentropy
From the beginning, CSS tutorials said just what you said, that the web is not
the printed page and that you should not strive for pixel-perfect layout.

~~~
praptak
It's not necessarily about pixel perfect. Even basic things like "two divs
horizontally" are not intuitive in CSS, especially pre-flex-box.

~~~
Blaiz0r
Use spans then...

~~~
praptak
The selling point of CSS tho is that layout change should not require change
in html.

------
ZenPsycho
here's my pet peeves:

1\. CSS should not have adopted a hyphenated naming scheme for properties,
since it makes it difficult to access css properties from javascript or other
languages.

2\. CSS should never have been used for layout, and nobody should have
suggested it should be. CSS defines properties on individual elements, while
layout fundamentally needs to define _relationships_ _between_ elements, which
requires really icky hacks and implied relationships in a language like CSS,
e.g. the definition of percentage units (percentage of what?) being mostly
arbitrary and context sensitive, So you are forced to learn what all those
context rules are to get the desired outcome.

What does height: 80% mean? 80% of the parent element's width? 80% of the
parent element's height? 80% of the window width? who knows?

3\. The naming of properties and values is entirely inconsistent. Sometimes
"none" works. sometimes it doesn't. What even _is_ going on with "white-
space"?

4\. Who allowed Microsoft to add "pointer-events" properties to css? This is a
tragedy.

5\. em based font sizing seems like a really good idea until you use it in
some system that will arbitrarily nest component elements until the innermost
reply to a comments thread is either microscopic or 3 characters per line.

~~~
uryga
> _CSS defines properties on individual elements, while layout fundamentally
> needs to define relationships between elements_

I couldn't agree more! Does anyone know a language/toolkit/something that gets
layout right? I remember getting excited by Grid Stylesheets [1] but the
project seems dead now...

[1] [https://github.com/gss/](https://github.com/gss/)

~~~
thexa4
The layout constraints system on iOS works pretty well once you understand
that it uses a global constraint solver:

[https://developer.apple.com/library/archive/documentation/Us...](https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/AutolayoutPG/index.html)

~~~
ZenPsycho
I wonder if CSS could be translated/compiled to sets of linear constraints?
Obviously just the parts that affect layout would be relevant for this
translation. But I wonder if it's possible to come up with a formalised
mathematical relationship between the byzantine context sensitive rules of CSS
layout, and the smaller set of building blocks that cassowary supplies.

And then, I wonder how much could be round tripped? Do flexbox and grid fill
enough of the gaps to make systems of linear constraints fully expressible in
terms of flexbox/grid? If not, where are the remaining gaps, and are they
useful enough "real world" usecases that you couldn't practically make
constraints->css a (potentially) lossy translation. It kinda looks like GSS
attempted this, but I wonder if GSS can be improved upon to rely less on JS
for filling the gaps in 2018?

------
mcphage
(1) it should have been designed around what people actually try to do: three
column layouts with headers and footers, aligning content in the middle,
pinstriping (this one isn’t as popular anymore), drop shadows, etc. Instead,
all of these things required either hacky workarounds, or stepping outside of
CSS entirely. The first decade of CSS was “look at all these things you can do
that you don’t want to, and you can use them so long as you don’t try to make
the kind of sites your clients actually ask for!" So fucking stupid, it still
makes me angry years later.

~~~
dwd
> (1) it should have been designed around what people actually try to do

It was but a lot has changed in the last 20 years.

At the time CSS was first supported in most browsers, the way to create
columnar layouts was with a frameset. They even handled fixed position headers
and footers.

I can't believe I've been writing CSS for 20 fucking years.

~~~
mcphage
> the way to create columnar layouts was with a frameset

Ohgod, I forgot about that one. Ugh. Of all the bad ways to make a 3-column
layout, that one was definitely the worst.

------
quarterlyresult
It wasn't until recently that I finally realized how user-friendly CSS was
designed to be. As I started to fiddle with LaTeX in search of better looks on
my papers, it gets more and more clear that the design of CSS is thoughtful
and ergonomic. It is so painful to work with LaTeX that I could not believe I
had complained about CSS. What would take a few lines of clear code in CSS
would take dozens of undecipherable sequence of commands in LaTeX.

For instance, just changing the font size of section headings in LaTeX is not
a trivial matter. Eventually I ended up with this:

    
    
        \renewcommand\section{\@startsection {section}{1}{\z@}%
                                           {-3.5ex \@plus -1ex \@minus -.2ex}%
                                           {2.3ex \@plus.2ex}%
                                           {\normalfont\normalsize\bfseries}}
    

It would take just h1{font-size:1em;} in CSS. The problem of TeX is that it
has no abstraction that is easy to work with. In CSS, you have elements --
actually, a tree of them -- and they have their own attributes, and in
addition, they can be easily modified. You can even give elements a class to
have them have common properties. All things that do not exist in TeX. I did
not know how the concept of a heretical structure of elements and their
attributes give you an intuitive interface to a layout.

Certainly, CSS might not provide you with full control over how things are
rendered. There is little doubt that TeX excels in that regard. But how many
people need to be able to easily create a new math operator? Is it worth
making it difficult to change the font size of headings?

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

It was for many years for >98% of the users when IE had near-total market
dominance. But W3C rejected sanity and refused to fix the spec, insisting that
IE should break every website on the planet and implement the W3C box model.

This was a major PITA for anyone who cared enough to design a website that
worked equally well in IE, Firefox, and Opera, which became an increasingly
annoying problem as Chrome and Firefox gained in popularity. A great many
developer hours (including mine) have been lost on the W3C's foolish
stubbornness.

~~~
gsnedders
> It was for many years for >98% of the users when IE had near-total market
> dominance.

It never reached that high: IE was only around 80% at the time of IE6's
release (and IE6 was the first version of IE/Win to support quirks mode,
allowing the change without breaking sites; IE5/Mac had shipped a year
earlier, but never had the marketshare its Windows counterpart had).

------
terandle
Some of these seem very nit picky but if we are doing that my pet peeve was
that the “color” property should have been named “text-color”

~~~
SimeVidas
It affects non-text as well, e.g.,
[https://jsbin.com/wodevam/edit?css,output](https://jsbin.com/wodevam/edit?css,output).

~~~
ronaldj
Wow. I've been writing CSS for 10+ years. I never knew that.

------
stevebmark
I think you forgot the "C" in CSS

I think you forgot that everything is in a global, conflicting namespace,
where people thought global naming conventions like BEM were a good idea vs
actually solving the problem

------
Zarath
Wow I just started making websites of my own recently and have encountered so
many things that are immensely infuriating about how the language is
interpreted that I've been thinking about starting a list myself.

They seem to favor implied behavior rather than explicitly defined behavior
which is incredibly annoying. For example, space between inline-block elements
that is not accounted for by margins. The fact that margin-top and margin-
bottom percentages are computed based on the width of the parent element, not
the height. The fact that certain properties like max-height are oftentimes
not respected if they use a %, even if the height can be precisely calculated.
The fact that I have to add body { margin: 0; } to everything. I'm sure there
have been more but just what I can think of off the top of my head.

Oh, and COLLAPSING MARGINS.... WHAT THE HELL

~~~
scns
I often feel annoyed too but CSS what we have been given to work with. Instead
of wasting time being annoyed that reality does not match our expectations it
is better for our health to swallow the bitter (red?) pill, accept reality and
learn CSSs idiosynchracies. The page
[http://book.mixu.net/css/](http://book.mixu.net/css/) shoud help.

~~~
adamrezich
>You may have used z-index to "fix" the relative stacking order of content.
But did you know that z-index is not absolute across the document, but rather
relative to a stacking context?

wait what the FUCK

------
bsheir74
Css is fine. Not perfect but fine. It's an approachable way to style documents
that look ok on different devices. It's best when used sparingly.

When I see people complain about css, they usually fall into a few camps.
First theres the person who wants everything to look the same everywhere. They
want web design to work like a print document. Sorry but thats now how it
works.

And then theres people who are writing web apps, not documents. I feel sorry
for those folks. Cuz css does suck for that, and there's no easy solution.

But for documents, css is fine. Although it wouldnt be as important if you all
marked up your documents correctly in the first place.

~~~
pjmlp
The problem is that there are plenty of us, because although it is possible to
make a living with native projects, it is Web that pays most of the bills on
UI development.

At least 2018 is the year we finally catch up with the native 90's regarding
components.

------
vertline3
A new software engineering maxim:

"The bar of complaint will rise to meet any improvements"

~~~
afarrell
Nah, I've definitely used some software which had fantastic cognitive
affordances, fit in my working memory really easily, and which people broadly
agreed were fantastic.

[http://docs.python-requests.org/en/master/#the-user-
guide](http://docs.python-requests.org/en/master/#the-user-guide)

------
sireat
I get a serious case of impostors syndrome when it comes to CSS. 20+ years of
HTML, 15+ of writing Javascript, loving ES6 but CSS gives me fits.

What I hate the most that there really is no clear parent - child abstraction.

This parent child abstraction (all the way down to turtles) is present in most
reasonable UI frameworks. I'll take Windows Forms or Qt any day of the week
over CSS.

In CSS this abstraction leaks all over the place. Elements can do whatever the
hell they want (z-index, pos, box sizing before International Border-box Day,
etc).

CSS Grid was supposed to solve layout. It still has a long way to go.

For example, teaching at a bootcamp I ran into the following:

[https://learn.freecodecamp.org/responsive-web-design/css-
gri...](https://learn.freecodecamp.org/responsive-web-design/css-grid/limit-
item-size-using-the-minmax-function/)

By setting a hard limit in pixels(as required in the exercise) you break the
grid for smaller sizes because items go outside parent.

So what do I tell my students? Avoid px whenever possible, use media queries,
em/rem and percentages.

That's all good, but there is no coherent mental model to think about UI
besides bunch of arbitrary boxes which can do ANYTHING.

In a good UI your child elements should stay within the parent(via scroll
etc), not so with CSS. There are no guarantees whatsoever. Someone will come
up with !important !important pretty soon.

------
tokyodude
> background-position and border-spacing (all 2-axis properties) should take
> _vertical_ first, to match with the 4-direction properties like margin.

Is there some reason why margin/padding is top, right, bottom, left instead of
left, top, right, bottom or left, right, top, bottom or both of which would
seem more common in other APIs

~~~
Haydos585x2
My guess is that it works the same way a clock does. Purely a guess though.

------
sizzle
If someone just getting started in front end dev as a hobby and knows HTML,
CSS classes, IDs, selectors, basic inheritance rules and the most of the top
commonly used CSS declarations but nothing about centering or aligning
elements, other than abusing the box model to move elements around the screen:

e.g.

.class { margin-bottom: -50px !important; }

would you recommend starting with CSS Grid or Flex box tutorials for learning
alignment and why?

I'm getting the hang of {flex: # # #%;} grow, shrink, basis construct, but is
CSS grid the future and should I cut my losses and start there? My time is
limited as this is not my main profession.

Thanks in advance.

------
Brajeshwar
“New ideas will come along, but they will extend CSS rather than replace it. I
believe that the CSS code we write today will be readable by computers 500
years from now.” — Håkon Wium Lie, co-creator of CSS.

~~~
c-smile
Yeah and that puts enormous pressure on what we put there.

That flexbox, half-baked and overcooked at the same time. And display:grid at
the same time but using completely different concept of flexibility (fr units
in grid) and some strange property in flexbox.

What, the hell, this means:

    
    
        div {
          width:400px;
          flex:2;
        } 
    

? Just a humiliation of CSS box model.

------
c-smile
flexbox, grid, table,etc. shall be values of some 'flow' or 'layout' property
as they define layout model of element's _content_.

'display' values shall just define requirement of _the element to its
container_ : display:inline, display:inline-block require flow:text container
and display:block require flow:vertical, flow:horizontal wrapper.

So it shall not be display:inline-table, display:inline-flexbox and the like.

------
tannhaeuser
The principal mistake of CSS IMHO is that it invented new syntax for what
should've gone into HTML attributes (like SGML LINK and FOSI did). This then
led to inconsistent ways of manipulating display properties (CSSOM etc.) and
also to the identity crisis of HTML (postulating "semantic" HtML when markup
is as syntactic as it gets).

------
fouc
It would be nice if it was possible for devs to create their own CSS-like DSL
and get the browser to use that instead of CSS.

~~~
pmarcelll
I started to work with HTML and CSS recently, so I'm still learning. To me it
seems that CSS preprocessors are the closest thing to what you descibed,
although the output is still CSS.

------
jetzzz
CSS should have used linear color space for gradients and blending instead of
sRGB. I don't want CRT emulation in 2018.

[https://lists.w3.org/Archives/Public/www-
style/2012Jan/0615....](https://lists.w3.org/Archives/Public/www-
style/2012Jan/0615.html)

------
c-smile
Fr units (fraction, measure of flexibility) shall be allowed on
width,height,margin,padding and borders.

Instead of using flexbox I should just be able to write:

    
    
        label { width:1fr; } 
        input { width:2fr; }
    
    

to distribute the widths in 1:2 ratio.

Easy, obvious and has very good mental model - flexes are just springs where
fr unit expresses their strength.

------
kryptiskt
For what could have been:

"The Languages Which Almost Became CSS" [https://eager.io/blog/the-languages-
which-almost-were-css/](https://eager.io/blog/the-languages-which-almost-were-
css/)

------
c-smile
It shall not be `display:none` but rather `visibility:none;` to exclude
element either from layout or rendering trees.

------
c-smile
It MUST be a way to reproduce <center> HTML by CSS means solely. No way so
far.

~~~
rimliu
I know at least three without using tricks like negative margins.

------
SimeVidas
Emphasis on incomplete.

------
jiveturkey
are there any efforts underway to rectify the horror of css?

~~~
MaxBarraclough
When it comes to widely-used web standards, we tend to be pretty much stuck
with them forever. They get extended, but not replaced.

------
sureaboutthis
A lot of the complaining in this thread is not what the article is about but I
always find that too many people look at CSS usage from too high a vantage
point without understanding the fundamental workings. It is that issue where
people find themselves in trouble getting properties to interact with each
other as expected.

One example, and not the best one, is 'width'. People want 'width' to be the
total width of an element as displayed in the viewport but 'width' was never
specified that way. It is the width of the content, such as text, exclusive of
padding, borders and margin. But people don't read the specification, then
struggle getting layout to look as they wish and blame CSS as not working "as
it should".

Quite frankly, in most cases, CSS works exactly as it is specified and most of
one's problems go away once that is understood.

~~~
bunderbunder
There are legitimate grounds to argue that the way CSS was specified is
_wrong_.

The fact that people find it so confusing is one. If people intuitively think
that "width" is the total width of an element (an entirely reasonable
assumption, mind), then that would imply that CSS chose an unnecessarily
confusing name.

Another is from the mental load perspective. If I'm doing a layout, I want to
figure out how things fit by looking at the total space they take up. _That_
is the width I care about. Leaving margin out of it makes sense, but having to
mentally add the padding and border to get from "width" to "no really width"
is annoying.

~~~
sureaboutthis
Today, many people want to modularize components/elements for placement in an
arbitrary way. That is, they want to be able to plunk down an element on any
page and make it all work together. However, if one uses 'width' as the total
width of the element, including margin, borders and padding, it could mean the
spacing between the content, pre-arranged in that way, may not fit the design
of the page giving it too much margin or padding making it look awkward. Then
the designer is stuck with that if he doesn't have access to changing the
elements margin/padding.

If `width` only means the content, then a designer can plunk that same element
down and adjust padding/margin to fit any design easily.

This is one example of an issue others would complain about.

~~~
bunderbunder
These kinds of tradeoffs can be handled better, though.

It's worth taking a look at how Windows Presentation Foundation does things,
for example. It places the decision of whether to size individual elements
according to their content size, the size of the container they're being
placed into, or their total width front and center, in a way that, IMO, leads
to less head scratching and compromises.

I think the issue here is that CSS was originally envisioned primarily as a
styling tool, and layout functionality was bolted on as an afterthought,
through a design-by-committee process. So, yes, it works, and anyone can learn
it, but it would be nice if the overall effect were one of a technology that
had a clear plan all along.

