Comments for CSS 3: A Giant Serving Of FAIL
-Vince
@define is an element I have longed for since the very early days of CSS. And @importRule could also be expressed:
.one { /* design / } .two with .one { / design */ }
(or replace "with"... with "from", "extends", "includes")
That would fit more into the basic setup of CSS in general (ie, wouldn't break the decade of learned CSS behavior). And would make relating it a little easier for OO programmers. Also, it would be a lot better than expressing multiple classes and ids inline (which is pretty dumb, if you ask me).
I know there are people who will vehemently claim up and down that HTML/CSS aren't programming languages, suitable for stupid people and monkies. And they are right, in the barest technical sense. However, when it takes the the learned thinking process of (other) programming languages to do anything relatively decent with HTML/CSS you can't say they really aren't programming languages by saying they are not dynamic. Punch card programs weren't dynamic either.
Inheritance and Variable replacement is nice too, but can easily be solved by using some preprocessing tool (xslt, if nothing else).
CSS so far was EASY and simple to use, these new intros with that vars just make things more and more complex with only little gain.
Sorry, not convinced about this!
Would it be advantageous to push these types of changes to CSS into open source browsers, with the possibility that the closed source browsers may follow? ... maybe I'm just too optimistic, and at least mildly naive.
.highlight { color: red; text-decoration: underline; }
.updated { background-color: yellow; }
This would achieve the same effect as your @importRule '.highlight';
The composite classes are very much possible, just not within definition but in the actual HTML. Your example of 'updatedByOthers' in current implementation would look quite simply like div class="highlight updated updatedByOthers"
CSS variables are nice, but it's very easily achieved with dynamic CSS. Setting up CSS themes is ridiculously easy:
body.redtheme .panel { background: red; } body.bluetheme .panel
Toggling a class on body would change entire theme.
Yes its "wrong", its a hack, but its easy to use and it does implement variables and what you described as @importRule '.highlight';
Its sad that this is needed. I don't know what is wrong with them.
Some at last talking sense !!! Variables please !!
Pete
But even if there were 'one good way', Microsoft would muck it up by doing something different anyway. Because they are retarded, and by retarded I mean 'they can get away with anything'. (Thanks for that Sara Silverman.)
When one builds a website, one has to bring the knowledge of not only a bevy of standards (html/javascript/css/xml- i could go on for days), but also browser quirks. Each browser has a differential support for standards, which breaks the notion of a 'standard'. It can take twice as long or longer to learn browsers' implementation quirks than to learn the standards themselves. Since technologies are multiplying, it's becoming exponentially more difficult to be a 'flexible developer' for different clients because you have to know exponentially more 'quirks'.
This is a big reason why I've chosen to leave the field of IT and web development forever. It's too annoyingly and needlessly complex. Have fun with CSS 3.0. It will make matters worse and won't offer anything new or better.
You can do what you want (declares/imports) ... Companies I have been with use php to declare 'variable' values all the time, eg.
.headline { color = ; }
granted, this isn't CSS ... and this isn't the cleanest way to do things (global variables, icky).
But maybe there should be a way css itself could do the programming/logic stuff and leave it to the browser to interpret it all.
How can we, with stake in this space, get the ball rolling?
For anyone who gets stuck at all the a priori's and doesn't get to the ascii art, just scroll down to the examples.
.box { width: 100% - 10px; }
As I tried to say the first time, why dont we strike up a converstation with the FF devs, it could be a very small hack to get what we want. They seem to be very much on board with making the web better.
Personally, it would be great to see a plugable CSS engine, so FF can continue to support the [sub]standard created by w3c, but also support what we all have been clamoring for... This would keep the browser "compliant", but allow us to continue pushing the envelope with the web by turning on a simple pluggin. (support the standard, yet drive innovation?)
As for building for browsers that can't/won't do what we need, I agree. Why coddle software companies that won't listen, won't standardise, and won't work with US the developers? Back in the not so old days, if you had a lame horse, it was put down.... Some companies need to take some lessons from the past, and just move on (because they certainly aren't keeping up).
-Karl
I would suggest a way to access a given background image with an index:
.myInheritedFancyBox{ @importRule '.myfancyBox'; background-image[3]: anotherImage.jpg; }
.myInheritedFancyBox{ @importRule ‘.myfancyBox’; background-image[3]: url(anotherImage.jpg); }
sorry :P
The Advanced Layout module of CSS 3 in particular looks like it will be a nightmare. And totally useless for any practical purposes. Especially since the chance of it being supported in any widely-used browser is minimal at best.
AlexG, Drew: I hope you don't imagine me so daft as to have missed what you're pointing out. In fact, I addressed it directly in the post. What grates isn't that you can't use multiple classes to set this kind of thing up at the node level (obviously you can, and in Dojo we do it to a degree which is slightly nauseating), it's that it scales like shit. It just doesn't work well when you've got hundreds of rules and would like to express small relationships between them. Being able to do something in a tortured, expensive way and being able to do it naturally is in many kinds of technology the difference between success and failure.
Regards
I have no idea why variables haven't been introduced already. Ridiculous.
Behavioral CSS sounds like an oxymoron to me. Behavior already covered by the script tag and the DOM.
Patrick
The web was about network-aware text documents wih minimal presentation quirks. But CSS+HTML+DOM+Javascript is just too much.
If they want more they can propose an open-standard implementation of something like SWF. Vector graphics, interactivity, etc. It'll be much simpler than the entire stack of CSS3/Javascript3/HTML5, smaller and with tons of more features. (But these plonkers at WHATWG would probably use XML anyway! Screw that. SWF is better than SVG exactly because it doesn't use XML madness)
http://sourceforge.net/projects/switchcss/
If there is interest, I can post a more up-to-date version on SourceForge that includes caching and speed increases.
I had never heard of moonfall before, sounds promising.
-David
(responding here because your blog doesn't appear to have a comment feature)
Thanks for taking the time to respond. Your efforts to get the CSS WG to do its work in public is much appreciated and I sincerely hope that the WG continues to make more of its deliberations open. Publishing things on the TR page wouldn't be so bad if there were any way to draw any particular item or feature back to the discussion(s) which spawned it. That the deliberations themselves cannot be examined may contribute to the artificial sense of credibility that you note.
I will note, however, that I feel the breakup of CSS 3 into separate "modules" without any visible means of punishing vendors for not implementing all Recommendation level specs accurately and in a timely fashion is a huge mistake. Breaking up the spec thusly will, inevitably, lead to more of the fumbling around in the dark that webdevs are used to as we attempt to figure out what works (where "works"=="works everywhere"), what sorta works, and what doesn't. Instead of putting the pressure on the browser vendors to duke it out at the negotiating table and making them really fight for features and prioritization, the working group took the lazy way out. There's now no enforcement, no back-pressure, and no clarity about what we "should" have. The WG has utterly and completely failed the webdev community while managing to soothe and keep the "peace" amongst vendors. It's a disgusting abdication of the WG's responsibilities and purpose.
Lastly, I was tentative about proposing this as CSS syntax, and I expected more folks to point out that the outlined @importRule and @declare are entirely ambiguous. That they haven't, I think, speaks to the reason I went ahead with it anyway: until we have some visible, tangible examples of what the world should look like, our current situation doesn't look shabby enough to beat the coeficient of static friction that prevents change. On balance I think it was worth it...it got you to reply thoughtfully ;-)
As for next steps, I don't have the temperament for standards body work (just ask Brendan), but I'd happily provide comment and work with you on an initial draft of something more concrete.
Thanks again for taking the time to respond.
Regards
However, server side generation of pages meant that this is no longer necessary. Reading NYTimes from a PDA? avantgo.com
In fact, iPhone has gone so far as to render in fixed layout mode, and let users zoom in on the content.
Time for all to head for absolute layout instead?
Furthermore, I don't think the CSS working group is necessarily the best place to decide what browser vendors should implement -- it essentially becomes a case of browser vendors putting pressure on each other. I think more author feedback in determining the list of what should be implemented would be better.
That said, the CSS WG is planning to publish a series of "state of all of CSS" documents. See http://lists.w3.org/Archives/Public/www-style/2007Sep/0097 for details. But this is less about what should be implemented than about what is ready to be implemented.
So I'm not suggesting that we necessarily punish browser vendors for not implementing everything. You're right that the W3C ratifies a lot of crap that no one needs. What I'm suggesting, though, is that there are some specs that are clearly (to use the CSS WG's terminology) "High Priority". These things (HTML, CSS, DOM) really can't be left to chance, and that's what the WG's new structure effectively does. We're facing the atomization of the second most important web spec and the organization whose job it is to force agreement isn't doing that. I'm only suggesting some sort of conformance "gold star" (carrot) or sanction (stick) now that it's almost incomprehensible as to what CSS 3 will "be" and at what level the various vendors will ship them (and when). In a world where CSS came in one bundle, this was pretty obvious: just organize a large enough raiding party and camp out in front of the steps in Redmond or Mt. View or wherever is required. Now that things are atomized, it's that much harder to get a constituency together. Maybe the list the WG is going to put together can be that "thing", but I doubt it.
As for where features should come from, I think we're in 100% agreement that the WG isn't the place to propose brand new stuff. Browser vendors need to listen to their users and implement things ahead of the specs. Once something is in the wild and is generally deemed to be useful and/or good, then standardization makes sense (and browser vendors putting pressure on each other is good and justified at that point). The CSS WG's most glaring failures seem to be around where the WG is "leading" what's shipping or are ignoring what browsers are shipping.
Regards
You have worked in sites with "hundreds" of rules that you have had to juggle? SERIOUSLY? I don't believe that for a second. If it takes that many rules, then you aren't using CSS correctly. You just aren't. What you are doing, it's called over engineering.
Trying to treat CSS like a programming language is LAME. CSS is meant to be simple. Simple.
Sincerely, Joe
Lack of variable substitution is my #1 grumble with CSS (cf. DRY principle) - this can only make life simpler, more readable and more consistent.
Inheritance sounds useful, and if you don't want to complicate your CSS with those rules, you can stay with the basic CSS.
It would be nice to have some accepted way of handling browser differences, since we all know they exist and will do for a while. Akin to Javascript techniques, checking for existence of object/capability, rather than the clever but nasty hacks that I seem to be forced to include occasionally.
Al
You don't need @importRule as you can apply multiple classes to the same HTML element.
Regards, Francesco
W3C must be a bunch of old farts who've never seen a Playstation. I mean COME ON OLD FARTS I want to make a cool Tony Hawks style menu system?
HTML + CSS = turd. Just take a look at flash and silverlight. Lets just make the web copy them.
Static text at 90 degrees + static pictures = printed pages. I want the INTERNET - NOW!
http://www.w3.org/TR/2007/WD-css3-grid-20070905/
Wouldn't this do the exact same thing and work right now?
.highlight, .updated, .updatedByOthers { color: red; text-decoration: underline; }
.updated { background-color: yellow; }
.updatedByOthers { color: #3f5070; /* a nice dark blue */ }
.box { width: 100% - 10px; }
Hate this:
.myInheritedFancyBox{ @importRule ‘.myfancyBox’; background-image[3]: url(anotherImage.jpg); }
Why not use the syntax of other languages that inherit:
.myInheritedFancyBox extends .myfancyBox { background-image[3]: url(anotherImage.jpg); }
or:
.myInheritedFancyBox( .myfancyBox, .myCommentBG, .myFancyBorders) { background-image[3]: url(anotherImage.jpg); }
the above would inherit from all three classes.
Anyway, whatever the syntax we need this - please!!
monk.e.boy
http://www.veerwest.com/sandbox/importrule/
-
David Baron requested a wiki page to document use cases and ideas about macros etc. That page is here: http://csswg.inkedblade.net/ideas/constants It currently has syntax added by www-style members, but no real use cases. Feel free to add yours.
-
The Print Profile isn't targetted at web browsers, it's targetted at another market that is using CSS, namely the printer implementations. (There are printers whose firmware understands XHTML+CSS; they're using it for things like templates for photo printing and such.) The Web doesn't need this profile, but they do, so their WG reps put their time into writing it.
-
The WG had a discussion about whose job it was to create a CSS Desktop Browser Profile, i.e. a document defining the features that a regular desktop browser is expected to implement and which can be used as a single specification authors can pressure a browser vendor to support. This discussion basically consisted of the two major browser vendors present trying to convince our chair that the WG's job isn't to dictate which features are implemented in browsers because that's more realistically and more effectively done by pressure from web designer community they're trying to serve. Choosing features for such a profile isn't something the WG is designed for: we're designed to write the specifications that define those features. We're not as well-suited to analyze which ones are needed most by the web authoring community.
"Yes, aliases and constants have been considered. As David Wheeler noted, "Any problem in computer science can be solved with another layer of indirection."
CSS is already an indirection. Instead of putting properties and values directly on elements, it associates properties and values with selectors. What you (and others) are proposing is to add another layer of indirection. By doing so, one could possible write shorter, more manageable style sheets. However, there are also some downsides. It requires a new syntactic construct (@alias) and implementations must be able to remember a list of aliases. What if aliases are defined in one style sheet and referenced in another -- should that work? If so, what if the first style sheet isn't available?
For CSS1, the downsides of aliases were considered more significant than the benefits."
http://interviews.slashdot.org/article.pl?sid=06/06/23/1443203
Fascinating article! Thanks for passing it on.
I guess I'm sympathetic to the process by which they were left out early on, but not to continued stalling on adding them. We've got a LOT of experience with how these things are used in the real world today, and whatever the pressures on CSS 1 to keep it simple, my view is that these arguments stopped holding water half a decade ago.
Regards
@define myColor red;
import(blue.css)
@define myColor blue; (ignored)
For the @importRule idea, there's no doubt this would be useful but it makes a lot more sense to use a CSS pre-processor. In my opinion, the benefits are unclear and adds unjustified complexity.
Last note: It would be great to be able to vote somewhere for W3C spec ideas & recommendations.
I'm sorry, but no matter how good your mastery of the cascade is, nothing more than a simple layout can be achieved in just 30 rules.
Now, back to supporting the @importRule idea. There's recently been loads of discussion about the emerging use of CSS frameworks like Blueprint. Mine and many other people's concern with this framework is that it requires assigning classes to elements specifically for layout purposes leading to much lower maintainability and reduced semantics.
With an import system you could throw in your framework css, then do things like:
.article { @importRules 'column span-15 prepend-1'; /* other styles */ }
Then you don't need to worry about non-semantic classes in your html because it's all taken care of in the CSS. You gain all the advantage of the excellent frameworks that are being produced with none of the drawbacks. As it is I've been highly tempted to combine use of Blueprint with Moonfall to achieve the same effect.
Yes, CSS should be more than it is. Agreed! But if you truly see NO value in the CSS 3.0 Advanced Layout specification then your world must be as narrow as your ideas presented here.
You disparage and encourage others to disregard entire specifications with tons of good ideas (and a few bad ones). Then you offer us ... CONSTANTS?
The day I can fully divorcing content from layout and banish useless classes like .right, .left, .span-24, .column1, .bottomnav, et al is a day I look forward to.
Look a little harder and you may be able to see that forest out there past all those trees.
I’ve posted my thoughts here: http://blogs.msdn.com/alexmog/archive/2007/09/25/css-not-moving-blame-microsoft.aspx
I'll be frank: define and implement it already! Surely a JavaScript can parse some text and manipulate all of those .style attributes. And if someone ever finally decides to optimize the browsers to what we're doing, because the documents are right there, we can look around and say "hey".
I do quite like the ASCII-art model of laying out the page, that you're so critical of. No, it's not perfect, and I would certainly hope to see a more technical alternative, but as a way to help newbugs buy into CSS and get into using CSS for layout instead of tables.
While we want to raise the bar as far as browser support and CSS standards go, we also need to remember to lower the barrier to entry - CSS needs to be easy to use, or else we won't keep converting people to it, and the tables will be perpetuated.