These are my notes from "The Future of CSS" panel at SXSW 2012. Tweets about this panel are under #sxswcss4.
This panel was moderated by Divya Manian @divya.
Q: What CSS features excite you the most?
Flexbox and grid, the upcoming layout specs. Flexbox should be in browsers by the end of the year. This is the first time we'll have something that's designed for page layouts.
Q: How can I use upcoming layout modules and not break legacy support?
That's a hard question right now. There's a spec that David Baron is writing right now which will let you test for what css properties are supported. Once that appears, you'll be able to use these things really easily. I would suggest using modernizr or similar tools that will throw a class on there.
As more and more market share is taken by browsers that support these features, we'll get more flexible and sophisticated-looking layouts.
Q: Will there ever be a selector that selects the parent of an element? You can do this in JS.
There might be. People keep trying to specify it, but browser developers are not super enthusiastic about implementing it. It's hard without being slow. Not in JS, because you don't need to worry about what the selector matches when the DOM changes. But with CSS if something changes in the DOM, you have to re-scan the DOM for selector changes. Right now you only need to scan children and some siblings. Eventually we'll figure out how to do this well, but it's too hard to implement right now.
I think we need selectors for batch processors, that only run once. That way we can have these totally resource intensive but useful selectors. There is a spec in Selectors 4 but this may wait until Selectors 5.
Q: Why is it called CSS3 and what is in it?
CSS3 is a marketing term only. It refers to everything after CSS 2.1. After CSS 2.1 we decided one giant spec was horrible and difficult to maintain. So there are some specs that are at level 4, some at level 1, included in CSS3. In order to organize this giant tangle of numbers, the CSSWG publishes a snapshot which denotes what modules are stable now. Soon it will pick up some modules when they're done and prefixed and have test suites.
If you want to submit tests, there are instructions on the wiki: csswg.org. If you go to the tests section, there are descriptions of the test cases and where to submit them.
Q: CSS used to be used for visual styles, but now CSS touches more. Is this good or bad?
I'm interested in tracking the CSS preprocessor framework to look for new things to put into CSS. There are a few really popular ones that are hard to implement and easy to understand and use such as variables, nesting and mix-ins. I would like to get these into the language; we'll see how they work out.
Q: CSS modules sometimes roll back from CS to Last Call Working Draft. Why?
The more common reason is that we need to make some edits or minor fixes, and in order to change the candidate recommendation the W3C currently requires us to go back to LCWD. This is not a great process. In that case, it's still really a candidate recommendation that's mis-labeled.
Sometimes though, the modules is super-broken and should really not have been an candidate recommendation. An example is the CSS Text module, which got pulled back to working draft. Also, the CSS Ruby module, which has no box model definition.
We've gotten a lot better at avoiding the second problem in recent years, but pre-2004 CRs that fall into the second category.
Q: Why aren't the specs more developer-friendly?
Specs are not designed for you. They're developed to help implementers help implement the specs in the same way. They are basically code, written in English. However it should be readable by ordinary people so that implementers (who are people) can understand it, and the general public as well. We're trying to get better at that, making the language better, making it a little more readable. However, if the choice is between readability and precision, we'll always go for precision.
Also we'll try to put the more boring paragraphs near the bottom.
Q: What features are not proposed, but you want to see in CSS?
Mix-ins don't exist anywhere, and we want them to get in somewhere. At the very least, they help solve some of the prefixing problems, because you can update the prefix in one spot instead of updates across your codebase.
Another feature I'd love to see but which is hard to implement is a general current function, where we can pass in any property, for example width = current(height) to make an exact square. It's really hard or perhaps impossible to implement. We may be able to do that for some subset of things.
Q: Where do you draw the line between CSS and JS or Photoshop?
I think it's going to be a moving line to some extent as people come up with new things that they want to do. We have to think, what are the advantages of putting this into CSS? For example, it gives the browser a lot of flexibility to optimize things, for example for background tabs.
If it's something that needs explicit control, that's probably not good for CSS. If it's something that we can do by providing parameters, that's something we can provide with CSS. We've been moving animations back into CSS as we've been able to do them better. 3D GPU animations, we can do some of that, but the more complex stuff we push off to WebGL.
What can you put into a declarative language that is still easy to understand? There's all kind of cool layouts that you can do in a batch processor that you can't do in CSS. We'll want to do those someday as we add more things to CSS.
Some features can be abused to substitute something that should be in HTML or JS, but could also be used for styling. For example, the content property could be used for all your content (bad) or for decorative characters (good!)
Q: Aren't there certain things that by their very nature will be edge cases and neglected?
The CSS speech will be in CR soon, it's a question of is anybody interested in implementing it? We can't control that, it has to come from market pressures. We can't dictate what vendors will work on. It's always going to be hard to prioritize. The best case is when we can take on a bunch of edge cases with a single feature that's designed for something else. We'd like to see some greater integration of CSS into JS. There's a lot of things you can't do good shims or polyfills for.
Q: How do you respond to the critics of CSS?
I don't think general criticism we can do anything about, because it's not actionable. Some problems are being addressed, some we may be stuck with. CSS and HTML came from a very different world when we didn't recognize the web as being used for apps. It was a very document-centric world. If you have to do backward-compatibility, it's what we have to work with. But, remember doing native apps? All of those systems sucked even more. We can always do better, we can always dream better, and we can get there, but we can't do another XHTML 2 that will fail.
Find the things that you hate and fix them, or explain to us why we should fix them.
Q: Multitouch pseudo-selectors?
Really interesting. There's no real good analogue to touching something. It's more like a :hover. Once you throw in multitouch, that's all kind of crazy. We need someone who knows what's going on with it, which is something that we're sorely missing in the group right now. Sign up for www-style!
Q: What's the single best thing the groundswell can do to push forward web standards?
We have a few minor efforts going on now. You need to make something that can take input from millions of people, and put it in four or five people's inboxes without making it overwhelming. Ben Schwartz has been working on some tools for transparency. Hopefully that will be useful. If you want to work on spec restyling, we are totally interested. Try it out and send it to us. We are not actually designers for the most part.
There's a caveat: the maintainer of our website doesn't like new redesigns.