Now, to the topic: I love being able to completely alter the presentation of an html document using simple and very high-level descriptors, eve if it is through hacks that twitch the original purpose of the language. CSS was *not* built with layout in mind, it just turned out to be a far better alternative to tables… Sure, I’d love to write width:100%-200px center and then see it work even in Internet Exploiter, and I too have experienced frustration when the perfect, most semantic, lightweight and simple-to-maintain solution to a layout (yet again, the “L” word) challenge needed only a simple if statement somewhere in the description.

But DOM injecting, querying and manipulation? IMHO, not for CSS… JS does it well only thanks to frameworks! But you know what? rather than advocating for more “complex” CSS, I say screw the DOM! It’s an excessively and unnecessarily complex solution to a much simpler need: the parsing and rendering on information, which is increasingly dinamically generated.

I say the X in Ajax it’s the way to go, and the sooner the better.

The inverse is that designer refuse to see that wiring and automatizing every case is not the solution.

There is CSS and JS. Maybe the solution is to allow JS in CSS.

Adding s here and there to create custom backgrounds for elements that already have background, is again, missing the point…

how about floating object, but in the center?

And I agree about basic math, hopefully some of Matts’ ideas will be picked up, and rather then giving us pre-built solutions, we will get better tools…

For the equally spaced tabs example, how hard would this be:

ul.tabs li {
width: distribute;
}

Seriously, look at absolutely any design application and take a hint.

I do not see the need for dom manipulation. That would just be a new method to implement the same old hack- wrapping everything in n divs just to get a reasonable level of control.

Pretty much all of us use some kind of template engine. And the server side is a perfect place to pursue expressions like 100%-10px or 800px/3. It looks like this:

100%-<%= Consts.widthOfSth %>
800px/<%= Consts.NoOfCols %>

(examples in ASP, but you get the point I assume). Basically you just run expressions on server-side.

The problem – something changes on client-side. The solution – use javascript then. Hint – javascript is text and can be also generated from template. Using same objects and values etc.

What I don’t want to see, is implementations of CSS3000 with variables and whole blown language and whatnot created by 3 different teams. One would be perfect but slow, the other fast but rough on edges, and you don’t want to even consider the possibility of something like this coming from the land where the shadows lie!

CSS is not perfect but it’s a good start and it’s moving in the right direction. Adding “DOM traversal, reference, and injection” to CSS breaks another desired separation idea – functionality and presentation. If CSS is only about layout, and that’s what it is, and should stay so, then it shouldn’t be able to mess around with DOM.

You have HTML for content, JS for functionality, and CSS for presentation (roughly speaking). Neither of these is perfect, and in many instances they tread on each other’s domains, but I believe as web grows and as each is evolving they will keep improving in that regard, and DOM traversal is a step, nay a leap, backwards.

I do agree, however, that the whole process should be faster – there’s no good reason why HTML5 and CSS3 are taking so long other than bureaucracy.

Pretty much all of us use some kind of template engine. And the server side is a perfect place to pursue expressions like 100%-10px or 800px/3. It looks like this: 100%- and 800px/ (examples in ASP, but you get the point I assume). Basically you just run expressions on server-side.

The problem – something changes on client-side. The solution – use javascript then. Hint – javascript is text and can be also generated from template. Using same objects and values etc.

What I don’t want to see, is implementations of CSS3000 with variables and whole blown language and whatnot created by 3 different teams. One would be perfect but slow, the other fast but rough on edges, and you don’t want to even consider the possibility of something like this coming from the land where the shadows lie!

http://www.jclark.com/dsssl/

I remember reading about this 8-10 years ago — a book I was perusing in the local Borders had chapters on both DSSSL and CSS. And some of the advantages of DSSSL sounded quite a bit like what Wilcox is after here…

I think DOM traversal is a little too much, but DOM inserting sort of exists today with p:after {content:’.';} it only could be more complete:

.blocks {insert-before:''; insert-after:'';}
#content {insert-wrapper:'';}


Or it could be even simpler:

.blocks {insert-before:'span.round-top'; insert-after:'span.round-bottom';}
#content {insert-wrapper:'div#content-wrapper';}


I see much need in css-maths like
width: 100% – 200px;

:)

As for all this debate I feel one of the fundamental problems is this dumbing down issue with CSS. Real world developers need CSS to have advanced features, the CSS working group’s response to that is “CSS needs to be simple” so people understand it.

CSS needs to stop only supporting the lowest common denominator. If everybody did that we’d still be writing assembly or ASP or some god awful un wrist friendly language because other programmers can’t wrap their heads around functions, inheritance, reflection, etc.

I say CSS needs to be both. It needs to be simple, but the development community needs advanced features so CSS WG get your @$$ in line and start providing them. All languages have simple features and then advanced ones. You can write procedural code with JavaScript and you can write Object Oriented code. I want multiple background images, I want variables, I want better layout techniques, fonts, text shadows, animation, element shadows, transforms, and I want it all yesterday :)

The fact is that even if CSS3 isn’t ideal, it would allow us to do a lot of things we can’t do now. Same with SVG and Canvas and other next generation web technologies.

At some point though, when there’s a layer of cruft too thick to use, we will likely wind up having to use an abstraction layer like gwt just to be productive. Not that these technologies aren’t powerful, but they aren’t quite cohesive, and the cross-browser support will be a nightmare.