On a similar note, i think this Bret Victor quote captures the frustration of the CSS experience very well:
"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."
> This doesn't even address the fundemantal design flaw with CSS
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.
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.
CSS layout is about two things - the relationship between an element and its parent (and its siblings to a lesser extent).
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.)
Well not _only_ two things, but the idea is that you need to specify _relationships_ between objects. You can't do that by just considering each object in isolation.
- "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"
You could try and combine more than two objects together in a single rule, but it's obviously easier to specify the rules one pair at a time.
A layout language without prepositions isn't much of a layout language at all.
XML to the rescue! The alternate future of the web! XML + XSLT (stylesheet)-> XSL:FO (intermediate XML language for formatting) -> FOP (program to convert formatting objects to output) -> rendered format. XML all the way down! (One mistake, zero output.)
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.
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.
> 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.
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.
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.
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.
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.
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.
Much of the government and enterprise sectors don't want to upgrade their browsers. They put a lot of money into their crappy intranet apps around 2000, and don't want to pay to have them rebuilt; since those require the old browsers to stick around, the new apps will still have to run on the old browsers.
I only was able to stop supporting IE7 this year :-P The only thing that has forced some of our customers to upgrade has been a year of successive SSL exploits that have rendered old browsers/OS insecure.
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.
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.
As of today, you are right. However, we should be aiming towards a future where amateurs don't have to worry about browser incompatibilities. Coding time to be focused on building the product and its features, not juggling css rules to make it look the same across browsers.
Nobody bats an eye when you use Python for logic, sql for querying your database and regex for searching text. Unlike the front end, there are ample opportunities for "uniting" the backend in one language, yet nobody really seems to bother.
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.
As a very busy CSSWG member... I agree. There are a number of benefits to the current structure, but I highly suspect that if the web were invented today, styling would a JS-mediated aspect of the DOM, not something fully separate like it is today.
Those aren't problems with CSS - those are problems with how Facebook architected _their_ CSS. A lot of those don't apply to well-architected projects.
These seem to be problems with Facebooks architecture rather than general CSS problems. For example they claim you have to use "global variables" like in the selector ".button-depressed". But you could just use ".button.depressed", thereby scoping the depressed-class.
They were right on the object-level (they chose the superior layout mode), but wrong on the meta-level (they violated the standards process). At the time, the harm from the meta-level violation far outweighed the object-level improvement, to the point that it led to everyone else in the web design community teaming up against Microsoft and tearing down their dominant position.
> 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.
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.
What frustration? The IE box model is the superior model. It's the way graphic designers naturally think about layout: You make a box then fill inward. Easy grid based layout. It's insane to figure out the size of your inner content and grow out—always subtracting from your desired total width.
The frustration due to IE having one model and the spec and every other browser having a different model. Everyone who worked with CSS in the dark ages of IE6 felt that frustration.
Yes, that's the point. ^_^ IE's "'width' sizes the border box" behavior was the better behavior. This was very early in the CSSWG's life, tho, and the group as a whole was less mature, so it didn't value back-compat and supporting actual pages as much. I wasn't around at the time, so I can't be sure of exactly why people preferred the content-box sizing model, but regardless, it was a wrong choice for compat at the time, and in hindsight, it was the wrong choice for the sizing default.
There are still reasons to size the content-box, but that's what box-sizing is for (or some equivalent mechanism).
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.
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.
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.
Many years ago, I read that Microsoft "misinterpreted" the spec but I don't recall the source.
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.
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.
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.
> 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).
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.
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)
I have a toy which allows <script type="text/smalltalk">. The scripts get transpiled on-the-fly to Javascript.
(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...)
Back in the day, IE4 supported both javascript and vbscript. And from memory if you installed other eg ActivePerl (and ActivePython too I think), you could use them as well.
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.
When we implement Display PostScript in js, so we can use it for the web?
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.
Hey, as long as you're implementing Display PostScript in JS, throw in light weight threads, arbitrarily shaped canvases, events, interests, air tight synchronous event distribution, monitors, object oriented programming, networking, binary data encoding, object reference tokens, and implement NeWS! [1]
RinohType [1] combines a CSS-inspired style sheet system [2] with a powerful layout system based on boxes ("containers"). It currently only outputs to PDF but an SVG backend could be added without too much work...
Alone yes, but the whole XHTML alongside all the XML modules that were being defined was a vision oriented towards to what XAML or other native layout engines offer.
> 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)
Both, either. ^_^ Having wrapping behavior split the way it is today is wrong - either all of it should be in white-space, or none of it should be. (Moving it all out into a separate property is probably best, so white-space can keep just being about white-space itself.)
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.
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/> 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
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.
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/>. It's not the best name, but we're stuck with it. ^_^)
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.
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...
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.
I assume you mean property names, because keywords are all over the place and don't have anything to do with colons.
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.
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. ^_^)
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.
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.
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.
"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
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.