Incomplete List of Mistakes in the Design of CSS
wiki.csswg.org
wiki.csswg.org
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.
That's not what a layout language is for. A layout language needs to be able to specify "A goes 10 px to the left of B".
"CSS, a language for specifying visual appearance on the web, is … so complex that it has never been implemented correctly; yet, successive versions specify even more complexity. At the same time, it is so underpowered that many elementary graphic designs are impossible or prohibitively difficult, and context-sensitivity (or anything computational) must be addressed externally. Most CSS lore is dedicated to describing the tangles of brittle hacks needed to circumvent incompatibilities or approximate a desired appearance."
I don't think CSS layout issues could be described as a 'fundamental design flaw'.
CSS originally didn't really address layout at all - it was about styling the content of documents. IMO it's a stretch to say layout was 'fundamental' to CSS.
The fundamental parts of CSS are the way multiple styles from multiple places are inherited down a nested tree structure and applied or overridden based on their specificity. For it's time and the constraints it had to work with (ie preexisting HTML handling the structure), I think it was an elegant solution at heart. Especially when looking at it on context of the problems it was solving.
Sure the world moved on and demanded more and more from CSS with little help from popular browsers, but that all came later on as the web exploded.
> 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.
Why do you think CSS only deals with one thing at a time? CSS is all about how the element behaves in relation to it's relatives (eg parents and siblings etc as defined by the HTML). But it is about matching rules against the existing document structure rather than defining the document structure.
- "A goes TO THE LEFT of B"
- "The header goes ABOVE the content"
- "The list goes INSIDE the table"
- "The menu goes BEFORE the advert"
A layout language without prepositions isn't much of a layout language at all.
It's specified in two halves: the parent lays down general dictates about how its children will be laid out (via 'display' and the layout-specific properties like 'flex-flow'), while the child responds with details about how it would like to be laid out (via width/height/etc and layout-specific properties like 'flex').
We never did end up creating a layout mode that deals in direct relationships between elements, for a number of reasons both good and bad, but that's why the CSSWG's Houdini Task Force exists - one of our deliverables is Custom Layout, so you can write JS-driven layouts that interact with the rest of CSS properly. (Today you can't without a lot of hacks, and those only get you partway there.) Custom Layout will be one of our last things to do tho, because it's the hardest, both to specify and to implement performantly (in particular, without slowing down pages that don't use Custom Layout at all, and ideally not kicking the whole page into a slow mode if one widget uses Custom Layout). So it's still a few years out - we've only got rough ideas for how the spec will work right now.
(Some of the reasons we haven't done direct "X is 10px to the left of Y" layouts: (1) CSS's syntax isn't built well for it. The rule/declaration dichotomy privileges one element, the one matched by the selector. There aren't good, reliable ways to select a unique element for the other end of the relationship. IDs aren't good, because they're page-global; everything else is too promiscuous. (2) Too easy for things to overlap in bad ways on unexpected screen sizes. Authors often develop for the computer they're on, and most don't pay much attention to screen sizes they don't own devices for. Existing CSS layout modes all degrade more-or-less gracefully, because the parent has ultimate control over where the children go and can avoid making them overlap. The exception is abspos/fixpos, which are the closest to the direct-relationship layout mode, and which can easily cause bad layout - see almost any page using position:fixed and designed for desktop, then viewed on a phone's screen. (3) It requires being extra-opinionated about how to handle cycles and such. Individual libraries do this fine (and often respond with a simple "don't write cycles"), but specifying it unambiguously and usefully is pretty hard.)
Consider that LaTeX manages to carry out all of those functions (layout, styling, and computation) using only one language.
That makes sense. The problem is that we never got anything close to that.
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.
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.
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.
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.
Us programmers often get this wrong.
Good luck arguing with customers that will only pay when you achieve pixel perfect layouts across all browsers.
Or are able to replicate certain UI behaviors from native platforms.
Doing native stuff again, and I don't miss this type of arguments.
The concept of executing untrusted code is entirely antithetical to security. Javascript, or any Turing complete language, or perhaps that even is too precise a constraint, is a remarkably bad idea for setting the style of anything that is otherwise static. There's no good reason that text and images need be stylized via a proper language rather than static, non-executable statements.
> As a user, I keep finding sites that simply don't work in Chrome or Safari or IE or whatever.
I keep finding sites that simply don't work at all in Firefox with NoScript. Many of those sites are primarily just text and images which don't display otherwise. It's completely insane from a security point of view.
I speculate that it's because these languages are better at certain things, just like having a non-executable language for data, helps keep the data, data only (cue angry lispers), and facilitates easier writing of prose in a mark-up language than a real programming language could facilitate. Just look at markdown.
More over, we invented JSON, rather than just sending JS files between browser and server.
I prefer writing queries using Django's ORM even though it is underpowered.
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.
The old IE old model is exactly box-sizing:border-box;
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.
Microsoft is a member of the W3C. I don't remember where they were then but, today, they are listed as contributors to writing of the spec and I'd assume they were then, too.
The box model has not changed and your statement calling this CSS box model property "more logical" is an opinion. My opinion, as well as many others, is there is nothing wrong with how width/padding/border/margin works. Some complain that width should include all that but, to us, it's perfectly logical the way it is.
This new property is only a different way to set the same thing but, again, the model has not changed in any way.
Regardless of the model you prefer, browsers all need to adhere to the same model; that's the point of standardization. Whether Microsoft thought they had the right model or not, they selected a model that differed from the web standard.
There are still reasons to size the content-box, but that's what box-sizing is for (or some equivalent mechanism).
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.
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).
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.
(for a while I thought <script type="text/dart"> might get real… oh sweet naivety)
<script type = "x-shader/x-fragment"> … </script>
(Although the process you have to go through to hook a new script type is painful. There are, like, four different cases you need to consider, and scripts have to be processed in the right order but handled synchronously, and...)
HTML+CSS for publishing static, stand-alone documents isn't all that bad. It's terrible for making "applications", and it's terrible for composing more than one thing into a page (such as a header, footer, table of contents/menu).
I still think Adobe's idea[1] of flowing content through boxes (aka the "desktop publishing way") makes more sense than many of the other "augmentations" for CSS in terms of allowing complex layout. But it is an idea that makes sense for basically composing pages - not really for "applications".
I'm not convinced there's much of a meaningful overlap between layout for hypermedia meant to be read/watched/consumed - and "smart object graphs"/"applications" that are meant to be interacted with. Other than that the latter can be used to build the former -- but that's a terrible way to approach standardization -- just for the problems related to accessibility and machine readability alone.
If we could agree to keep the two things separate, make some real effort into making better readers for better (but probably dumber/less feature-full mark-up) -- we would probably be better off. Even such things as readability[2] shows the merit of this: it shows, by existing, the virtue of a browser that is better at being a hypertext browser is useful (and that a browser that's better at being an application run-time can be used to build and host a browser that's better at being a hypertext browser...).
But I don't think we should need for users to relate to that many layers: an OS and standard library that acts as platform for applications, an application that acts as a platform for applications and an application in the form of html+js+css+possibly some server side magic that acts as an application for browsing hypertext. I'd very much like an application (a browser) that's actually good at just browsing hypertext too.
[1] https://www.adobe.com/inspire/2014/01/complex-layouts-reflow... (Now dead AFAIK, even though there's a js polyfill)
[1] http://www.opqode.com [2] http://www.mos6581.org/rinohtype_status_update_1
(I'm RinohType's author)
[1] https://en.wikipedia.org/wiki/NeWS
NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:
used PostScript code instead of JavaScript for programming.
used PostScript graphics instead of DHTML and CSS for rendering.
used PostScript data instead of XML and JSON for data representation.
Well, which is the mistake?
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.
We're trying to fix vertical centering, at least. The alignment properties from the Align spec <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.
> 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
<div id="myDiv"><ul>...</ul></div>
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.
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/>. It's not the best name, but we're stuck with it. ^_^)
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.
though this oddity/hack allows to responsively & proportionally scale images and backgrounds.
CSS presumably uses the colon for clarity.
It's just a separator between the two semantic halves of a declaration. It could just be a space, but it wouldn't be quite as obvious. Compare "display block;" to "display:block;"
It wouldn't save characters, either - you can omit spaces around the colon today and have the same number. That is, "display block" and "display:block" are both 13 chars.
There is indeed nothing requiring a colon vs a space, as the grammar is unambiguous either way.
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. ^_^)
I mean, other than it's there on the browser, is there anything else?
input[type="submit"]{}
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.
1. CSS
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.
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.
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.
"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