Sunday, August 19th, 2007
The Future of CSS and the end of 3.0
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?
Rounded corners ! Using div and other hacks to get them is really ugly for something that is such an obvious job for CSS - and has in fact been in the spec for a looooong time.
CSS has not only lost it’s way, it’s not nearly integrated well enough w/ the HTML efforts now underway to make any kind of a discernible difference in how we develop webapps.
Long story short, the CSS box model needs to be augmented w/ DOM interfaces for everything CSS can set and read (and I don’t mean “what’s cascaded?” I mean, “what’s the current value?”). The standard idea of what is the viewport and what is the document are *insane*. The lack of any box model you choose for any element is likewise idiotic. CSS and DOM need to figure out that web authors building apps *will* inject layout elements into their documents and not simply try to punish them for doing so, but specify ways to enable this to happen which are also semantic. Shadow DOMs are being delivered by every Ajax toolkit worth their salt because we simply can’t wait around any longer for the the W3C and the browser vendors to get off their asses and make HTML+CSS pluggable in a meaningful way.
We can soundly say that the box model today is a bug and not a feature. Parametric CSS, based on any unit you like, with references and a real expression language is the only thing that’s going to get us anywhere near the expressive power and simplicity of the other markup/styling languages being floated on the market today. The CSS working group’s insistence that CSS isn’t a programming language (or that it’s not even an expression language) is well past it’s freshness date. We can all see through the end-game for CSS2 now, and it’s not pretty. Further bludgeoning of content developers with braindead “standards” only ensures a culture of recrimination and frustration that leads the sane to other technologies and allows those left to claim ownership (and moral superiority) over a pile of junk that grows more worthless by the day as the action moves elsewhere.
Does the W3C have any legitimacy left with which to address these problems in a meaningful way? I don’t know, but I suspect that the answer to that question will determine whether we face mess, wonderful, real competition or simply a withering Open Web.
Rounded corners could easily be solved by the CSS3 ability to have multiple backgrounds. I’d like to see that, in many places have I wished to overlay 3 or 4 backgrounds.
I agree that CSS layout has a long way to go. I hate spending 4 hours trying to get CSS layouts to work when I could get the job done in 20 minutes with tables. I wish relative positioning worked a little more like it sounds like it should work and I wish that block elements were aware of the size of their containing elements so that stuff like 75% was 75% of the containing element not of the page.
Biggest need is multiple background images.
Then there could perhaps be some work on the float-attributes because they weren’t made to be used the way they are used and perhaps if they were made for what they are used it could’ve been easier and simplier to use :)
The biggest problem however is not to get CSS to work - that’s quite easy. What’s hard is to have that CSS work as well in IE, especially version 6, as it does in FF, Opera and Safari and to make it more annoying Microsoft introduced new weirdness in IE 7 not present in IE 6 demanding us to test the websites in both while not supplying us the tools to do so in a good way (breaks conditional comments to have both installed as far as I know)
I don’t think CSS is the problem. Of course it could be more comprehensive and become a programming language, but it’s not. The risk of overlapping behaviour and layout is too big.
A correct implentation of CSS 2.1 in IE/FF/Opera/Safari would be enough. HTML is simple, but I don’t feel it as a restriction. New fancy stuff in CSS would be nice in a perfect world. Unfortunately we still live in a world where it takes years to correctly implement float, deal with font sizes and compute the width of a box.
maybe people should start learning css instead of copy/paste or using “css frameworks”. its not that hard.
(sorry but i cant stand comments like “ooh it took me 4 hours when it could be done with tables in 20 minutes”.
Quite a bit of what folks are asking for is already implemented in at least one of Webkit, Mozila or Opera -
border-radius is in Mozilla (not great yet) and Webkit (Safari 3) - good support
multiple backgrounds are in webkit (inc safari 2)
border-image is in webkit (safari 3 but not yet iPhone)
opacity is in IE67, opera, webkit and moz
box-shadow is in webkit (safari 3, not iPhone)
text-shadow is in webkit/safari, and (rumored) Opera 9.5
for details see
http://westciv.com/iphonetests/
So, we can draw the following useful conclusions
1. quite a few features of CSS3 (a spec largely in draft form) are supported in one or more current browsers. Having implemented draft specs in the past, I can tell you that is risky.
2. using one of these features will not impact the user experience in browsers which don’t support the feature - this is a very big change from the days of CSS1 in IE3/4 and Netscape 4.
Meanwhile people continue to assert “CSS is awful for layout”
I’m not saying that this is entirely false, but can we have some examples of the kind of layout that CSS is awful for that you can do easily?
I recently did this
http://westciv.com/xray/
I have written desktop apps for 15 + years. I would die for some of the UI flexibility of CSS2/3 in desktop UI frameworks.
Has CSS3 to have lost its way - in many ways yes. It’s certainly been a long way between drinks - but as recently eloquently argued elsewhere glacial change is not necessarily all bad.
But I still continue to have the following conversation with professional web developers: “I could do X with tables in (order of minutes) while it is (impossible||takes much longer) with CSS”. From people who have never heard of the descendent selector.
So, before criticising CSS, at least people should be familiar with its more subtle aspects, which have been well documented for a decade in many cases.
@twist - if you give the containing block of an element a positioning context (position: absolute, fixed or relative) then % widths and height refer to that parent element;s wodth and height. The subtle power of relative positioning is that if you give an element position: relative, and no top or left, it will be layed out exactly where it would statically be positioned, and yet, its descendents will take their positioning context from this element, not the page. CSS really is sophisticated and powerful, if subtle.
Even though the article states that there’s an elephant in the room and nobody is noticing it, and the article clearly states that “CSS is awful for layout. Rich Ajax apps need layout.” some comments still think rounded corners or multiple backgrounds are so important. That’s missing the elephant…
So we need is layout. Browse to a Google application and open Firebug. Find some container elements that seem to define the layout of the application. Resize your browser and watch the width and/or height of these elements change. There is nothing in CSS that will do that for you, perhaps in CSS 3.0, but then this is the type of feature not implemented.
The simple fact is that most programming environment including Java, .NET and Flex come with some kind of layout manager, either explicit through code (like in Java) or implicit through a markup language (XUL or Flex, probably XAML too). Google has it in GWT and translates that too JavaScript that will update the layout when resizing the browser.
So we need JavaScript to solve this layout issue. I really hope the current popular frameworks will implement layout managers, because figuring this out is pretty awkward. Elements need to specify 100% height starting from the outermost element, and you need to take in account margins, borders and padding and all this in a cross browser implementation too.
This has been my rant and I really hope to see more layout managers. Ext has one, so let’s get this competition going!
The fact that people are forced to “discover” techniques on how to achieve certain layouts is a testament to how hard it has become. For example, just look at the “clearing floats technique” and look at how it has evolved over the years. The effect itself is very simple and frequently used and readily done with tables by anyone with even a simple knowledge of HTML. But in CSS, the technique was not easy to come by. The first iteration required adding HTML that had a “clear” style. Then it evolved to using “:after” to discreetly add the HTML. Then it evolved to setting an “overflow” on the parent element. Of course all this started because we had to makeshift with styles that weren’t designed for that purpose.
I guess as usual with a standard, the main first problem is its implementation. We loose time mainly applying ugly hacks for IE in our company to have decent portability of our layouts.
If at least we had *complete* support of CSS 2.1 on every A class browser, we’d have less portability problems and a bit more hair on the head.
The World Wide Web is a place where a lot of information is published. It is also used for gaming, pornography and commerce, to name but a few areas, however a major part of it is still publishing information for others to find, explore and read. Publishing text and images has many spoken and unspoken rules if you want it to appear consistent and professional, and one of the most basic of these is column layout. This is not only having text and images in separate columns, but also allowing items to span multiple columns while still conforming to the overall column layout (including column borders) - look at any magasine or newspaper.
Yet somehow this basic area of publishing, like others, has not been made obvious to implement in CSS, especially when you want some elements to span your layout and others to conform to individual columns. I get the impression that the ethos when designing CSS standards was ‘What style features can people implement using HTML? Let’s extract them to divide content from layout, and add a couple of cool things that we think people might like…’ and not ‘We’ve been publishing things for centuries, let’s explore some of that history to learn what’s important for good publishing and so should be fundamental to CSS and also extract any other non-content features included in current HTML’. There is more to publishing than just column layout, but it was the first example that came to my head.
My problem with CSS is not that it isn’t possible to acheive some very basic publishing styles, it is that it does not seem to be fundamental, obvious and easy - the obvious and easy only come once you’ve seen how to do it, and even then it might require some horrible workaround, in some cases bypassing CSS completely.
I dont understand why people are mad at CSS, when they are in fact mad at different implementations of CSS.
I am doing a lot of gtk work and I cant tell you much I would love a SIMPLE solution like css, without the annoying rc_files
in fact, i think this should even become a standard among designing a LAYOUT. How much easier can it get then:
color: slateblue
padding-left: 1em
?
In a unified manner …
“You spend the majority of your time trying to get CSS working correctly!”
Do you mean cross-browser cross-plattform?
Because for me, when i do something in CSS, it just works how i want - but then again I develop for myself and can only laugh about the poor souls that have to cope with everything … ;-)
“without the annoying rc_files”
I forgot to add the complicated themes on gtk too. (gtk-engine)
It is SO MUCH EASIER to specify a .css file, even if its complex…
The Desktop can be so annoying, why dont they acknowledge that the web-world has some GREAT ideas, which they should incorporate
seriously :(
CSS keeps adding stuff to something that’s broken. Like most browsers.
I don’t like the idea of modules to add more stuff from different efforts. Sometimes you just need to start over from scratch.
I think saviour is in taking a step back, instead of adding new features rethink what CSS1 would have been if we could start over. If layout is taken into account from there the web will be a better place.
For about three or more years I’ve read dozens of articles on solving the positioning and align problems using pure CSS, and all of them mentioned a certain amount of hacks required to implement basic things. I don’t understand why so many people are afraid of good old tables. Of course, I DON’T mean we should use tables for all our positioning needs; but many of annoying CSS problems can be solved by using just 1 or 2 tables per page, while specifying anything else with CSS.
Tables are considered by many the worst example of mixing content with representation, but they are not. In fact, most web sites are indeed tables and not just blocks or code. While using tables in the way they were used in 1998 is evil indeed, I think we may still benefit from tables because they are implemented quite consistently almost in all browsers, and this implementation will survive beyond CSS 2.0 or even CSS 3.0.
Don’t throw a working technology into a trash can; it is quite useful and mature.
I would like intuitive implementation of websites for non-coding, non-teksters. And I don’t mean the all but useless WYSIWYG. Here’s my moniter design, push enter, voila. Better yet, here’s what’s my mind sees…bingo…push enter and it’s there. Any takers?
I agree with Alex. As web developers, we have the power of choice. A style definition de facto standard, can save our world. A JSON based standard for layout definition would be defined by toolkits implementors, and then, implemented by each framework in their own way.
Cheers ;)
While this is a very accurate statement, it ignores the fact that part of the reason for the different implementations has to do with the way the spec is authored. Plenty of other specs suffer the same consequences (just look at the SVG spec, for instance)–there are things defined that “have to work a certain way”. Every browser runs into issues with trying to implement it, and *that’s* why there’s so many different implementations.
And like many others here (aside from almost everything Alex said, which I whole-hearted agree with), I think one of the biggest issues is that the HTML CSS implementation (there are others, you know–HTML isn’t the only kid on the block, just the biggest one) is the lack of a grid implementation. It’s easy to do absolute positioning and layering (a la Visio, Illustrator, OmniGraffle, Quark, Photoshop, etc. etc.) but it is impossible to do a true grid without using tables (well, near impossible–height, anyone?). If we’re serious about separating semantics from presentation, a grid mechanism is a must. Period.
(I would say the only thing I disagree with Alex about is the separation of the viewport and the document; I think that makes perfect sense. What I *do* agree with there is the way things are bound to either the document or the viewport, and how one might reference the other.)
Dion and Alex are dead on in their assessment of CSS. Things have truly degenerated from the content author’s perspective.
I am the Executive Director and CTO of The Institute for End User Computing, Inc., a 501(c)(3) nonprofit pursuing the long term grand challenge of designing a new legacy free end user computing platform to integrate the most powerful enabling technologies we can find, make them painlessly accessible to End Users, and thus leapfrog todays’ operating systems while also improving security and stability.
But on a day-to-day basis most of our time is being sucked into the black hole of web site maintenance and development as we busy ourselves behind the scenes working on a radical redesign of our website to make the best use possible of newly available technologies without detracting from its usability in light of Section 508 accessibility considerations or adopting a lowest-common-denominator approach that would deny the majority of our visitors the benefits of a dynamic GUI.
While we have the in-house talent to make this work, many other organizations don’t, so we would humbly submit that it is time to consider devising an entirely new content authoring and rendering platform with a single unified, but well factored, authoring language. We are posting a more detailed overview of this line of thought on the IEUC’s weblog since it would take far too much space to explain our thinking in the context of a comment posted here.
In any case, we think that the up front pain of biting this bullet and devising an entirely new content authoring & browsing platform would more than pay off for everyone in the long run.
If you agree and would like to help us set up a project like this in the intermediate term, please contact The IEUC.
We are also considering organizing a workshop on New Directions in Web Accessibility to consider web accessibility issues from an End User perspective and to look for some more immediate ways to leverage Javascript, PHP, and Microformats to improve the situation for disabled web surfers.
I’d like to see a CSS engine distributed in much the same way Tamarin has been shared with Mozilla. A layout API that could be plugged into and upgraded at whim into any browser, IE/FF/OP/SF/etc. I understand this is complex thing to do, but it appears to work for plugin based content just fine.
Rounded corners are not correctly implemented neither in Firefox, nor in Safari. Just try to use rounded corners with a background-image on the same element. Totally broken!
And a really basic thing like vertical centering an element is such a nightmare that no one does it! It’s ridicuolous that you have to end up using tables, be it through HTML or thorugh CSS display property. The lack of foresight from CSS standard makers has always appalled me!
The main problem is that W3C standards are not democratically developed. How can an organization decide standard on their own, without hearing what users of that technology think about it? Users of HTML, XML, CSS and the lot are millions of developers around the world. THEY should decide standards, what’s good and what’s not, what’s needed and what’s dispensable, with a clear online democratic process. Not a bunch of academics or self-nominated organizations! It’s impact is not limited to Microsfot, Google, Disney or whatever, but to all of us developers worldwide!!!
The decision model is now totally flawed.
You won’t get anything good from a non-democratic authority.
If the W3C released a recommendation tomorrow of a fantasticly simple and elegant CSS grid module, could you really expect to see this working in IE anytime soon? With no major bugs and following the spec correctly (remember float)?
CSS already has a grid system: display-table from CSS2 (almost ten years old). All major browsers support it with one large exception.
I wholehardedly agree CSS DOM needs an overhaul (I think ppl are working on this), but again, it won’t be in IE, so you’ll get to use 10% of it.
You’d think that being FOSS would make WebKit and Gecko better at allowing web designers to flex their styling muscles. However, even they are crippled in their implementations of CSS3, and are more interested in implementing the “new” HTML features being developed by Apple, Microsoft, Opera, and everyone else. Presto is also caught up in non-CSS matters (even though I would assume Opera to be at the forefront of CSS most of the time…nah, now its all about those WIDGETS BABY!), and Trident is still out of the ballpark.
So let’s put this on the table: As noted by Upanisad, the W3C development of CSS is undemocratic and corporately driven; the development of the layout engines which are supposed to host CSS and other web standards are also undemocratic and corporately driven.
In that case, a new web layout engine, one that has no commercial backing and is made exclusively for today’s and tomorrow’s web designers (NOT web developers) is desperately and sorely needed. A Debian-type web layout system in which the fundamentals of web design - clean, accessible, useful - are put at front and center of any new feature incorporated into the system. Plus, with extensions and extensive documentation available to the public.
Yeah, we need that. We shouldn’t be at the mercy of the companies that much longer.
I think that there are a number of problems that need to be addressed to fix the state of the CSS world:
1) Better Designers — I’ve been working with visual designers for a long time. The ones that are part of our company are great, in part because they interact constantly with a fanatical web developer (me) who challenges them to think in web ways (and I’ve learned a lot of good design principals from them). Most of the outside designers I have to deal with are print designers who have this notion that what works on a sheet of paper also works on a web page.
The comment by Tetburr shows us an example of this:
The reasons for having columns of text in print are numerous. One of which is reading speed. Another is print density (its easier to pack more ads onto a page, which means more money, for example). A third is usability (ride a bus and you’ll realize how many people fold the paper vertically more or less along the column lines). There may be more but these come to mind.
Only one of those applies to the online medium (unless you are designing for e-paper, I guess), although the evidence (I can’t remember where I read this, sorry) is that the rules for optimal column width online is considerably different than in print. Besides, consider the incredible nightmare of reading an article online in,lets say, 3 columns. If its sufficiently long, I have to scroll down to the bottom of the page and scroll back to the top two to three times (depending on how you count). Spanning multiple pages is probably more effective in most cases. The use of columns for rendering text is incredibly limited online, enough so that I would argue that its not worth implementing (except for print style-sheets).
2) Better Layout Semantics — Many people have, already, suggested that we can more easily handle layout using tables. IMO, those people who think this way will not become good web developers until they abandon these ideas. It has nothing to do with semantic zealotry; there are broader issues to be considered. Table layouts require layout order and source order to be the same, however this is rarely beneficial. For instance screen readers necessarily have to read though all that unnecessary verbiage to get to the meaningful content. This is why we invented “skip navigation”, although I’ve watched video of blind testers of our site simply tab a bunch of times, once the page loads, to simply get past the initial (assumed) noise of the page to get to the meat of the page. Search engine indexing too benefits from putting the meaningful content as early in the source as possible. None of this is possible with table layouts. Then we get the issues of needing nested tables in many cases, which just multiplies the paucity of the approach.
What we need is clear semantics for layouts. I would not expand the use of divs for this but rather create a new set of tags and associated CSS properties to handle layout that have explicit default behaviour that gives us a lot of the stability of tables with the layout usefulness that we need.
3) Better Selectors — I’ve long argued (mostly to myself) that the selector syntax that we have is far too limiting. The biggest limitation is the lack of a where clause. I would love to see all of the flexibility of XPath in the CSS selector syntax. Now I’ll admit that I grew to love XPath while working with XSLT (which I think is the superior programming language for converting content to an output format) and that many people would not initially find such a syntax useful. However, those are probably the same sorts of people who typically don’t use descendant selectors. Being able to use complex selectors would simplify so much.
For example, lets say that we have a form in which we have a bunch of radio buttons coded as inputs within labels. Its not unusual to want to highlight the option that you currently have checked (or to use a background image in place of the “real” checkbox). If I could write a selector something like
label[input::checked](which reads a Label element with an checked input descendant) it would be really easy to do. Now I have to resort to writing an onClick event for the radio button to set a class on the label.I can’t bloody stand fixing people’s hacked together table designs. And they’re usually a lot more restrictive, unintuitive and generally boring.
Uh, hello, Safari? Its CSS support is unrivaled (to date). It may need a bit better Javascript support, but that’s another topic for another time. That’s because Gmail is a hack. It’s a really cool hack, but there’s no reason it couldn’t have been done in other ways. Maybe you could elaborate on what exactly you’re expecting? I find it hard to believe that you have such a hard time with CSS layout, and can articulate a self-evidently better approach.That’s not to say that it can’t be improved. But I’m skeptical up to this point.
err… as someone who was building OS emulators in Netscape 4 I really don’t understand the hubbub. Much more interesting and advanced interfaces were being built with the most rudimentary gesture towards css. As soon as you could position and size elements the world changed. I frankly would rather not have a lot of CRUD spread by novices who simply aren’t cut out for building applications. Stick to blogs and templates and photoshop. Please do not destroy the only free (as in freedom) platform for software development by begging corporate crooks (Microsoft, Google, Adobe) to come and solve all your problems for you. I’d rather not have the next 10 years spent filtering through the same people complaining about how (insert whoever becomes the web-based Microsoft here) ’s software isn’t innovative, all looks the same, and doesn’t work.
Lots of interesting comments, but I think Tetburr hit the nail squarely on the head. The web is the new publishing medium. When will it start to act like it? Printing on paper has been around for centuries. Why not learn from what works in that medium?
Rounded corners would be a really nice bit of window dressing, but I would kill for the ability to set up a multi-column layout and have my text automatically flow as it does in Quark or Pagemaker. Kill, I say!
And typography. Why, in the 21st century, is it so freakin’ primitive? Why do we have to limit ourselves to 3 or 4 fonts if we want to make sure it will look good on every browser on every OS? How about the ability to upload a font with the page or to map a font to something similar on the user’s PC or something? Anything!
And something that the programmer in me has longed for: constants. Yes, CSS constants. A very common design principle is to use a theme - a few colors that complement each other and are used throughout the design. So, you set up your theme by defining a few constants and then use them for the colors in your CSS rules. Want to change the theme? Just change the constants - no need to create a whole new stylesheet or go through and change every instance of #305673 to #285630. I’ve actually implemented this on a few sites using PHP, but it’s a major kluge.
Finally, just make it work! Always! Consistently! Stop talking about adding a grid system to CSS. CSS already has a well defined positioning system - it just doesn’t work right. All the browser makers need to get the basics working before they start worrying about implementing rounded corners or their own proprietary bits of fluff.
dshearin is right! Fonts support is definitely needed! Using images to get cool fonts on a page it’s so annoying and limiting!
As far as I know there’s some sort of external font support in current HTML, but it’s totally buggy and makes every browser crash! It’s probably really complicated beacues it involves OS font support, browser rendering engine and even font copyright issues, but it’s definitely a major limit in modern web design!
Even browser developers start do get it. I remeber an official proposal on the matter from an Opera guy a few months ago.
err… appearently CSS3 Web fonts are coming for real in the next version of Opera (9.5), due in a couple of months!!!
http://www.clagnut.com/blog/1980/
So something is moving, eventually!
Had a nice time reading all the comments…… its always nice to hear what the fellow developers think and their ideas and stuff……. but I think CSS is doing fine, the browsers aren’t…… and I am really surprised why people are so afraid of CSS layouts…… at the same time I think it is wise to use tables sometime (although I try to avoid it mostly)…… and please don’t expect it to map your brain for you…… there will always be hacks and workarounds, they are a developer’s enthusiasm of staying ahead of the current technology
I agree that if CSS was implemented consistently it would not be the nightmare it has become.
The thing that I miss most is layout tools comparable to what I get in java, flex or even good old Delphi (border layout, grid layout, flow layout, …). I get that CSS is meant to style single-column documents, and for that it is great, but the reality is that web 2.0 is not built out of single-column documents. I need border and grid layouts that size themselves to the window, and even though CSS can often (but not always) be bent to my needs, it is simply not designed for doing that.
What I really miss is a keyword like ‘extends’ for css classes.
In large projects with different developers, or the layout often change, it’s often not easy to keep the whole overview of layout and style.
Furthermore most Layouts are not really recyclable. Most it’s easier to build the whole Layout new than fix an existent layout.
My wish is a definition like:
.dotted_box { border: 1px dotted; }
.red_box { border: 1px solid #f00; }
.red_box_dotted extends red_box, dotted_box
.topic_box extends red_box_dotted { background-color: #000;}
.
From the qooxdoo we don’t directly need more features here and there. We can do the layout on our own - even if it wouldn’t be necessary when the browsers could deliver something better on their own. But there a definitely a need to fix or start to support following low-level technologies:
Fix the box model again. “border-box” should be made the default. (Everybody who think about this will came up with the imagination that this is the better default)
Values defined in percents should work the way people think (in relation to the parent size which is relevant) e.g. the client box of the parent with the border-box of the child. This should also support gaps defined using margin e.g. box-width: 1000px, column spacing 200, first column = 40%, second column = 60% will result into a first column of 320px and a second column of 480px which means 480px+320px+200px=1000px
Flex dimensions should be made available e.g. define that column A is 200px and column B use the remaining space. Easily do-able with tables.
Support for “text-overflow” CSS property is really needed. Shame on you Mozilla.
Vertical alignments should be supported. Really ugly that this simple feature is missing for block alignments.
Multiple background images should be made available. Also rounded borders would be great. A great feature not mentioned yet would be gradients defined in a simple text form e.g. “red,blue(20,30)” (maybe we can use some declaration style of other vector formats alá SVG here). Background image stretching would also be great e.g. define a background image foo.png and let it stretch from top to bottom (could be used as a replacement for gradients).
Web GUIs need have the possibility to omit text-selection (Opera and IE), omit fancy context menus (Opera), better control the tab-focus flow (e.g. multiple roots), allow multiple active selections (maybe one for each focus root), …
CSS is a nightmare! It takes a very long time to master, and the bugs in browsers causes massive amounts of pain. I find myself repeating mistakes, ie hitting browser bugs, over and over never very sure how I solved it the last time. I blame the spec more so than browser manufacturers for this mess. CSS is so convoluted when it comes to being a layout language that no wonder the browser manufacturers have so many errors. I’m not sure I could get the code right the first 10 times. The one thing CSS got right was separating layout from content, but they threw the baby out with the bathwater by being so against grid based layouts. What was so wrong with table based layouts? They are real easy to understand, use, and implement.
I think alot of people forget that a pure CSS layout doesn’t mean abandoning tables completely. Why do you need CSS grids? That is what tables were designed for, tabular data!
CSS is really not that hard once you understand some of the bugs that exist, mostly in IE. I design CSS layouts everyday and time to design is pretty much the same as if I was using tables. I agree it is not an easy thing to master and understand but once you do it is very powerful.
Are we talking about a problem with CSS or a problem with how browsers implement CSS?
I agree there’s a couple of features like layout, shadow that would be useful in CSS but then again if browsers implement it differently (2 column mode with X z-index causes bug on browser B), it will be another nightmare! Thats where the problem is
CSS not good for layout?
CSS IS layout.
Specifically, document layout. The problem lies not in CSS but in the entire model. HTML was created to allow people to easily markup documents for view over the internet. CSS was created to allow designers more flexibility in laying out their documents.
Designers are against table based layout for multiple reasons, and one of the more major reasons is accessibility. Screen readers have major problems with table based layouts. Table based layouts usually are also larger in terms of download size.
What you guys are mad at is that you didn’t spend the time learning CSS and its quirks that you spent on javascript, and now you’re coming in with your amateur design skills and getting mad because it isn’t working the way you expect it to. The fact of the matter is that if you style your elements correctly, you won’t have any problems when you manipulate it with javascript.
Don’t complain when you create a round hole and then try to fit the square peg that’s been around for years into it. Either find a way around your limitations through education, or find another job.
Give me a break, CSS Standardistas. Tables are structure. If you want tables to be for tabular data only, we will need HTML to be extended to include a grid layout system. Web apps should be formatted like Quark / Pages / Publisher- but we can’t as long as we allow the users to change font size. There’s more to this than the issues with CSS, many as they are.
I’d love to see an easy way to do multi-column lists with headings.
I agree that this is the way to go forward. If this change is ever made I suggest browsers implement zooming (ala iPhone) and allow designers to switch between font-resizing and zooming. That should allow people to view your pages the way you want them too.
Heh, it’s easy for people to go “Tables? Eww, go learn CSS or get out of web development” when in turn, who has yet to go “Go help them fix the browsers/CSS or quit your whining”
And no, CSS is not the table-killer of the web that you’d all like to think of it as. Because when I write a (example) 15 column table, I know how it’s going to appear in every single browser.
CSS - A new browser issue around every corner (ha)
Tables - They work.
I have not read the list of comments, which is getting really large.
Explorer 6 is the real pain; working with Opera and Safari differences with FF in most casses get even funny and don’t forget they have three totally different Engines.
The fear of a “too much quick change” applying CSS3 is a problem but is at the same time the sollution. We’ll always have differences between vendors but good browsers means good programming for developers, simple.
@dshearin, Tetburr, etc.:
Over here at the jQuery-en mailing list we are developing a column-layout plugin, as we also believe it is a simple, yet missing, feature of CSS/HTML layout. Please join our discussion and development on columnize large text … thread.
Also, sIFR is great for headline font replacement. I don’t realistically expect embeddable fonts until someone implements either:
a) a DRM feature to prevent font ripping (which everyone will troll and rip anyway), or
b) an awesome subset of open-source/creative commons/WTFPL -licensed set of internet fonts. Until someone can make a profit model out of one of these goals we will be stuck in our current situation.
Whether or not CSS layout is hard is relative. Frankly, 1000s of designers seem to have accomplished their layouts in pure CSS, so hard/easy is just relative to their skill/talent. No one can tell me that HTML markup can display the same features as fluid, well-designed CSS layouts. As a lifetime layout designer ALL proper layout takes thought and skill, that’s what keeps people like me in business :-).
It seems to me like many of the anti CSS comments here are obviously by people who are completely incompetent using CSS. “ooh it took me 4 hours when it could be done with tables in 20 minutes”? Please!!! You must be a terrible developer!
The people who are writing off CSS in favour of tables really have no idea at all. You’re stuck in a VERY, VERY old way of doing things, and I suggest you pick up your act. I don’t have any problems with CSS at all, and certainly don’t find it more laborius than tables. You are just lazy, and not very good.
The problem is NOT CSS. It is browsers implementations of CSS. (Gee, groundbreaking stuff here). And also, apparently, the competence of web developers out there.
“web authors building apps *will* inject layout elements into their documents”? Please speak for yourself. Some of us are good. Some of these comments look like they’re written by complete amateurs who simply don’t understand the paradigm/benefits of separating content and layout.
“it is impossible to do a true grid without using tables”?? What are you talking about? Yes it is near impossible. Which is appropriate, seeing as you SHOULD use tables for tabular data. That’s what tables are for! Funny that, with the name ‘table’ and all. Table is the correct html element to use for tabular data. No-one ever said otherwise. You obviously need to learn how to use html.
CSS is fantastic, and will be around for a long time to come. If you suck at it, GREAT! That’s more jobs & higher pay for those of us that have a clue :) You stick with your geocities style table based layout garbage :)
In fact, many of these anti-CSS comments seem so clueless that I just decided I’m not even going to continue with this post. Waste of time.
I take a lot of offense to people telling me I haven’t spent the time learning CSS. I have. In fact I spent fair more time learning CSS than javascript as one person said. I spend lots more time debugging CSS than javascript as well. When we refer to layout we mean interface layout not document layout. CSS is relatively ok for document layout. Let me say that’s the only thing it’s good for. Laying out interfaces it is crucially defecient. I still stand by my point that using CSS as an interface layout language is voodoo black magic, and things that are difficult to understand are difficult to implement which means there will be more bugs. CSS doesn’t work for interfaces.
I also think that people who say table layouts are wrong are basically too proud to admit that CSS got layout wrong when it went against tables so vehemently. Grid based layouts are easy to use and easy to understand. Flow based layout, or document layout, is not. It’s pure FUD when people say grid based layout is wrong. That’s just not true. Grids work great for 90% of the problems out there. Graphic Designers have been advocating grid based layouts for a very long time. It’s the predominant form in print design. Don’t believe me read this article on JGoodies: http://www.jgoodies.com/articles/forms.pdf Notice all the graphic design books referencing grid based layouts? One as far back as 1964.
Separating layout from content was a good idea. But, the CSS crowd went horribly off track by dismissing such a useful and simple layout system as the grid.
EoN: We’re not advocating using HTML table tag in our HTML for non-tabular data. For this discussion a grid and a table are two different things. We aren’t using tables to get a grid. We’re suggesting that allowing for definitions of grids outside of the HTML will help when doing interface layout.
Browsers implementations suck because CSS is too complicated! Not because they or we are lazy as you claim. If CSS gave us a grid we could still have separation of content from layout. Separating layout and content is a very good thing. But, are grid based layouts, especially since we’re trying to build interfaces more often than documents.
Charlie,
I blogged about this back in 2005
http://www.redmountainsw.com/wordpress/archives/presentational-xml
I really do not understand how can you set-up a Web 2.0 Ajax interactive interface (with drag and drop and all that) with tables! (This is Ajaxan.com, isn’t it?)
Web is not print. It’s totally different and dynamic. And multi-column layouts (with text flowing from one to the next) is really impractical on the Web. You need to scroll up and down many times to read an article!
Personally, I don’t see grids as a priority or a necessity.
Vertical block align definitely is: you just can’t do it without using tables or display:table (if the box to center is variable in size, or without using hacks)!!
Rounded corners and shadow are cool and spare designers a lot of work: just a couple of rules, instead of using complex DIVs that actually mix-up content with style.
Web fonts are definitely cool. Copyright problems are ridiculous. With a quick Google search you can get any (pirated) font you like in a moment (not to mention EMule). So what?
Official (standard) Javascript commands to get actual CSS property values of an HTML object would be useful. A command to get its exact position in reference to the view port is definitely needed (offsetParent and the likes are not standard and they act crazy sometimes on different browsers, especially with tables and relative/absolute positioning).
EoN, Charles, et al:
The old saw that someone simply “doesn’t understand” or “hasn’t learned” doesn’t help your argument, and is puerile. Ajaxian attracts those of us who are doing web dev. I am involved in taking legacy data apps and putting them on the web for companies who aren’t delivering to the public but for their employees and associates. I understand and use more than a dozen computer programming languages. CSS and HTML are awful. I use them, and I do not use nested tables. If the other languages I used required so many hacks I would certainly be looking for a better language. People who are simply trying to get their jobs done with a table are choosing one hack that requires minimal work over another set of hacks requiring longer fiddle time. The answer is not for us to argue with each other but to encourage a better structural language to replace/extend HTML, and a better formatting language to replace/extend CSS.
@Scott:
CSS and HTML are a pain to work with, which is why we often have to add a layer of JS on top of CSS just to style our pages, and also why many of us are trying to advance the -MLs, to properly present data and separate layout. However, getting something that will work on all web-browsing computers for all people across the world is very difficult as well. Java can do it because a single company has control. However none of this is impossible, just hard!
Are you going to tell me you have total code portability, the range and widespread use of CSS/HTML, in another language? You never have to insert code for different processors, dependencies, etc.? Programming is hard, especially when it works everywhere.
I agree, and I think that’s why JS frameworks with built-in parsers, and extended functions (like providing JS 1.5 spec functions for 1.2) and objects are popping up everywhere. And eventually some of this will find it’s way back into everyone’s browser.
@Charlie:
I design on a grid system, but I use CSS! These are not mutually exclusive. And I use tables for tabular data.
Rather than whining because it’s hard or you don’t know how to do it, find a solution or learn a new skill! Help advance the language!
@Chui:
Layout (width) does not belong in data markup, and tables are not the future. It’s an effort, at least.
Charles:
You’re still making an accusation that these folks “don’t know how”. I believe this is not always the case. And you’re still being childish, calling Charlie a “whiner”. Do you really think you’re helping your position, or that of CSS advocates? Also, you are not addressing the argument, instead substituting your own points. But to answer one of yours, yes, I do have a language that runs on most machines/OSes, though I rarely use it. It’s called REALBasic. You have at least acknowledged that HTML with CSS is hackish, and now you’re adding JS to the mix. I do hope you actually see how bad the situation is. If you are truly wanting to help others, post your method for grids or refer them to a book from which you learned your method.
Others:
Do have a look at Dan Cederholm’s “Bulletproof Web Design”. It will help you understand what the CSS advocates are on about. As you probably have guessed, it doesn’t solve every problem. That will require another go at the issues, which most of us have been advocating.
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:
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.
“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..
@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?
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.
I enjoy reading these comments but I think a lot of folks here do not seem to understand what CSS is for. The purpose, and it’s a good one, is to abstract the content from the presentation. CSS is not perfect by any means, but it is a huge step forward from cramming presentation and content into one file. From bandwidth reduction, accessibility improvements, ability to easily (yes it is easy) share content across viewing devices CSS is a good thing. Complaining about poor browser implementation is good, but it takes a long time for the complaints to get listened to and fixed by the browser vendors.
Complaints about having to hack with CSS to get the display correct remind me of the wonderful days back in ‘96 when we had to learn to suffer through single pixel gifs to hack with tables for proper display. Browser vendors, for whatever reason, like to be different and it sucks for us as developers and designers. And it has always sucked for us, but this is part of what we get paid for.
Share suggestions to improve CSS, but suggestions to throw it out altogether are, well, lunacy. Sorry, but it is not broken it is more like an awkward teenager.
One last post on this topic:
Charlie, speaking of Molly, have a look at this and see if that doesn’t sound like some people here. Look at this, too.
Let’s be clear: using a table for other than tabular data is a hack. But look at vertically aligning a CSS float and you’ll find some pretty awful hacks there too. In that situation I use a table.
CSS is not an awkward teenager, Anthony, but in the same way it is not ‘broken’. It simply is a poor tool in the first place. I would be all for throwing CSS out- but HTML, too, if there were a better tool. No, at this time, there isn’t one- but we should be asking for them. The print/document paradigm works well if you’re doing static pages. A better grid/box/object model is needed by those of us who are doing web apps.
some work draft css3 prop for layout
#element selector{
display: “abcd”, “card”, “tab”
}
http://www.w3.org/TR/2007/WD-css3-layout-20070809/
> “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.
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.