Re: [css-variables] the new ED for CSS Variables

On Fri, Feb 17, 2012 at 12:35 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Fri, Feb 17, 2012 at 5:33 AM, Brian Kardell <bkardell@gmail.com> wrote:
>> I agree, I've said in the past that I think this is the best idea for
>> "variables" in CSS that I've seen put forward.
>>
>> Minor editorial type comments on the current state of the draft:
>>
>> I mentioned this a few months ago, but I would like to reiterate:  I
>> think it is definitely worth going to some measure to ensure an
>> understanding of the actual relationship between data properties in
>> CSS and data properties in HTML as I can easily see confusion here
>> with people doing something like:
>>
>>    <div data-foo="something">
>>
>> and then expecting to be able to say:
>>
>>    div{
>>          property:  data(foo);
>>    }
>>
>> Or vice versa.
>
> Naming is still somewhat up in the air.  We may just change the name
> entirely, to var-* or something.  If we don't, then I think it would
> be good to add a note saying that it's merely a surface resemblance.
>
>
>> The table in section #2 just says "see prose) for a description, but
>> the relevant bit it probably small enough to fit, "anything that is
>> valid according to the value production in the CSS Core Grammar."
>> Likewise, in the same table (or at least in the prose) it is probably
>> worth mentioning that the data-* would have to be "anything that is
>> valid according to the identifier production in the CSS  Core
>> Grammar".
>
> You may be right about the former; I'll try it out and see how it fits.
>
> The latter is implicit in the fact that it's a property name.
> Property names have a defined grammar already.


Is there harm in calling that out? I think a lot of people who _use_
CSS might not take that as quite the given you make it to be... Do you
really expect some to not try something like:

data-colors[0]: red;
data-colors[1]: white;
data-colors[2]: blue;


>
>> I know that this has come up in other threads recently too, but - is
>> there some rationale for splitting this into two _very_ small drafts,
>> one that deals with the CSS part, and the other that deals with the
>> CSSOM extensions part?  It seems that the later is less done and given
>> the state of CSSOM it could hold things up needlessly.  I agree though
>> that access through CSSOM would be good - but that almost seems like a
>> whole separate topic and a whole different level of complexity at this
>> point...
>
> Believe me when I say that the CSSOM part is *by far* the easier part
> of the draft to implement.  It's only unfinished because I've been
> working on Images and Flexbox lately; I'll get to it soon enough and
> fill it out the rest of the way.  I'm now more familiar with how to
> use getters and setters in WebIDL, and shouldn't have much problem
> with resolving the issue.
>
> ~TJ


I guess I will take your word for it but it seems to me that CSSOM is
currently doing a little bit of soul searching in terms of what it
really wants to be in terms of APIs and however that pans out could
have an effect on how you'd like to sculpt/graft this in.


- Brian

Received on Friday, 17 February 2012 18:10:26 UTC