Re: CSS Variables Comments

David Hyatt wrote:

> (1) In section 4.1, the grammar is incorrect.  LBRACE is part of both 
> "variables" and "variableset", when it needs to only be declared in one 
> of them.

Fixed.

> (2) In section 5.3, removeVariable is specified as raising an exception, 
> but no mention is made of when or why it would raise one.

My bad. I introduced an empty string return value in case the
variable does not exist in the current variable declaration set but
it's probably not the way it should be. I suggest the following instead:

-----------
   Exceptions

   DOMException NOT_FOUND_ERR: Raised if the specified value has a syntax
                error and is unparsable.

   Return Value

   DOMString   Returns the value of the variable if it has been
               explicitly set for this variable declaration block.
               Returns the empty string if the variable has not been set.
---------

> (3) In section 5.4, CSS_VARIABLE is specified as having a value of 4. 
>  This conflicts with the value used for INITIAL in WebKit.  We could 
> probably move INITIAL to 5, but it might be  worth thinking about how to 
> handle DOM conflicts when CSS drafts all want to proceed along a 
> standardization track at their own pace (and may all want to add new 
> rule types and value types).

Interesting... But let me remind you that CSS_INITIAL 4 was not
submitted for standardization AFAIK.


> (4) The CSSVariable interface needs to be removed.  The CSSVariable 
> interface's existence greatly complicates *everything*.
> 
> (a) It can appear as a component of a compound value.  It will make the 
> implementation extremely difficult if I have to actually parse complex 
> values like text-shadow while hanging on to CSSVariable values for 
> pieces of that value. 
> 
> (b) An actual media context must be given in order to perform variable 
> lookups.  The CSSVariable interface can't simply have a CSSValue "value" 
> attribute, since that value is media-dependent.

I think you are here mixing two things Dave... The first thing is the
trio CSSVariablesRule/CSSVariablesDeclaration/CSSVariable that allows to
tweak an @variables rule in the CSS OM itself. Here, CSSVariable dooes
not need the media because it belongs to a CSSVariablesRule that is
media-dependent anyway... These interfaces are not here to directly
tweak a variable in the context of a given document but only to
manipulate a declaration of variables from within the CSS OM.

The second one is not available in the current spec and it's clearly a
lack, identified by my colleague Laurent Jouanneau : the ability to
simply call something like

   CSSStyleSheet.getVariable(variableName, medium)
   CSSStyleSheet.setVariable(variableName, medium, value)
   CSSStyleSheet.removeVariable(variableName, medium)

I am not sure the first one should reply a CSSValue. A string is enough
IMHO.

> (5) The draft makes no mention of where @variables rules fit in relation 
> to @namespaces.  The order needs to be specified.  I suggest saying 
> @variables occur before @namespaces.

That order is not specified because I reused the CSS 2.1 grammar. Does
the order before or after @namespace has any effect here ? The only case
I can think of is usage of an attribute-based functional notation where
the attribute name would be prefixed. And in that potential case,
@namespace rules should occur before @variables, not after...

> (6) The draft makes no mention of whether variable lookups occur using 
> every variable defined on the document or only variables that occurred 
> earlier in a depth first parse of the stylesheets.  I believe it's much 
> easier (and more intuitive for authors) if lookups occur using every 
> variable available for the current media (since dynamic re-evaluation 
> when methods like setVariable get called would be much more problematic 
> otherwise).

Absolutely, that was the intent, I'll make sure it's more explicit in
the spec.

</Daniel>

Received on Tuesday, 17 June 2008 08:37:14 UTC