CSS3 . Info
Summary of the two current CSS Constants proposals
by James Hopkins, 15 November 2008 12:48 PM
There’s been an apparent need
(voiced by the web community) for CSS-based Constants ever since
the conception of CSS (even though there are many established
server-side preprocessors in existance). From reading blogs and the
like, people are either very much in favour or very much against
the idea, but the feature’s mixed reception hasn’t stopped members
of the CSSWG exploring and discussing the idea further, to the
point where we now have two fairly detailed proposals from members
of the Working Group. The aim of this post is to explore and then
summarise the current state of both proposals (from an authors
not a vendors point of view), comparing features of
both.
Back in
March this year, Dave Hyatt and Daniel Glazman combined forces
and presented the first formal
proposal for Variables to the Working Group, and (based on this
spec) Hyatt subsequently implemented the module into Webkit
nightlies; the implementation was distributed for around 5 months,
but was later
removed due to concerns regarding feature adoption by authors
before the spec had any time to mature. In August this year,
fantasai submitted a counter-proposal
which detailed plans for a parse-time syntax for Constants (which
are lost after the variables are parsed and therefore not mutable),
compared to Hyatt’s/Glazman’s proposal which allowed for scriptable
Variables.
Types of Constants
Fantasai’s proposal features three types of named Constants,
‘values’, ’style-sets’ and ’selectors’; a value constant
represents a property value, a style-set constant
represents one or more property declarations and a selector
constant represents a selector. Each are declared using an
@define rule and as fantasai explains, the syntax
of an @define rule is the @define
at-keyword, followed by either the values keyword (for
declaring value constants) or the style-sets keyword
(for declaring style-set constants) or the selectors
keyword (for declaring selector constants), followed by a
block
. Examples (ripped straight from her proposal :)) showing
the syntax for each of the three Constants are below:-
Values
@define values { textColor: black; bgColor: white;
accentColor: silver; accentBorder: double silver 5px; }
Style-sets
define style-sets { noteBox { border-style: solid;
padding: 1em; border-radius: 1em; } quoteBox { margin: 1em; }
}
A feature of fantasai’s proposal is that constants are
re-usable, so you can include ’style-set templates’ which can be
applied to multiple selector declarations, using different value
constant values.
Selectors
Note that any selectors used in such a variable aren’t allowed
to be grouped (using the comma-seperated grouping syntax), since we
will have the ability to group selector variables anyway. Selector
constants would be useful for repeatedly selecting child/grandchild
etc elements deep within a complex DOM tree; consider this:-
@define selectors { deeplynestedelement: body.home
> div#main.container ~ ul#navigation > li
a[href="http"] span#child >
span#imrunningoutofnames;}
deeplynestedelement u, deeplynested b{ color:red;
}
And with the addition of a possible :match() pseudo
class in Selectors Level 4, you could do something like this to
make the above statement even more organised:-
deeplynestedelement:matches(u,b){ color:red; }
Instead Hyatt’s/Glazman’s proposal simply utilises a new
@variables rule in which any type of variable
(presumably) can be used, without the need for type keywords -
their proposal isn’t actually clear on whether different types of
variables can be parsed (or whether this proposal simply targets
value constants), however, after looking at several
test cases, the implementation seems like it was capable of at
least parsing ’style-sets’ constants too.
@variables { CorporateLogoBGColor: #fe8d12; }
div.logoContainer { background-color:
var(CorporateLogoBGColor); }
Scoping
Two fairly major differences between the two proposals are their
scoping behaviour. In fantasai’s proposal, by default, the scope
of a named constant does not ordinarily cross @import
boundaries
; this essentially means that the use of variables
declared in one @import are restricted to that
particular stylesheet, unlike Hyatt’s/Glazman’s proposal where, by
default, constants cross @import boundaries. However,
using fantasai’s proposal, authors do have complete control over
the scope by using one of three new keywords (which is placed
between the @import keyword and the stylesheet URI),
push, pull and sync;
pull allows constants declared within the imported
stylesheet to be used in the importing stylesheet;
push allows constants declared above the
@import rule in the importing style sheet to be used
the imported style sheet; sync allows both of the
previous, simultaneously.
The two proposals differ also in the way that constants relate
to, and work with Media Types. In
Hyatt’s/Glazman’s proposal, an optional Media Type keyword can be
placed between the @variables keyword and succeeding
block declaration. In fantasais proposal, constant declarations
(placed within a @define block) can be nested within
an @media block. However she metions, …if declared
inside an @media rule, the scope of the declaration
does not end with the @media block
, meaning that
constants can be used outside of the @media they’re
placed in. It’s worth mentioning that the @media rule
model/syntax differences could be trivially modified to use the
other’s media type syntax.
icons after the pull-down lists. This means that if
you want to reapply, say, a block selection after doing something
else, only one click is needed (rather than having to choose
another option, then choose the original option). The effect of
this on the ease of use of UniView is much greater than I
expected.
to the text area. If you click on this, all the
characters in the lower left panel are copied into the text area.
This is very useful for capturing the result of a search, or even a
whole block. Note that if a list in the lower left panel contains
unassigned code points, these are not copied to the text area.
