http://lazywebmastertools.com/blog

I propose something like this:
input[type=button], input[type=submit], button {
background: {image1} {repeat} {attachment} {position} {z-index};
background: {image2} {repeat} {attachment} {position} {z-index};
}

Alternately, the “z-index” of each background image within the rule could be determined by the order it appears within the rule, such as: first is on the bottom, second is just above it, and the last image is the top-most image.

At the very least, let us apply multiple backgrounds to one element through the use of multiple classes. I know this goes against theory of web design (in that you can only apply one background image to an element), but we’re seriously limiting ourselves. The Web is a dynamic medium, and it’s “designability” should be dynamic as well.

I think laziness has overcome the w3c. It’s truly sad. Now that IE 7 is out, we’re gonna have to wait much longer to see any css3 support from IE at all, even if the w3c gets their act together and starts striding towards finalizing it.

Imagine debugging this gem spread across 5 or 6 styesheets …

.highlight { color: red; }
.sidebar a {
@importRule ‘.highlight’;
font-weight: bold !important;
}
#foot a { color: blue; }
#foot p.right a {
@importRule ‘.sidebar a’;
font-weight: normal;
}

I only see it getting worse from there.

We all have ideas of what would make our day-to-day work easier. I would like to see print/paged media concepts extended to the screen world so as to better separate unrelated content. Like …

@screen #foot {
.vcard { color: gray; }
.legal { color: white; }
}

I can see problems here too though because my main goal is to avoid typing it this way…

#foot .vcard { color: gray; }
#foot .legal { color: white; }

Namespacing in CSS 3.0 combined with XHTML 1.1 modularization offers solutions to many of our current “problems” that are more forward-thinking than mine above. I’d like to see more pressure on the browser makers and the W3C to get moving.

If you haven’t done it, look at Prince XML (the most up-to-date CSS engine I’ve used). If you don’t know this already, you’ll learn that CSS is for more than HTML and that Microsoft really does/did have the box model wrong. At the very last though, I can guarantee that you’ll want those selectors NOW.

I can’t imagine a Web 2.1 without CSS 3.0 and XHTML 1.1.

Why is CSS selector syntax so similar to — yet so different from — XPath?

Correct me if I am saying wrong?

What is being described is an excellent idea … for a PREPROCESSOR, not for the CSS standard.

What value is added by having the client figure out what a page building environment can precalculate?

Exactly none. One of the things that makes CSS usable is that it can be parsed in exactly one pass, without having to perform lookups or substitutions, or actually do anything beyond actually just parsing, which means that the parser can start immediately, be done a short time after loading, and just apply the parsed rules. Adding substitions and constants (and xpath selectors, as other people have suggested to me in the past), would just end up in users seeing a lot more FOUC than they do now.

I think the pre-processor route is the way to go because it doesn’t rely on third-party support and ultimately there’s nothing wrong with CSS. CSS is fine, it works — but it would be nice if we could manage it more effectively.

No one expects the HTML spec to change to support all the functionality PHP, ASP, JSP, etc. provides, we shouldn’t expect the CSS spec to either. And we shouldn’t expect others to do it.

Many CSS authors have expressed interest in variables, constants, includes, rule nesting, and inheritance. Here’s 2 projects that have some of this functionality (I helped write Switch):

Switch CSS Pre-processor: http://sourceforge.net/projects/switchcss/

CSS Server-side Pre-processor: http://www.shauninman.com/archive/2007/06/27/css_server_side_pre_processor

If you are interested in this functionality, support these projects and others like them.

What value is added by having the client figure out what a page building environment can precalculate?

.highlight {
color: red;
text-decoration: underline;
}

.updated {
@importRule ‘.highlight’;
background-color: yellow;
}

.updatedByOthers {
@importRule ‘.updated’;
color: #3f5070; /* a nice dark blue */
}

Current CSS code that accomplishes the same thing:

.highlight, .updated, .updatedByOthers {
color: red;
text-decoration: underline;
}

.updated, .updatedByOthers {
background-color: yellow;
}

.updatedByOthers {
color: #3f5070;
}

Perhaps rather than wasting time inventing new things we can focus on learning how to use the CSS that is already available? However, I do agree that constants would certainly be useful, especially in large CSS sheets … but you can already do that with a server side language. CSS can be dynamically generated.

and yes, I would kill for css constants and this kind of import rules. And most of all I would kill to have M$ to respect all the standards and to have somekind of windows update to upadte 6.0 and 7.0 too!

This importRule mechanism seems to solve those complexities. However, what does, a statement like importRule “div.class” refer to? Does it import all rules with pattern exactly equal to “div.class”, or does it import styles by cascading? Would it also import “.class” rules, for instance? That would make things messy, too, but as long as you refer to exactly one rule, it seems simple enough.

So my proposal would be to allow for “named rules”, or “rule templates”. For instance:

@template('big') {
font-size: 200%;
}

.other {
@importTemplate 'big';
... more ...
}

That seeems cleaner, easier to use and easier to implement.

here it is

blahblah


but isn’t that the same as giving an element 2 classes in the first place

blah blah