W3C home > Mailing lists > Public > www-style@w3.org > February 2013

Re: [css-variables] CSSVariablesDeclaration interface definition

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 27 Feb 2013 14:09:10 -0800
Message-ID: <CAAWBYDDSsxLW+NTcOaQ=UMRTC43cQ=d+f7RZdATd3baEeNkiHg@mail.gmail.com>
To: John Daggett <jdaggett@mozilla.com>
Cc: www-style list <www-style@w3.org>
On Wed, Feb 27, 2013 at 5:43 AM, John Daggett <jdaggett@mozilla.com> wrote:
> Tab Atkins wrote:
>> > In section 4.2 of the CSS Variables spec [*], the
>> > CSSVariablesDeclaration interface defines a set of methods to
>> > get/set variable values.  There's also an explicit delete method.
>> > The settor method's behavior is defined as:
>> >
>> >   When asked to set or create the value of a variable, if varName
>> >   matches the grammar of a custom property name: if varValue is
>> >   the empty string, invoke the algorithm to delete a variable;
>> >   otherwise, invoke setProperty() by passing varName as the
>> >   property argument and varValue as the value argument.
>> >
>> > I don't think it's a good idea to have setting the variable to an
>> > empty string delete the variable, instead I think it should be
>> > treated as an invalid value. Otherwise, the behavior of the settor
>> > method will differ from setProperty and will be inconcrugent with
>> > setting other CSS property values where setting a property to an
>> > invalid value will retain the previous value.
>>
>> Read the CSSOM spec again - this matches the behavior of setProperty.
>
> Ok, I see, setProperty has the same "remove when value is set to emptyString"
> behavior.  So why does that need to be spelled out in the prose above, since
> just passing it to setProperty has the same effect?

Hmm, that's valid.  The behavior is still unexpected to most people,
so I'll move that into a note.

> In fact, I don't quite see the point of this interface, the sole
> purpose seems to be to prepend "var-" on to the property name before
> calling getProperty/setProperty/removeProperty.  Is that really needed?

If that was all it did, it would still be convenient - normally,
properties are exposed on CSSStyleDeclaration as properties, using a
dashes-to-camelcase conversion.  This obviously doesn't work for
custom properties, because it would map both "var-foo" and "var-Foo"
to "style.varFoo".  You'd be forced to only use the
getProperty/setProperty methods, which *nobody* uses in practice.  The
CSSVariablesDeclaration interface fixes this - as long as the variable
name matches JS property rules, you can use it directly, without
conversion or ambiguity.

It does more, though - it exposes only the custom properties that are
actually set.  This is different from CSSStyleDeclaration's normal
behavior, which is to expose every property.  This makes it convenient
for things like iterating over all the custom properties, which I
think will be useful for JS that is using custom properties as a data
channel for polyfills or the like.

~TJ
Received on Wednesday, 27 February 2013 22:09:58 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:06 GMT