Update: Martin Payne has just come up with what I feel is the most *ingenius* solution to the not ‘not important‘ dilemma…

The first time I saw !important, I also thought it meant “unimportant”. Even though I now know how to use it, I still don’t like it much. Perhaps a double negative !unimportant would have been better, but I guess that would cause just as much confusion for people not familiar with Boolean. How about !!important instead then? :o)

I LOVE IT!

Anybody have a contact on the CSS WG at the W3C? I’d send them the suggestion, but I’m pretty sure that if there isn’t one already, an automatic filter to send any emails from me directly to the “Trash” folder would be created soon thereafter. ;) :D

–
Update: I got home last night running on energy reserves, so I am just getting to this planned update now. As per this same linked comment below,

@David Håsäther, Anonymous,

All *VERY* good points. Thanks!

I am literally rushing out the door, and I need to read both of your comments more thoroughly to absorb things a bit more. One thing I will add to the top of the post later tonight when I return is the fact that,

a) This was obviously something that the designers of the spec *HAD* to take into consideration when they chose to move forward with it, and as such,
b) There’s probably a pretty good reason why they chose to move forward with it.
c) I’m probably being just a little too annoyingly nit picky.

So there ya have it. :)

There are some *REALLY* good follow-up comments below from the above mentioned folks, as well as David Buxton, and Asbjørn Ulsberg. If you have a moment, taking note of their comments would be *WELL* worth the time you invest.

Thanks folks!

[Original Post]
By force of habit, when I visit any of the documents that relate to a particular standard hoping to gain further in-sight into why something is not behaving the way I think it should, I will often times find myself running through this same specification from start to finish, just to make sure that the reason behind my misunderstanding relates to the specific question at hand, instead of something else in the specification that might override the specified behavior, and therefore be the source of my misunderstanding.

I was just brushing up on a few CSS-related things as they relate to the rules of inheritance. Of course, in doing so I came to the ‘!important’ section of the Assigning property values, Cascading, and Inheritance section of the CSS2 specification.

Maybe I’m the only person on the planet who feels this way, but coming from the perspective of a hacker who’s experience with coding is built from a ‘programming language’ foundation, instead of a ‘property=value’ pseudo language such as CSS [1], when I see the ‘!’ character in front of any other character, or set of characters thereof, I immediattelly think “not important”, which for those unaware, is the standard way in most modern day programming languages to negate the object, or element, or attribute, or operator, or etc… that follows it, using this to compare two of the same previous mentioned items, using the resulting boolean value (true or false) as a way to make a decision as to what to do next.

For example,

if (a != b) then print c; else print d

would read,

if the value of ‘a’ does *not* equal the value of ‘b’, then print the value of ‘c’. If it does, print the value of ‘d’.

So, with this in mind, consider the following,

… for balance, an “!important” declaration (the keywords “!” and “important” follow the declaration) takes precedence over a normal declaration. Both author and user style sheets may contain “!important” declarations, and user “!important” rules override author “!important” rules. This CSS feature improves accessibility of documents by giving users with special requirements (large fonts, color combinations, etc.) control over presentation.

While I understand the need for, and both respect and applaud your efforts in regards to,

This CSS feature improves accessibility of documents by giving users with special requirements (large fonts, color combinations, etc.) control over presentation.

Don’t you think “Programmers Usability” is important too?

Okay, fair enough… From the perspective of a non-programmer, the presence of ‘!important’ will more than likely invoke a sense of “this is REALLY important”, but to learn the concept of boolean comparison is not what I would term a “stumbling block”, and never in my life have I heard someone state “this ‘!’ = *not* stuff is just *TOO HARD* for me to understand. I JUST DON’T GET IT!”, and as such, I have never really understood that particular argument.

Taking this a bit further, wouldn’t ‘important!’ be a bit more meaningful to this same non-programmer than would ‘!important’? That said, I recognize that from the stand point of a parser, its faster to recognize a single ‘!’ character, and understand that what follows next to be given a higher weight when determining the total specificity of any given CSS value using the [browser, author, user] stylesheet order of precedence rules. But then why the use/need of ‘important’ that follows it? Wouldn’t ‘!’ be enough to suggest that what follows is “important”, and should take precedence? What value does ‘important’ bring to the table that can not be determined by using the ‘!’ character alone? In other words, if parser speed is the reason for breaking the standard syntax for boolean comparisons, then why slow the parser down by adding the ‘important’ keyword.

Of course, maybe the point was to allow the ability to add other keywords that follow ‘!’ in future versions of the specification, but if this is the case, then why the need for the ‘!’ character at all? If we have already slowed the parser down by adding the ‘important’ keyword, then the ‘!’ character is just added baggage, of which has now just made the language more complicated for no apparent reason other than “because.”

You know, there are times where I can understand the criticisms sent Microsoft’s direction for not implementing full support for CSS 2.x (e.g. attribute selectors), and then there are times where I want to applaud them for !implementing areas of the spec that make matters more confusing rather than less.

Then again, maybe there’s something that I’m missing thats not immediattely obvious. But in and of itself, that statement should be enough to understand my point: When you design a specification who’s purpose is to make the lives of those in whom choose to use the specified technology as part of their development, easier, if the purpose for something is not immediatelly obvious, and even further, holds potential to confuse matters by breaking away from the standard and common syntax used by a significant majority of other technical specifications, you have just had the opposite of the intended effect by making things harder to understand, and more complex that they should *EVER* be.

Just my two cents.

Thanks for reading. :)

—
[1] To all of you who are about to enter in “I hate you, you suck!” comments fan mail, please don’t do so on the basis of your belief that CSS *”IS TO A PROGRAMMING LANGUAGE!”*, err, I mean “!IS TO A PROGRAMMING LANGUAGE”.

For the record, no it’s not. CSS is a compact syntax that allows you to select elements within an (([X] and/or [HT])ML) document, and either set or change the setting of the value of the specified element. (e.g. a {color:red; text-decoration:none}). Nothing more, nothing less. Of course there are those who will argue that because you can dynamically change the values of a given property, and the fact that, for example, {display:none} will make any given element automagically “disappear”, that this alone means it is a programming language because you can

a) select items based on a certain criteria
b) change the values of the properties of these same selected items to something else.

Firstly, with CSS, no you can’t. To “change things” you need to use a programming language such as ECMAScript (Javascript).

Secondly, what you are really dealing with is Dynamic HTML (DHTML), which allows the ability to handle captured events that take place within a document (e.g. onmouseover), to then change the value of any given property, of any given element. Of course at this level, you have completely bypassed CSS all together, and gone directly to the Document Object Model, who’s spec contains a section termed ECMAScript language bindings, which will then point you directly to the ECMAScript language spec for programmatically dealing with things such as the aforementioned DHTML event model (although this is never explicitly stated. Ahhh… the nature of specification development politics. You gotta love it! No you don’t.)

Disclaimer: That last bit regarding the exclusion of any reference to DHTML having to do with politics is *MY OWN OPINION*, and is more than likely wrong. I’ve just never understood, completely, the reason for the lack of mention of the DHTML events model (designed by Scott Isaacs and built (at least, from what I understand) by the IE4 team headed by Adam Bosworth, who at the time (obviously) was with Microsoft.) inside *ANY* of the DOM specifications (I promise, I’ve looked through them all), or for that matter, other than random references here and there in various presentations and various “under development” specifications, anywhere on the W3C in any sort of official capacity.

Microsoft, did you forget to pay your W3C dues? If you did, that would certainly help explain things a bit better. ;) :D

While I realize it would be embarrasing, if you’re a bit short on cash, you know all you have to do is ask, right? ;)

You’re welcome :D