W3C home > Mailing lists > Public > www-style@w3.org > October 2011

Re: Better Variables through Custom Properties

From: Brian Kardell <bkardell@gmail.com>
Date: Fri, 28 Oct 2011 11:14:10 -0400
Message-ID: <CADC=+jfBXDB5R+LW1dvrKpH_f4xyRrmqOsh5j1yqLRu2cnXgSw@mail.gmail.com>
To: Roland Steiner <rolandsteiner@google.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Boris Zbarsky <bzbarsky@mit.edu>, www-style@w3.org
Just a thought, but is there a sensible alternative to data-*?  It
seems confusing to me that data-* is not strictly related to html
data-* but they look the same.  Maybe set-* accessed with get()  -- or
just var-* accessed with get() or var() or recall() or something?

I know this is bike shedding at this point but this is definitely
seems like one of those things that people might quickly start talking
about on blogs, etc... For me it feels like it will add unnecessary
confusion that could be cleared up pretty readily.

On Tue, Oct 25, 2011 at 5:03 PM, Roland Steiner
<rolandsteiner@google.com> wrote:
> As a preface, let me stress that I'm happy if we get this kind of variables
> regardless of the details, so I don't want to derail the thread by
> bikeshedding (below I just address some parts where I feel there are
> misunderstandings - feel free to skip them).
> TL;DR: If we have to choose between current and inherited value accessors,
> my vote would be for 'inherited', because it's IMHO simpler as well as more
> powerful. Conversely, accessing the current value adds a whole level
> of complications, implementation-wise.
> On Tue, Oct 25, 2011 at 12:45, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> 1. You can only do that if you only have a single layer of dependency.
>>  Multiple layers require you to add wrappers to your HTML, which is
>> horribad.  (Adding wrappers for layout purposes is one thing.  Adding
>> wrappers *so you can derive variables* is beyond the pale.)
> I'm certainly not advocating adding wrappers. One might need to introduce
> additional variables, but wrappers shouldn't be needed in either approach.
>> > OTOH, with the current value you also have this question:
>> > .x {
>> >   data-foo: red;
>> >   data-bar: data(foo);
>> >   color: data(bar);
>> > }
>> > #y {
>> >   data-foo: green;
>> > }
>> > <div class=x id=y> Red or Green? </div>
>> > I'd argue it should be green, but that means local "helper variables"
>> > are
>> > not all that reliable.
>> This is *exactly* what you want - being able to use the cascade is a
>> decent part of the appeal of this approach.  Note that with your
>> approach it's impossible to do something similar unless there's a
>> wrapper you can target instead.
> I'd contend you *don't need* this. But what I wanted to get at with this
> example is an implementation issue: you couldn't just apply and overwrite
> properties in ascending cascade order - this would leave the text red in
> above example.
> - Roland
Received on Friday, 28 October 2011 15:14:38 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:05 UTC