Sunday, August 19th, 2007

The Future of CSS and the end of 3.0

Category: CSS, Editorial

We have all been frustrated with CSS over the years. The implementation has been spotty across the browsers, and it has all but died off. IE 7 stepped up and fixed a lot, even if some weren’t happy with how far they got. CSS 3 has been out there for quite some time, but apart from Opera, other browsers have selectively implemented their pet features. Some have done interesting non-standard work too: -mypetfeature-foo-bar.

Today, I was sitting at BarCampBlock in Palo Alto, participating in a session on CSS futures. I got to see the doppelganger effects of CSS in action:

Random Features

How do new CSS features get into the browser? Do engineers throw in what seems cool to them? Is it based on input from some small part of the community? I have heard quite a few “yeah, this is just cool so I want to implement it for v.NEXT” comments.

The micro-picture

People get in the weeds on tiny little features to implement. We see subtle tweaks, and little features that are nice to have but they miss the elephant in the room….

Undercover Elephant

CSS is great for simple web style. CSS is awful for layout. Rich Ajax apps need layout. You spend the majority of your time trying to get CSS working correctly!

There are various people starting to fix the problem. Hell, you can even use ascii art for layout.

It isn’t like there aren’t good examples of how this can work. Just take a look at XUL, XAML, and Flex.

It is time to create a CSS module for layout that works. Take the best of those above, and make it happen. You only have to work with simple examples to see how hard it is to get things right with current CSS, let alone looking at the code behind something like Gmail, that has to rely on subtle bugs to even work.

It sounds like CSS 3 as The Big Unit is basically dead, and small modules are the way forward. We should see good support for CSS 3 selectors, media queries, and who knows what else. Hopefully that new layout manager!

What would you like to see?

Posted by Dion Almaer at 12:27 am
57 Comments

+++--
3.4 rating from 85 votes

57 Comments »

Comments feed TrackBack URI

Fair enough, Scott.
A rudimentary Google for ‘css grid layout’ gives us these excellent articles:
A List Apart’s Flexible [Grid] Layout, from 2002
Another great ALA Grid post, from 2005, which leads us to Mark Boulton’s excellent 5 part fixed/flexible CSS grid guide – very popular, highly recommended. In fact, there are scores of articles dedicated to CSS (and grid/broken-grid) designs now. Which is why, as Jeff Atwood notes at CodingHorror.com,May 29, 2007:

…basic CSS grid layouts are a fairly well understood science by now.

I agree, a language that works on “most machines/OSes” is either “basic” or “hackish”, especially as we try to bend it to new extremes with new technology/techniques. As is often true, good things don’t come easy, and easy things aint usually good. But one can always learn, and an easy google search is often a good place to start.

Comment by Charles — August 21, 2007

“But one can always learn, and an easy google search is often a good place to start.”

you really acuse those of us, who use tables as for app interfaces, being stupid or in our first steps in web dev.

using css religiously for every possible layout wont solve anything more, than one’ self esteem. anyone who tried to use pure CSS grid laypout sooner or later in their steps encountered a problem that required JS to fix, or incredibly ugly css hack. making a webpage for one browser 100% in css is relatively easy, making it for ie+ff starts to be tricky, making it for opera, ff, safari, and both ie’s almost always reaches the state of layers of hacks and hacks. some of these hacks dont work with eachother. and going entirely JS-way (like proposed layout libraries) isnt a solution either – CPUs are powerfull, but even modern ones can be killed by overJSed webapps.

you could be stubborn and go for hacks, or go and use that horrid thing called table. screen readers most probably are going to be fooled more by JS workarounds and on-the-fly generated layout, than lone table or two. so i dont get that accessibility arguments. esp. that most applications that table-users were talking about, are used by 100% healty employees of some big companies.

one well placed table, maybe hurts css-purists, but it solves so many CSS-inducted problems, while breaking so little, that i realy dont get the point of trying to remove it for no-matter-what-cost. what is a bigger abomination – table (one, seldom two, very rarely more) used to get 100% working application layout across the browsers, or a JS+CSS hacks that do the same, but most probably are goign to completly fail in a browser,that autors havent tested it in.

all grid solutions use css hacks, and all of them fail after reaching certain site complexity. positioning, layers, overlays.. it all works neatly, until hack A disables hack B and all hell breaks loose..

Comment by sid — August 21, 2007

@Charles:

Ah yes the CSS stylings of Molly E. Holzschlag. I attended one of her talks at ajax experience and asked this exact same question why is the grid system bad? I went with a completely open mind. I really thought she’d have some insight that would help me understand why CSS completely ignores them. And, I got the same “Don’t constrain your design to a grid” answer from her. She didn’t give me any practical explainations about why it was hard to maintain, or difficult to modify. It was the old “Just think of the possibilities” answer. Quite frankly I was tremendously unimpressed just like I’m unimpressed with the pro-CSS zealots arguments on this forum. I guess I should have seen it coming after I sat thru her talk hoping she’d give me that higher level understanding about CSS showing me something I’d missed along my journey, but no I had really covered most of it. She recited the same old techniques I saw on the web for building a table less login form. And, remarkably I’m getting the exact same answer as to “Why Grids are bad” from most of the people defending CSS. And, when they can’t answer my question they freak out and tell me that I’m whining or I suck as a developer. And, that I should learn CSS. I learned CSS. I sought sage advice from Molly after teaching myself for 4 months. I read numerous A List Apart articles. I’ve been to w3cschool and read the tutorials numerous times. And, I gotta say CSS is still not good enough. It’s not easily expressive.

CSS’ answer to the predictable alignment is using fixed widths! Since when has this been a decent solution to line items up. If I had a real grid solution then I could at least let the browser figure out the size of the cell based on the content it contains. What happens when “User” turns into “Internaute” in French on my login form? Oh and remember to indent the margin-left: to be the width of all the cells before it plus a little white space to make it look nice. Calculate that up, run it, and….It looks like crap. Aw I see I forgot to use float? WTF why the hell do I have to use float to line up stupid boxes! Oh and finally add a clear to wrap the lines. Was that all clear? Going through this exercise is like writing DB code in assembly. I’m writing low level code to teach my browser how to create a grid. And, my results are even less flexible than if I had a proper grid. What’s wrong with this picture? We should be able to communicate with CSS’ layout in a higer level way. “Hello CSS create a 4×4 grid of the following div’s.”

Sure the ability to break away from the grid is nice if you want to do some artsy examples like she has in her articles. I think for websites for MTV or band promotion sites these techniques are cool. But, for 98% of the websites out there it’s not. Usually the types of sites she’s showing as examples of “Grid-free” design don’t have a lot of content, and aren’t trying to make it easier to navigate. They’re trying to do something visually interesting in an fine art sense. Which isn’t what most developers have been hired to do. They just want a nice looking site that’s easy to navigate and find all the content. Why can’t CSS make that easy?

Comment by Charlie Hubbard — August 21, 2007

Regarding CSS, I completely agree with the notion that the Big Unit is basically dead, and small modules are the way forward. CSS has brought aesthetics, innovation and ease but has also made things complex and still has limitations of all kinds.

Comment by Balendu Sharma Dadhich — August 22, 2007

some work draft css3 prop for layout
#element selector{
display: “abcd”, “card”, “tab”
}
http://www.w3.org/TR/2007/WD-css3-layout-20070809/

Comment by chaoskaizer — August 26, 2007

> “You spend the majority of your time trying to get CSS working correctly!”

Sorry but I disagree with this statement, CSS is very easy to use and most modern browsers impliment it correctly. The issues come when you do not understand the technology fully enough or you try to make a site cross browser compatible. It’s the browser implementation at fault, not CSS.

Comment by Fu — August 26, 2007

Okay – i spent a lot of time using flash instead of HTML because following things are pain in the ass for some reasons:

*) Fonts: Antialiasing and custom fonts. It is a layout/design question whether or not you want the font to be antialiased and whether or not you want a different font. For sure i am very well aware of the fact that a font in the web can be copied but its a huge need for the versatility of html as a document language.

*) Calculative sizes: (100%-40px) … i don’t know how often i ran into problems by missing something like that. Same goes for ranges:
(from 40px to 120px) so if there is not enough space use at least 40px else go up to at most 120px.

*) Excluding selectors: It is possible to include more than one selector but its not possible to exclude one. I always needed to rethink structures(eigther html or css) if my client needed this or that to be added.

*) dedicated parents off the tree structure: Right now the offset parent has to be in the same structure as the node. So if you want some subtitle to be same sized like the dynamic element on the left you had to eighter fix some size or use javascript or change structure. So a “size-parent” would be a straight & nice stuff.

*) Rotation: At least 90° steps but for sure *° would be better imho. Its something straight missing for a while now.

*) Nice but not really necessary: color modes: Having the ability to set the color overlay mode just like in photoshop is sometimes avoiding a lot of pain.

*) Antialiased images: Not every page wants or requires antialiased images (proper antialiased images) especially if they are ment to load fast (and use the right size anyway). But some pages (most i work for) require that scaled images are proper antialiased. Since i mentioned before that antialiasing is a style-specific element i really miss to see it. (Actually if you combine it to the 1st point: Antialiasing optional for everything)

*) Nice and colorful (but useless): Reflections. Every newer page uses SVG based or whatever used reflections for almost anything, sure its a trend since its they figured out how it works some time ago. I think it will sooner or later establish its way for some pages and it would be really nice to have it for every element (including svg and input fields).

*) Seperate hover areas: How many times i needed to trick to get the hover area to the place i wished even if there was no way to get there.

Comment by Martin Heidegger — August 27, 2007

Leave a comment

You must be logged in to post a comment.