Why are we trying to re-invent the wheel?
Today, Peter Gasston posted an article summing up a recent post from Daniel Glazman talking about possible future extensions to CSS, and in particular Symbolic Constants.
I’m really trying to get my head round why this proposal was put forward (possibly because I’m particularly tired tonight and am missing some blatant advantages, in which case someone please point them out to me), but I’m really not sure why we’re trying to turn CSS into a programming language (see last two lines of Appendix E).
As I see it, there are several disadvantages to straying After an editor for this proposed spec has been found (apparently they’ve already identified someone) he/she will to dedicate a fair amount of resources into a) maintaing the spec, b) deciding on a suitable module for it to go into c) acquiring and managing use cases and d) finding two interoperable implmentations etc.
As far as I can see it, any constant/variable infrastructure would be completely backwards incompatible and there are currently no plans for a fallback option (I’m not sure how one could ever be implemented in this scenario?) which would be a huge problem taking into account the vast array of different levels of CSS support cross browser, resulting in widespread adoption becoming a lengthy process.
The problem that we’re trying to achieve has been a fundamental server-side lang feature since the dawn of time. There are no backwards compatibility issues and we don’t have to wait for vendors to support it - the server side solution can be used today!
Tags: CSS Constants
April 1st, 2008 at 11:09 pm
James, using a server-side solution is fine for those that work in an environment where they are able to use it - that is, where you are writing PHP, ASP, or similar - but it doesn’t help those creating style sheets where only client-side access is available. Using variables was the single most requested feature when the W3C undertook a recent consultation, so I think it only fair that the W3C look into the practicality of making this a recommendation.
April 2nd, 2008 at 5:11 am
Not bad for a 1st of April’s fool
More seriously, I am not sure I understand what you mean here about lack of fallback.
April 2nd, 2008 at 8:10 pm
@Peter: Indeed so, but I think considering the possible demographic who would utilise this feature (authors seeking to create theming consistency over a large number of pages), I would suggest that they would have access to some kind of server-side language.
@Daniel: Even though it’s a little vague, if I can take Ian’s proposed syntax on his list of suggested extensions as an example, where he uses utilises the keyword ‘orange’ as the identifier.
Although this particular ‘color’ example does present a fallback option (to a certain extent) for UA’s that wouldn’t understand the proposed Symbolic Constants, my opinion is that it’s far from ideal. With the ‘color’ property in mind, authors would have to be careful about matching up a particular keyword value (’orange’) with the same or similar hex value within the constant (with the keyword value in the element declaration acting as the fallback). The relatively small range of ‘color’ keywords that are defined in the Level 2.1 spec (in addition to system colors, which would work in this environment but due to their very nature are unsuitable (they’re also deprecated in Level 3 Color module)) mean that we are fairly restricted to the number of ‘color’ keywords we can use as identifiers, whilst at the same time making sure we’re careful to match each keyword with a corresponding hexdec.
In an environment where keyword identifiers don’t exist and where only string values can be used (take the ‘border-size’ property for example), I fail to see in this particular instance, how a fallback option can exist; a new variable value would need to be created and inserted into the ‘border’ property, like
border:$key_color solid black- this variable name of course wouldn’t be understood by browsers which don’t support this Symbolic Constants feature.April 2nd, 2008 at 10:23 pm
James, that may be true, but I don’t think the W3C can just assume that developers have access to programming languages and so not develop CSS features based on that assumption; CSS has to exist based on the assumption that the developer has client-side access only.