
Incomplete List of Mistakes in the Design of CSS - arabadzhiev
https://wiki.csswg.org/ideas/mistakes
======
kayamon
This doesn't even address the fundemantal design flaw with CSS: (paraphrased
badly from a quote by Casey Muratori)

Layout is about the relationship between TWO THINGS. If you have a layout
language that deals with only one thing at a time, then you have failed.

~~~
hayksaakian
Html is tree structures right? Every element is default positioned relative to
the previous element.

~~~
est
Unless if you think about it, layout is positioned in a 2D plane (with
z-index, it's a 3D space, don't mention time), not a tree structure at all.

~~~
applecore
Except a tree structure is the only conceptual model that works for composing
a user interface (out of simple, largely stateless components). See, for
example, React and JSX.

------
Cshelton
This doesn't even get to the overall design of css in the first place and the
problems it has... [http://blog.vjeux.com/2014/javascript/react-css-in-js-
nation...](http://blog.vjeux.com/2014/javascript/react-css-in-js-
nationjs.html)

~~~
Turing_Machine
The whole idea of using (at least) three separate languages (HTML, JavaScript,
CSS) would seem weird if it were proposed _de novo_.

Consider that LaTeX manages to carry out all of those functions (layout,
styling, and computation) using only one language.

~~~
wodenokoto
In your latex equation, you are missing where the data goes. The idea for
html/css/js is that data goes into the html, layout and styling into CDs and
interactivity is defined in JavaScript.

That makes sense. The problem is that we never got anything close to that.

~~~
TheOtherHobbes
The problem is it doesn't really make sense in 2015.

Or rather, it only makes sense if you accept the technical debt inherited from
HTML, which is itself the simplified stepchild of SGML, which was a 1960s idea
and firmly rooted in paper publishing.

Separating content and presentation isn't a bad idea. The badness happened
because JavaScript - or some other web programming language - didn't appear
until HTML was established. So instead of a generic object model, with tagged
content containers linked to an updatable library of presentation and layout
code that could be standardised and refined continuously, some semi-standard
version of a sort-of-working layout library was pre-compiled into browsers and
accessed through a not very coherent DSL.

This made it fast enough to be usable - a very good thing, given 1990s
processing speeds - but it also made it much harder to develop and fix.

In 2015 CSS shouldn't really be necessary. So much layout and presentation is
done with JavaScript anyway that it would make just as much sense to get rid
of CSS and extend and standardise on something like jQuery-but-better to
create an evolving cacheable layout library that bypasses browser quirks and
uses exactly one common versioned codebase.

This might seem ambitious, but writing good code that works across all common
browsers now is such a nightmare for everyone that too many devs are either
not bothering, or their bosses are telling them not to bother because it's too
expensive.

As a user, I keep finding sites that simply _don 't work_ in Chrome or Safari
or IE or whatever. That's not good, especially when there's a business at the
other end trying to sell things.

I don't doubt the web will creak along, and some people will do amazing
things. But it's still frustrating when it could be simpler, more
standardised, more consistent, and much more reliable.

~~~
gopowerranger
As a web dev of 11 years, I don't find writing cross browser code a nightmare.
And any web site that doesn't work cross browser is by amateurs at best.

I don't know what web sites you visit where you have such issues but I haven't
seen them in years except for the occasional goofball site.

~~~
Ygg2
As someone that had to support IE6 and Chrome at same time, I can't agree with
this statement.

~~~
gopowerranger
Are you seriously trying to throw IE6 into this to attempt to prove your
point? We aren't talking about antiquated browsers no one should be using
today.

~~~
Ygg2
Are you seriously trying to deny IE6 isn't there in the wild? It was a job I
had to do. I was paid to do it. It was awful. This happened circa 2013.

For contrast I now support IE8 and IE9. Without jQuery. It's bad. Really,
really bad. Like, there isn't indexOf on Array and asking for polyfill is
forbidden.

~~~
gopowerranger
You're one-off job is nothing to be holding up as an example of current web
development. My company has 23 active clients and I can't tell you the last
time, many years ago, we saw IE8 in the visitors logs much less anything less
than that.

~~~
Ygg2
I wasn't holding it as example of current web development. I was holding it as
a sample of web development that happened semi recently. It is also why web
dev can be a nightmare - Legacy systems and browser incompatibility.

It's great if you never had to deal with them, but that doesn't mean it won't
happen.

Note: It wasn't a one-off job either. There were multiple jobs, government
sector.

~~~
gopowerranger
I never said it didn't happen, I dealt with IE4 and Netscape (briefly), and
that you mention "government center" is exactly the area I knew you were
talking about.

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

Didn't older versions of IE do precisely that, leading to endless frustration?
I hate to say it but MS did something right for once.

~~~
gopowerranger
Not exactly. The W3C spec stated the box model should work one way and
everyone but Microsoft/IE did it that way. This is a new part of the spec
which didn't exist back then.

However, since IE had 95% market share, everyone marked up their site
according to Microsoft's model instead of the W3C. It's affectionately called
"quirks mode" and really screwed people up, remnants of which I still see
today.

~~~
userbinator
MS thought the spec was wrong and the W3C actually intended the more logical
model, thus following that assumption when they implemented IE; and why the
W3C didn't change the spec, or why other browsers didn't follow, is I think
more of a political issue.

~~~
olavk
Well if MS thought they had a better model, they could have proposed it to the
W3C and introduced it as -ms-box-model or something. Even if IE's model were
superior, it was disastrous to have two contradicting models in different
browsers. Maybe whole debacle with 'quirks-mode' could have been avoided.

------
randomsearch
This is a totally crazy out-there idea, so be kind:

Rather than trying to create a layout system that can adapt to any window or
screen size, as with CSS/HTML, Java, iOS, etc., what if instead we had settled
on a small number of permitted aspect ratios for screens? I'm carrying the
analogy from paper sizes: A4, A5, A1, etc.

So probably we would have gotten this wrong when we first defined them (see
iPhone aspect changes), but presumably after a while they settle down and then
we can stop testing for the old aspect ratios.

Monitors, laptops, tablets, phones, would all standardise to a set of options
just like most books and magazines standardise to a given size.

I know there are downsides, but imagine how much easier this would be for
designers. Cross-platform UI design would be much simpler.

Just a radical thought I had.

~~~
Achshar
Aspect ratio isn't every thing in design. The size of the window is just as
important. A 3x2 21" screen needs very different UI approach than a 3x2 3"
screen. And standardizing screen sizes is not really a sensible option.

~~~
randomsearch
> Aspect ratio isn't every thing in design. The size of the window is just as
> important. A 3x2 21" screen needs very different UI approach than a 3x2 3"
> screen.

Good point.

I was thinking more along the lines of the fact that design tools and tech
that enable adapting to an arbitrary screen size are unlikely to be as easy to
use and expressive as those targeted for a specific aspect ratio (for example,
you could use absolute positioning).

> And standardizing screen sizes is not really a sensible option.

Suspend disbelief for a moment, or consider only from the POV a single large
corporation / group (e.g. Apple or Android).

~~~
Achshar
It's really about the burden of the effort, it can either be easy for the
users and a pain for the developers or it can be the other way around. We can
standardize the ratios and sizes and that would make things easy for devs sure
but then that would decrease the variety and innovation for the user. If there
really were a handful of fixed sizes and ratios then that would make things
like google glass, smart watches, galaxy edge or any other kind of
unconventional device with non standard display that much more difficult to
ship to the masses.

We don't know what kind of display size and aspect ratio the next contact lens
display or the next building sized display will have. So I believe it's better
to keep our self open to new possibilities.

------
okonomiyaki3000
When do we get to throw the whole thing out and start again?

~~~
Eric_WVGG
I always found it interesting that style tags were designed as <style
type="text/css">, implying that new style standards could be introduced down
the road.

(for a while I thought <script type="text/dart"> might get real… oh sweet
naivety)

~~~
gopowerranger
The script type is a possibility but you have to make it work. I've forgotten
the details.

~~~
toyg
Since the browser will not react to these nodes, you can add some JS code that
will detect them and hand off content interpretation to other mechanisms.

~~~
bsimpson
That's how React's JSXTransformer worked. You can also do the same for WebGL
shaders:

<script type = "x-shader/x-fragment"> … </script>

------
alsonote
> white-space: nowrap should be white-space: no-wrap and line wrapping
> behavior should not have been added to white-space > word-wrap/overflow-wrap
> should not exist. Instead, overflow-wrap should be a keyword on 'white-
> space', like nowrap (no-wrap)

Well, which is the mistake?

~~~
bsimpson
It's so broken that you can only use text-overflow: ellipsis if you've also
set white-space to nowrap.

------
Oduig
If you ask me, a layout language should have simple orthogonal concepts in it.
The reason CSS gets so much hate is, in my opinion, a lack of coherence, a
lack of modularity and terrible naming choices.

You only have to look at vertical centering to see the problem. Situations
that look almost the same require entirely different solutions, often causing
a change to ripple through to parent/child/sibling elements.

~~~
TabAtkins
Yup, that's the problem with having a language that evolved slowly over 20
years, while its problem space changed enormously. CSS was originally intended
as a simple way of styling text documents on the web.

We're trying to fix vertical centering, at least. The alignment properties
from the Align spec <[https://drafts.csswg.org/css-
align/>](https://drafts.csswg.org/css-align/>) do consistent centering (and
other alignment) across layout modes. Currently they only work in Flex and
Grid, but they're defined to work in Block and Abspos as well.

------
kagamine
If I had to pick a favorite it would be:

> descendant combinator should have been » and indirect sibling combinator
> should have been ++, so there's some logical relationships among the
> selectors' ascii art

Now, where do we stand on the omition of a parent selector?

I've seen it mentioned over the years that CSS lacks an all important parent
selector, eg:

    
    
        ul << #myDiv  
    

where the html would appear thus:

    
    
        <div id="myDiv"><ul>...</ul></div>  
    
    

This goes against the entire idea of a cascade. But with frameworks and
templates all over the web it isn't always possible to define the parent tag
yourself, or assign it an ID/class.

For example, I use a framework that generates html from xml documents, I can't
add a class or ID to the parent html tag, a parent element selector would be
of value here. My concern would be that it is open to abuse.

~~~
TabAtkins
CSS selectors always select "down the tree". Or, read in reverse (from right
to left), evaluating them only requires information from further up the tree.
In HTML, "further up the tree" corresponds exactly to "earlier in the text
stream". This means that as soon as an element finishes parsing, we can find
all the selectors that apply to it immediately, enabling better incremental
display.

Of course, that's no longer always true today. In particular, selectors like
:nth-last-child() depend on information from later siblings. Defining a
combinator or equivalent mechanism that allows direct selection based on later
siblings is thus not out of the realm of possibility. And selecting a parent
vs an earlier sibling is almost identical - the parent's start tag is
immediately prior to the first sibling (or text), so the distance between
"thing you're selecting" and "thing it needs to know about to evaluate the
selector" is only incrementally larger. So a way of selecting a parent based
on children is probably fine too.

There are a few issues that have prevented us from doing so today. For one,
it's _slow_. Using a single one of the "backwards" sibling pseudo-classes can
kick your entire page into slow-selector mode, because it breaks
optimizations. The same would be true of parent selectors, probably. For two,
we have to prevent nesting - siblings usually aren't too far from each other,
but the root can be _very_ far from a descendant. (Also, siblings are usually
walkable by traversing an array, while parent/descendant relationships are
typically pointer-based and slower to traverse.) This makes it a bit clumsy to
specify.

That all said, it's on the roadmap. I plan for it show up in Selectors 5.

(Oh, and note, the "cascade" in "Cascading Style Sheets" isn't about what
you're referring to. It's about a "cascade" of values for a given property
colliding on a single element, and figuring out which one "wins". Thus the
Cascade module <[https://drafts.csswg.org/css-
cascade/>](https://drafts.csswg.org/css-cascade/>). It's not the best name,
but we're stuck with it. ^_^)

~~~
kagamine
Thanks for the comprehensive reply and correction.

As I noted in my comment the area in which a parent selector would be of use
was in a framework where I don't always have access to the parent tag where I
could add a class or ID to the html. The way around this, because we got it
fixed finally, was not to wish for a css solution but was in fact to have the
authors of the framework create a fix inside the framework itself; where the
limitation actually occurred. It's of little significance to you perhaps, but
it is a point worth noting that the solution lay in fixing the right thing and
not adding ill-advised functionality to the wrong thing.

Also, thanks to you and your collegues for your work, especially flexbox, I
like CSS a lot (I know it gets a lot of criticism) and I believe it is what it
should be.

------
leeoniya
another one not on the list is that any padding specified in % is always % of
width.

though this oddity/hack allows to responsively & proportionally scale images
and backgrounds.

~~~
kagamine
Honest question, what else could it be a %age of? Or should % not be an
allowed unit of measurement of width?

~~~
IgorPartola
Height?

~~~
kagamine
Oh, right I see now, padding-top: 5%; is a %age of the width, not the height
of the element. Yes, that makes little sense.

------
toast0
I guess I was expecting a table.

------
_ZeD_
it's not a css mistake, per se, but I always found difficult to reason about a
way to tell "I don't really care how big this widget is, I _care_ that this
widget should be a rectangle with sizes of ratio X"; I _want_ to be able to
make a container, put a _square_ on the top left, a _16 /9 rectangle_ on the
center and so on...

~~~
TabAtkins
Yeah, setting an explicit aspect-ratio is on the roadmap. The relevant people
(me and fantasai) have too many other layout-related things on our plate atm
to deal with it, but it'll show up in the next year or two.

------
NickHaflinger
Why do keywords have to end in a colon. couldn't the parser use space " " to
detect the end of a word, like in C ..

~~~
gopowerranger
CSS is text files and there are no line endings.

------
multinglets
I can't help but wonder if the vertical margin collapsing (in general) would
have seemed worth it if we weren't borrowing concepts from print media.

~~~
TabAtkins
It is, still. You want separation between your paragraphs and other elements;
you don't want the first and last children of a box to be separated from the
edges of that box. Margin-collapsing does that (sibling boxes collapse margins
together, first/last collapse with parent and shift their margins "out"), but
it's difficult to do otherwise.

That said, you could do one-sided margins better if we hadn't had naked text
in the layout model. If everything was wrapped in elements, then text at the
start of a container element wouldn't require a margin-top on the first child
element, while text at the bottom wouldn't require margin-bottom on the last
child element. Naked text is a mistake. (And I just added it to the list. ^_^)

------
RandyRanderson
It would be shorter to list what is _good_ about CSS.

I mean, other than it's there on the browser, is there anything else?

------
xienze
All that and nothing about variables?

~~~
kagamine
I find myself often wishing conditionals on CSS until I remember that they
aren't necessary because things like

    
    
        input[type="submit"]{}  
    

exist (but feel hacky as can be) and that if they did exist I would never,
ever want to edit someone else's CSS file. Can you imagine the mess?

It would be nice not to have to look for a style:

1\. inline html

2\. in the CSS file(s)

3\. in JavaScript (or js library)

4\. in the source code in the backend

to find that one edit you need to make.

I think that limitation is the most frustrating, that because CSS cannot 'see'
beyond its own little home it bleeds out into other documents.

------
dmux
Complete list of mistakes in the design of CSS:

1\. CSS

------
andrewmcwatters
The term "blend mode" specifically refers to color blending. It isn't just
"blending" nor does the addition of the word "mode" at the end of the property
indicate some sort of redundancy in the attribute name.

This single slip up as an indicator of the author(s) not being familiar with a
particular graphics industry term makes me question the validity of every
other claim of "mistake" on the page.

> rgba() and hsla() should not exist, rgb() and hsl() should have gotten an
> optional fourth parameter instead (and the alpha value should have used the
> same format as R, G, and B or S and L).

Absolutely not. RGB is not RGBA. Perhaps the lack of robust rendering of
webpages across most browsers is due to standards bodies, even lesser ones
like csswg, not knowing anything about the fundamental graphics layers
powering them.

~~~
TabAtkins
trolololol

The term "blend mode" is a term of art in the industry, yes. But "mode" is
always redundant - lots of properties switch "modes", particularly the ones
with keyword values. For example, we could have had "display-mode" rather than
"display", but that would definitely have been redundant. The word "blend"
isn't used for anything else reasonable in CSS's wheelhouse, so using it by
itself would have been fine.

I'm not sure what difference you think you're alluding to between RGB and
RGBA. All browsers store colors as RGBA 4-tuples. Are you perhaps under the
impression that "RGB" and "RGBA" refer to particular color spaces or
something? They don't - nearly all color spaces are alpha-agnostic and can
have an alpha value appended to their color definition. (The few exceptions
are things like pre-multiplied RGBA, where the RGB components depend on the
alpha. But these are rare)

Given that the CSSWG's membership is largely browser implementors, I'm pretty
sure we have a handle on what the fuck our graphics stack does.

~~~
andrewmcwatters
Every argument you made you counter-argued using my own points within your own
post.

1\. > The term "blend mode" is a term of art in the industry, yes.

2\. > For example, we could have had "display-mode" rather than "display", but
that would definitely have been redundant.

3\. > The few exceptions are things like pre-multiplied RGBA, where the RGB
components depend on the alpha. But these are rare.

Yes, because RGB isn't RGBA. If anything it should be RGBA with an optional
alpha. Because you know, that's how the _structs are formed to begin with._

And separately,

> Given that the CSSWG's membership is largely browser implementors, I'm
> pretty sure we have a handle on what the fuck our graphics stack does.

Yes, as far as the people who actually write the portions of browser code that
involve placing pixels on the screen. You however, clearly do not.

I'm not sure what you're doing in a spec committee; you don't sound like a
person who has any experience writing low level code regarding these systems.
Given this, it's worrying because I'd wager that you'd make uneducated
decisions affecting others based on this lack of experience.

~~~
TabAtkins
lolololol obvious troll is obvious

"i disagree with you, thus you must be lying about your experience and
actually unworthy of doing your job, unlike me, the superior being" go get
your diaper changed

