Calling for a new CSS revolution
By glazou on Tuesday 14 December 2004, 14:35 - Standards - Permalink
Seriously, I think the time has come for us to look at what we've done, where we are, and what remains on the TODO list. I think we made a number of mistakes regarding CSS that are annoying today, and it's highly time to list them publicly, and apologize. I can say we because I have been a member of the CSS Working Group since 1997 (or was it 1996, I don't remember), participated into CSS 2, am the editor of a few CSS 3 modules. As an official member of the CSS WG on behalf of Electricité de France first, and Netscape/AOL later, I accepted new directions or proposals for the future of CSS that seem to me historical errors today. Before saying "Daniel plays it again", please read the whole message .
- the biggest mistake we made is 6.5 years old. Back in june 1998, we should have moved CSS from levels to versions. Levels, and the backwards compatibility they imply, are now a real threat for the future of CSS, somehow blocking innovation. Furthermore, it's extremely hard to validate a CSS instance because no level information is, of course, included in CSS style sheets. It would have been incredibly simple and easy to preserve CSS 2 as a level, and make forthcoming specs become versions of the level 2 of CSS. One very visible effect of levels is when the CSS WG wants/needs to change the set of values of a property to add one, and then turns a property into a shorthand by some kind of magic trick. CSS levels are a dogma, and that dogma becomes a burden. Versions would have allowed us to move faster, releasing for instance minor versions every six months.
- in my mind, CSS 2.1 was another big mistake. Oh, don't misunderstand me, it's not a mistake because it is bad. Not at all. It's even a very good spec... But it has been sucking all resources from the CSS WG for more than four years. Instead of focusing all our energy on the future, we kept our eyes on the past. I am sorry, and I know some proeminent voices disagree with me, but I can't help but finding it useless: the CSS 2.1 will not change at all the Web landscape around us. It is not "leading the web to its full potential". I do believe we are late on CSS 3 because we spent hundreds of hours, dozens of teleconferences, and sometimes face-to-face meetings from A to Z, on CSS 2.1. Extracting from implementations the highest common denominator was a good idea, but using it to make CSS 3 instead of CSS 2.1 was even a better one. Instead of that, the CSS WG edited - and still edits - a document that contains changes that are not yet in the corresponding CSS 3 modules, and a document that CSS 3 should really obsolete as soon as it is released... If back in 1998 I did not see the need for versions in CSS (mea maxima culpa), I have always expressed the same opinion about CSS 2.1.
- we start acting like the HTML WG. I mean we have a loooooot of modules/documents on the table, some of them being incredibly complex, and we spend considerable time releasing them. More and more observers wonder where we are and what we are doing. We are Constitutionalists, wanting a perfect model usable in all-possible-cases-of-the-world, discussing the impact of the position of a comma for hours, and rejecting simple, sometimes trivial, solutions when they work for "only" 95% of the World Wide Web. That could be understood as a plea for KISS but it's not only that. It's also a plea for pragmatism, that we seem to have completely put aside. The 1st of December, during the celebration for the 10th anniversary of the W3C, the acronyms XHTML and CSS were not pronounced or shown a single time in the day. I guess it's unfortunately a good indicator of the situation. The number of possible interactions between properties and property values in the CSS spec makes it impossible to test completely. I mean that the number of tests needed to make sure interoperability is reached is so high we'll never reach real interoperability. Knowing that, and giving the fact CSS 2.1's unique goal was to build an interoperable ground based on existing implementations, I am sure we followed a partly wrong path here. We also lost momentum because we have too many documents, discuss too complex issues relying only on one person's knowledge. Because more than six years after CSS 2, our group's charter is still the same.
So I do apologize for the above. Seriously. I was unable to have an outsider's eye on the question until I moved from a Group's full member status to an Invited Expert joins-when-he-can-and-he-cannot-often status. I was also unable to impact strongly enough the decisions taken in the Group, but, hey, that's life, and I am only a frog, and it's hard to fight face-to-face some rhetorics Masters when you're not a native english speaker.
So what do Web authors need today more than ever ? What is the list of features/extensions/whatever the Group could keep its eyes on to make things go faster, MUCH faster, and DELIVER ?
- authors need a new version of CSS
- they need functional notations allowing to position an element at "21% minus 11 pixels" of the width of another one... That's just impossible to do right now and that's certainly the top request.
- they need inline-blocks
- they need to position and size elements relatively to other elements, for instance "I want this text column to have the height of that other text column", without having to insert enclosing elements above them.
- they need columns
- they need to vertically center blocks without a hack
- they need a flexing box model like XUL's
- they need to scale image backgrounds and need to apply filters to images
- they need to be sure they can print a document preserving its readability, its usability and its original spirit
- they need to be able to define constants à la #define. The Cascade does help a bit, but only a bit. It solves only a very small minority of the cases where such constants are needed.
- they need better internationalization, but that does not mean we need to solve RIGHT NOW all the cases of the world, even the ones that we know are going to take years to solve correctly.
- they need scoped stylesheets, and a part of CSS 3 Selectors.
With these twelve points, we could so drastically change presentation on the Web that it would improve user's experience by a few orders of magnitude. The list above contains stuff that is already present in some CSS 3 modules or is even already implemented in some user agents beginning with F and ending with x. From my perspective, the rest of our current work, and in particular 2.1, can hibernate.

Comments
Looks like you guys are in dire need of implementing agile processes.
www.controlchaos.com/abou...
L
IMHO you should revisit that post you made a few weeks ago which turned into a CSS gripe thread.
You hit many of the points... but I think you left out something: simplicity.
Remember, in a corporation, most (especially non-tech) companies use designers to create html for websites, not developers. Developers do the backend. These people aren't as geeky. They can't stand CSS for it's complexity. Tables were an easy instant-gratification, so they were good. Very logical and easy to follow.
IMHO until the CSS WG realizes that their audience is not geeks, but design people, CSS is doomed like CSS2.
IMHO think more about templating languages as a "layout language", and leave CSS 1,2,3 as style language. That I think is the real answer. A simple way to do template to create layout. Perhaps resurect the table method of layout, but with the abstraction that CSS provided with 1 shared copy, rather than having it all nested.
Think about the audience. IMHO that was the #1 failure before, and it's what will decide this time around.
I do not always agree with the Glazou's views, but gosh, those 12 points sound right !
Keep in mind that with CSS2.1, you can do things like "display: table" to give table-like layouts to pages. However, IE doesn't support it. I think much of the problem with CSS is that IE doesn't support so much of CSS2(.1) that people don't make use of much of the really useful things you can do with it. Hell, you can achieve an awful lot with the right use of the more powerful selectors.
Having said all that, I do mostly agree with Daniel's comments.
> 1. authors need a new version of CSS
A majority of websites still heavily rely on table design, nested tables, insane amounts of <img src="spacer.gif" ...>, <br>, , <font>, and typical poor coding practices and typical ways of relying on MSIE's loose error corrections. Authors don't need a new version of CSS right now; they need to understand CSS, then implement CSS1 and to separate structure from presentational considerations.
> 2. they need functional notations allowing to position an element at
> "21% minus 11 pixels" of the width of another one... That's just
> impossible to do right now and that's certainly the top request.
#PositionedElement {margin-left: -11px; width: 21%;}
works for me.
> 3. they need inline-blocks
That's already in CSS2.1. www.w3.org/TR/CSS21/visur...
> 4. they need to position and size elements relatively to other
> elements, for instance "I want this text column to have the height of > that other text column", without having to insert enclosing elements
> above them.
This can be done with javascript. It can be done otherwise.
> 5. they need columns
It's in CSS3 and already supported by Mozilla (bug 251162).
> 6. they need to vertically center blocks without a hack
I never understood that one in web programming newsgroups. Why do you want to vertically center blocks in the viewport?
> 8. they need to scale image backgrounds and need to apply filters to
> images
Some of them are available, accessible already via CSS 2. Most IE filters are just cosmetic and abusing users' system resources.
> 9. they need to be sure they can print a document preserving its
> readability, its usability and its original spirit
Most documents today which do not allow printing in such way are very poorly written.
I'm sorry. Overall, I don't agree with your diagnostic of the current state of the web. Authors and amateur authors need editing softwares which will output/produce valid HTML 4.01 markup code and which will assist the user into producing valid and smart CSS code.
>Authors don't need a new version of CSS right now; they need to understand CSS...
Why waste time understanding something that is broken and/or difficult to use?
Believe me, I as a developer appreciate simplicity myself. I had once created an extremely complex UI which had all the bells and whistles, and which was so rigidly defined that it was ridiculous... when you consider that a simple textarea could do everything I wanted.
>This can be done with javascript. It can be done otherwise.
That's not the point. Doing things with JS should not be necessary to CSS. Otherwise, why have CSS at all, except as a shorthand for JS?
I personally suspect M. Glazman's comments here will not be well-received by the powers-that-be. So let's think for a moment.
CSS isn't adequate to the task. Call me crazy, but would it be wise to consider designing a new language to handle the styling? I know this smacks of proprietary code, but working openly with WHATWG might help.
Sometimes the tools we have to work with are so hard to improve on that we have to start over. That's what happened to the Netscape 4 code within the Mozilla codebase several years ago... and now we have Gecko.
The real question is why the WG failed to deliver these features to begin with?
"#PositionedElement {margin-left: -11px; width: 21%;} works for me."
True, that is one way to go about doing it, but it's still a hack that you had to learn. You should just be able to use standard math for the position.
amen brother
"#PositionedElement {margin-left: -11px; width: 21%;} works for me."
No!!!! That way, you can't set a margin by yourself!
"I never understood that one in web programming newsgroups. Why do you want to vertically center blocks in the viewport?"
Guess what: because one may want to vertically center blocks, that is just why. Design and ergonomics matter.
Another similar question could be: "why do you want to display your picture in the upper-right corner?".
> Why waste time understanding something that is broken and/or difficult
> to use?
I agree. E.g.: Why waste time creating DHTML menus when implementing site navigation bar based on HTML 2 <link> element in browsers would work/would have worked for all of us without javascript, without semi-complex css (or worse: IE proprietary behaviors), with very little time spent on coding. Please acknowledge that a lot of web sites on the web have/use DHTML menus and many of them are inaccessible, won't interoperate, won't work with js disabled... and I'm not even talking about CSS support here.
I'd say 98% of all web authors out there who are using CSS in their web pages never read both documents
Writing efficient CSS
www.mozilla.org/xpfe/good...
and
Tips for style sheet perfection
www.richinstyle.com/maste...
>That's not the point. Doing things with JS should not be necessary to CSS
The point I was trying to make is that it can be done in different ways without a CSS revolution. Relative positioning and relative sizing usually works with CSS without a problem.
I still think we're far from the need for a CSS revolution. In 2002, W3C estimated that 99% of all webpages out there would fail a markup validation.
["Most of the Web sites on the Web are not valid. We may assume that this is the case for 99% of the Web pages"
www.w3.org/QA/2002/04/Web...
]
I'll tell you that 99% of all webpages out there rely on IE's internal error correction handling, rely on copied code from dynamicdrive.com or typical javascript copy-N-paste code which are full of poor/wrong/invalid coding practices, with insane amounts of document.write() calls, setTimeout(str, 1), setInterval, innerHTML, id_attribute_value.style.property_name=property_value, document.all, etc,etc,et... Most people don't learn how to write reasonably well web pages: they copy from other sites what they see and "learn" from what "works" on the web, mainly with MSIE 6 for windows and thanks to its loose, faulty error correction mechanisms.
"The whole reason nearly all Web pages on the Internet are malformed is because browsers let Web page authors get away with it. As long as browsers are permissive in their error handling and recovery, Web authors will continue to produce invalid Web pages, because they won't even have any idea the pages they are authoring are invalid! (...) If we lived in a world where browsers could refuse to display malformed content (with useful error notification of course so that authors could easily repair their content), then all of these [layout] 'bugs' would simply disappear. (...) I think people who don't work on Web browsers for a living have no concept of just how malformed the Web really is"
D. Hyatt, january 2004
weblogs.mozillazine.org/h...
"A user agent acts on behalf of the user and therefore is expected to help the user understand the nature of errors, and possibly overcome them. User agents that correct errors without the consent of the user are not acting on the user's behalf.
(...)
Silent recovery from error is harmful."
www.w3.org/TR/2003/WD-web...
GT
P.S.: when I took over bug 74952 8 months, the mozilla.org document "Using web standards in your web pages" which was 3 years old or so had 261 markup errors according to W3C validator, many CSS errors and many poor web design techniques.
Well, I would certainly like to have a XBL(-like) language. I think that could solve a lot of design/semantic issues of today.
Unfortunately, it was decided that SVG needs XBL more than HTML
I've been a programmer since 1965, and did considerable web development in the mid-90s, just before CSS. I haven't been doing much since then, and only really started to work with CSS during the last month.
So let me say that, coming from /my/ perspective, such as it is, I agree that CSS (beyond CSS1) is in a mess.
Here are some things that I cannot find a way to do:
1. Line up verse drama with speech prefixes in what is, other than the prefixes, the left margin. See pws.prserv.net/jwkennedy/...
for an example of how I've hacked it by (what else?) tables.
2. Line up part of a line at the right margin. See pws.prserv.net/jwkennedy/... where I haven't been able to do it at all. Find "sue to be" and look at the "[Aside". That part of the line, and that part alone, should be right-justified. The best I can do is pad it out with .
(3. Of course, one thing that verse drama desperately needs is a "tab to one em beyond the end of a designated previous line" function, but I don't even know of a word processor that can do that.)
13. A native and accessible way to replace text by image
(not a hack necessiting extra span, extra css rules, extra js and extra brain)
Please!
>they need to be able to define constants à la #define.
Heh. This was actually in one of the early drafts for the CSS1 specificatipon, but was, for some reason dropped.
John W Kennedy:
For number 2, you seem to want compact boxes. See www.w3.org/TR/CSS2/visure...
They're implemented by Opera 7 and Safari 1.2, I believe.
Perhaps display:compact would do the trick, but it doesn't work with Firefox, IE, or, for that matter, Amaya.
My particular problems aren't the subject at hand, of course. But it's discouraging that after so many years, it's still almost impossible with CSS to reproduce quite ordinary effects of California-box typesetting of straightforward English literature.
And I've noticed on Bugzilla that several CSS problems in Gecko are currently in status: "We won't fix this until W3C explain what they mean."
So, basically I'm saying, "Yes! Yes! Yes! Yes!" to DG's original manifesto. This logjam has got to be dynamited.
Years ago I asked comp.infosystems.www.authoring.stylesheets about resizing text; I wanted to set bounds on how small and large a font could be so that no matter what the webpage tried to accomplish, no character would ever grow or shrink beyond a certain size. As long as the suggested font size was within this range, I was content to leave it alone and obey the webpage's suggestion. I used multiple web browsers, so I wanted the font size customization to be portable across browsers. User CSS looked like an ideal place to do this. I needed this because I was frequently coming across webpages I could not read. A fundamental reason for using the web at all was completely lost on me.
The most substantive reaction I received was also strongly indicative that CSS was and is really screwed up. In groups-beta.google.com/gr... Eric Meyer told me that, theoretically, one could extend the font-size: property to specify a range (like "font-size: (9pt, 12pt, 15pt);") so one could specify the minimum, optimal, and maximum font sizes. This kind of specification, if followed, would have solved my problem and been backward-compatible. Earlier CSS parsers wouldn't recognize the syntax, so they would ignore the entire rule (a proper implementation of the cascade would make this so). Combine this with "!important" and place it in a user stylesheet, and voila, one has the ability to portably set limits on font size so that one can read what is being displayed.
Of course, there are plenty of other ways to screw this through text placement, but it would go a long ways to solving my problem.
This course of action wasn't even recommended--it didn't even pass muster at the discussion stage--because proper implementations didn't exist in the past (what about Netscape 4.x? What about MSIE?) and these buggy programs might screw up royally when seeing this new syntax. In other words, implementors inability to properly implement the cascade back then are being used as an excuse to not implement advances that would be genuinely useful today.
I hope if there is a means of reassessing something in CSS that old mistakes implementing backwards-compatible features like the cascade won't hold future spec authors from specifying socially useful features like allowing users to set down hard limits to make things legible for their eyes.
Daniel, if in point 12 you include the "i want to apply this rule to all elements that *contain* such or such elements", i'm all with you. That's the most annoying thing, i think, in current CSS selectors.
I fully agree with all your 12 features (though, especially 2-8 and 10).
Gerard: The problem is the amount of time an average, standards-abiding designer wastes/spends trying to get the look they want.
Robert: I don't understand your suggestion. Is it something like this:
layout.xtl:
<layout>
<row><col id="sidebar" /><col id="main" /></row>
<row id="footer" />
</layout>
and in doc.html:
<col id="sidebar">menu item #1</col>
<col id="main">lorem ipsum blah</col>
<row id="footer">copyright . . .</row>
From an authoring POV, that seems fine (although I don't like having to use separate files for layout and style). But I'm not sure how good it is from the semantic and DOM flexibility POV. I haven't given it much thought, so maybe it's fine . . .
Ultimately, I'd like to have decent CSS layout abilities first and soon. Keep the changes simple for now (to within a single language). Template files can come after.
I certainly don't always agree with you, but here I'm like xave and many others: those 12 key points yield a thumbs-up here!
"Tables were an easy instant-gratification, so they were good."
What? I remember pretty well, back in the time, wasting hours, if not days, trying to understand why some tables would appear correctly in Netscape but not in IE, or the contrary. Tables were anything but an instant gratification. People started to use them as hell when products such as Macromedia Fireworks emerged and automatically spitted out tons of TABLE code and transparent GIFs that happened to work the same way in the majority of browsers. Likewise, the vast majority of people will start using CSS without knowing it and regardless of its complexity, only when good software that does it behind the scenes will be available.
I don't find that you can compare CSS and TABLE designs on the basis of code complexity. It's more a mindset/habits change issue. Personally, I find CSS design much more logical, easier to read and code than those 90% TABLE-fat pages. It's also way more powerful, and some people confound that with "complex".
Just thinking about one thing : CSS couldn't and can't be a revolution. There wasn't any big new idea in web design since the end of the 90s. The market actors since then just evolve with few steps, had to capitalize and become a real industry. Web sites layouts themselves arent't so different now that they were a few years ago. Yes CSS made its way in the industry, but just for technical reasons : easier to maintain, more interoperability. This wasn't a revolution, this was "just" an evolution - and in the enterprise side, not the user one.
I think the web industry just always waits for standards to build real web base applications. "Always" because this needs is here since at least the mid 90s, and nothing is really coming since then. They won't make a big move to a new layout technology that win't make an immediate profit to their business, since some of them allready made a lots of efforts to adopt CSS 2 in a relative difficult period (end of the golden web era). they just need now more clients, more services, more efficient web sites. This won't be done via layout.
I think the main mistake was to make CSS markup independent.
Actually, using CSS properties, you can perfectly style a document made only of <p> markup, for instance, with no regard to the document structure (which people usually don't care about : all they want is proper display).
It makes it quite difficult i think (or maybe impossible) to design an HTML+CSS editor.
UI editors are inspector based : select a widget and its display attributes appear in an inspector.
In a classic HTML editor : select an element and the inspector displays the attributes.
But with CSS, it is just useless : select any element, and all the CSS properties are available.
All the display: xxx stuff is quite impossible to understand to non guru people and it prevents you from building an editor a la XPress where you position blocks then text into the blocks.
Totally dissociating markup and presentation is probably a noble idea but it just make things terribly complex to understand to designers.
Right now, for instance, what most designers managed to understand is : a block is a <div>. It they need to position a block of something, they wrap things up into a <div>. But notions like : a <p> is also a block or, worse, you can turn a <a> into a block by using "display: block" is just totally confusing.
> The real question is why the WG failed to deliver these features to begin with?
Because it's a whole lot harder to produce an interoperable specifcation that meets a bunch of needs than it is to come up with a list of needs in the first place.
> Levels, and the backwards compatibility they imply, are now a real threat for the future of CSS, somehow blocking innovation
So given a non-backwards compatible CSS with releases every 6 months, how would authors deal with backwards compatibility problems? Or would we be in a situation where each page would only work in one particular browser version according to the version of CSS it supported? The web is a set of interlinked pages. Because all the pages are interlinked, it is a natural and reasonable assumption that a single client will read them all. Breaking backwards compatibility would prevent that or prevent pages using the new features. Even with a spec that allowed for graceful degredation of new features we're already stuck in a CSS 1.5 world where authors only use features that IE supports. Releasing specifcations faster than they could possibly be implemented wouldn't help anyone at all.
> 1. authors need a new version of CSS
Like they need plauge. Well that's not quite fair. But CSS is currenlty browser-limited not spec limited (note all the features that aren't used because they aren't supported).
> 2. they need functional notations allowing to position an element at "21% minus 11 pixels" of the width of another one... That's just impossible to do right now and that's certainly the top request.
That would be nice. In the spirit of backwards compatibility, I suggest preserving the existing "API" (i.e. left, top etc.) and adding a new version (multi-left, multi-top, etc. or something) which take complex values and override any values in the old "API". Then there would be a proper way of allowing backwards compatibility whilst providing new features.
> 3. they need inline-blocks
Impelmentation issue.
> 4. they need to position and size elements relatively to other elements, for instance "I want this text column to have the height of that other text column", without having to insert enclosing elements above them.
Well come up with a good spec that won't lead to a) horrible performance or b) infinite loops amnd introduce it in such a way that backwards compatibility is maintained.
> 5. they need columns
Implementation issue.
> 6. they need to vertically center blocks without a hack
If the hack works, it's doing much better than most of CSS 2/3 which aren't implemented by the majority (by useage) of UAs.
> 7. they need a flexing box model like XUL's
That's been proposed.
> 8. they need to scale image backgrounds and need to apply filters to images
Why do they need client-side filters?
> 9. they need to be sure they can print a document preserving its readability, its usability and its original spirit
Print style sheets? This sounds like a UA issue (ability to specify no stylesheet when printing or ability to specify a user print stylesheet to remove background images, etc.)
> 10. they need to be able to define constants à la #define. The Cascade does help a bit, but only a bit. It solves only a very small minority of the cases where such constants are needed.
That would be hard to do in a backwards compatible way. I'm sure it would be trivial for a well defined editor to fake this feature though. Even someone using notepad could easilly use a preprocessor to achieve the same effect.
11. they need better internationalization, but that does not mean we need to solve RIGHT NOW all the cases of the world, even the ones that we know are going to take years to solve correctly.
OK.
12. they need scoped stylesheets, and a part of CSS 3 Selectors.
An implementation issue.
So roughly half of your requirements are issues with specific implementations. And, if we're talking about implementation issues, I think that authors will settle for simple things like proper support for positioning in IE. In fact, your "order of magnitude improvement in user experience" can /only/ occur in one of two situations: 1) IE becomes a minority browser 2) IE gets a significant update to its CSS support. Untill either of those things occurs all CSS development is essentially irrelevant (and because of this CSS 2.1 is useful since IE developers would, presumably, target CSS 2.1 if they were looking to update their standards support).
Not only for those reasons. The CSS Working Group is also made of people having completely different interests. Let me give you an example : Opera for instance resists strongly to a lot of additions to CSS that could imply a size increase of their layout engine for mobile devices. That's pretty normal, given their business. So for them, levels do make sense because they certainly don't want to deal with multiple versions of CSS. In that sense, community is somehow blocked by one only.
You miss the most important point: make it simpler to use (by web designers and anybody else).
Before any other enhancement, people need a simple way to design an unbreakable and/or elastic page layout. Currently, CSS claim separation of semantic and presentation. But in fact they are not. Presentation is still linked to content. This is the main CSS pitfall: Rules rely on content flow. The only alternative is the absolute position but this one is impracticable in most situations.
To achieve it’s main goal, CSS must provide a real separation between content and presentation without requiring to use XSL or to break semantic with doubtful artefacts.
This can be achieved very easily if presentation layout did not rely on content nodes but on a separate concept like cells. Then web designers will be able to keep a firm control on the design and distribute content across theses cells using traditional CSS selectors.
For example:
XML:
<body>
<h1>Today news</h1>
<div class=”article”>
<h2>Users complain about CSS</h2>
<p>CSS is not so easy to use…</p>
<p>bla bla bla…<p>
<ul id=”related”>
<li><a href= “glazman.org” >Comment about Calling for a new CSS revolutions</a></li>
<ul>
</div>
<div class=”article”>
…
</div>
Enhanced CSS (abstract):
/*
setup cells
- $ is used to select cells by name
- after split, implicit cells size is “auto”
*/
body { split-horizontal: header articles footer; }
$header { height: 100px; background: url(header.png); }
$content { split-vertical: article related; }
$related { width: 200px; }
$footer {height: 50px; background: url(footer.png); }
/* move content to destination cells */
body h1 { in: header; }
.article { in: articles; }
.related { in:related; }
This example shows that only few additions are required:
- a way to create cells ( “split-horizontal”, “split-vertical” in the example)
- a new property to tell were content should be rendered (“in” in the example)
- a cell selector to address cells (“$” for example)
Advantages of such approach:
- Compatibility with existing syntax
- Compatibility with existing browsers. The layout and all background decorations are maid using cells so old browsers will ignore them. They will display content in normal flow but with correct text styles and so on.
- Easy to handle by WYSWYG tools
- Easy to understand and control (this is the most important).
CSS needs two things:
1. Maths. How great it would be to do example 2 in your list ('position an element at "21% minus 11 pixels"') or something similar. Might help to make layouts that fit a variety of resolutions. (Or is media queries (CSS3) enough?)
2. Variables. I long to set a variable at the top of my stylesheet to define a colour used on several elements later on. Then to change the colours, all I do is alter the variable - not wade through lines of code to find each occurence (or use a text editor's Find/Replace function).
You can probably parse a stylesheet first on the server to do this (or use styles in the head of the document and process this first) but that is messy.
Yes I know combining the two would make CSS a *programming* language, rather than a style (markup) language, but it would be very useful. So long as you don't go down the route of implementing functions that make it the same as JavaScript or PHP!
Now imagine you had ten colours styling each item on a list. Each was related to another, so you could make a gradual colour change, say from bright red to dark red. A variable would be used to define the first colour, and each further list item would be subtracted from that to give a progressively darker colour. Then you could do something like "add 10% more green" to the first variable and this would affect each list item, retaining the gradual colour effect.
"They need to be sure they can print a document preserving its readability, its usability and its original spirit."
PDF?
The more I think about it, the more I think a whole new method would be great - perhaps a completely new language similar to a mix of HTML and CSS. Why are simple things like columns and centred blocks so hard to do easily? These should be the easiest things to do - not the hardest. (Or is it that getting them to work cross-browser is the problem?)
What's interesting is how PDF and Flash are becoming more and more web-enabled. PDFs can already contain web links, mp3s and JavaScript. Flash does XML, audio and video content, and works well with images. Both allow for a vast range of fonts to be used. (It really sucks to just use only a few fonts in HTML. A pity embedded fonts didn't take off.) What we need is a program like Flash or PDF, but where columns can simply be moved into place and no code is ever seen. (Dreamweaver perhaps is the closest to this goal, but still relies on traditional code like HTML because that's essential right now.) Some kind of visual language would be used, that still allowed enough complexity to make detailed layouts. I mean you can do some amazing things with Microsoft Word using lines, shapes, text-boxes and gradients. (Just don't output it as HTML...)
> PDFs can already contain web links, mp3s and JavaScript.
Ther're also almost impossible to read on-screen. Most other document formats have the luxury of assuming a fixed media size (e.g. A4 paper). Web browsers are expected to intelligiently resize the document to the dimensions of the viewport, which can range from a tiny mobile phone scren to a vast widescreen cinema display and then resize again when the viewport size changes after the document is rendered. They're expected to deal with users resizing the text and other elements on the page. That's entirely reasonable; it makes onscreen readability as good as it can be given the limitations of current displays. On top of that, web browsers are expected to work in a performant manner over slow connections. This means that it should be possible to incrementally render the document without receiving the whole file. That's not a considration for other document formats like PDF.
Before dismissing HTML/CSS as a faliure because they can't provide all the graphical flair of traditional DTP programs/formats at least understand that they're trying to solve a fundamentally different and *harder* problem.
"I'd say 98% of all web authors out there who are using CSS in their web pages never read both documents
Writing efficient CSS
www.mozilla.org/xpfe/good...
and
Tips for style sheet perfection
www.richinstyle.com/maste..."
Especially as they contradict each other....
DG: "Separate layout from style, position and sizing relative to other elements, scoping, macros" - I've always wondered why such "obvious" things were left out/not thought of. They would make things so simpler and WYSIWYG page design tools (thinking of NVu
so much more effective in creating flexible layout.
"A new version" - why? Forgive my naivete but if these much nededed things don't go into CSS3, where should they? Most of it is working draft so there should still be time... But certainly yes for "version identification" and consequent validation options as stated in the first point 1.
Still, my concern is the lack of MSIE support may break it down; if we can't use proper 2.1 now what is the chance of this "CSS-NG" in forseeable future?
Should be a solution implementing some basic javascript intructions into style properties like the IE proprietary 'expression' ?
Hi, I red twelve of your points and agree with very most of them (I don't understand some of them, but I believe, that webdesigners need them to sleeping with girls /or boys if they're interested/ instead of CSS nitemares). You can release music album - my favourite one is the 6th track, this is evergreen of CSS.
I wholeheartedly agree with the genera notion of this blog post.
Just to add to some details:
6. We do not actually need to vertically center things. We in fact also needs to be able to easily size things in comparision to the viewport. It might not be necessary for document-centric pages (something, which all of the W3C seems to concentrate on), but is very important on pages which basically are a UI for web applications.
And some additions:
13. We need min-height, max-height, min-width and max-width as soon as possible
14. Font handling is basically a mess. We need a max-font-size and min-font-size setting, to somewhat improve this. Other nice things would be if we could _redefine_ what the different fontsize keywords mean, and if we could specify different fontsizes depending on which font face of a certain list was actually used (because, as everyone knows, different fonts of the same height can look quite differently large).
I agree, Daniel. While the CSS stagnation is unfortunate, it has given many CSS authors time to understand it. However, most people producing CSS now a) don't see the need to fully understand it, b) let it be written wrongly or inefficiently for them (Dreamweaver is a crutch), c) begin by learning a broken box model (IE), d) use CSS like paint on a canvas, as opposed to ornaments on a tree, and/or e) don't understand (X)HTML in the first place, which really is a prerequisite. In my view and experience, CSS is simple: the implementations make it tricky. At some point, the web needs to bite the bullet and abandon forgiving mechanisms (a la "quirks mode") to force content to be compliant.
the problem is that in old days anyone could write a webpage to express some thought. That is why the web was seen as a revolutionary medium and not a pathetic medium like TV. the problem is that all those specs made it fisible only for professionals to put up a web site.
All your efforts suck. sorry to say that but people loved the simplicity of HTML.
ps. and sorry for my bad english. not native speaker
I've been using CSS for some time now (not really an expert on it, though)
but I think the greatest problem CSS has, is the support by the large browsers, Firefox seems to do it quite well, but if you look at IE; that browser makes a mess out of it (for the most part at least).
So another version of css won't help a bit, unless you get the major (if not all) browser-parties to support it.
Until that happens, every new version/level of CSS is doomed to fail.
nice blog, though I am excited now to use all CSS layout instead of making table structed layout...
kashyap
Odd that people are so entirely against a new version of CSS. I agree that the last thing we need is to stagnate on CSS 2 and 2.1. Who cares if 90-whatever percent of authors don't use CSS2? Those of us who do need a better technology to work with. Those who don't probably aren't CSS2 compliant because it sucks where they need it to work (folks ask you how to get a footer beneath their absolutely positioned columns and you have to cough and tell them to start over). And maybe if there really is one new standard that works well browsers won't hack it apart (or will do so with less fervor) before implementing it.
I agree with the twelve points, if with some reordering.
Hello. Thought I would check out what was new. I am doing a research for my new webpage. How are you liking the new community. I was looking for some one and I found some looks good.