W3C home > Mailing lists > Public > www-style@w3.org > January 2012

Re: CSS Referencing

From: Brice PARENT <brice@websailors.fr>
Date: Thu, 19 Jan 2012 18:35:14 +0100
Message-ID: <4F185452.7090007@websailors.fr>
CC: www-style@w3.org
I (think i) understand how complicated this subject is (even more since
i've read your answer, TJ), but i also imagine how powerfull this could be.
By the way, I really liked these CSS-variables (i didn't know about
them). This CSS referencing (if it has to be created), should be based
on this system which seems to be mature.

So i guess, if we want to allow such a thing as css referencing, we
would have to restrict it to the elements with IDs, like :
.exampleClass{color:as(exampleDivId.background-color);} where
exampleDivId would be a div id, and the value used for the color of
exampleClass would equal the "actual" value of the background-color of
#examplediv.
If #exampleDivId background-color changed, every .exampleClass elements'
color would too.
If #exampleDivId's background-color is not set, the class wouldn't
redefine the value (keeping it to its default state, like auto, inherit,
...) until the property exists.
I think, to create this functionnality, the system wouldn't have to make
more than a few simple things :
(as English is not my native language, it is easier for me to explain
this using an example)
Starting point :
#div1{width:50px;}
.just_as_div1{width:as(div1.width);}

1 - creation of the css-variable (in memory) :
#div1{data-oneGeneratedTempName:50px;}
#div1{width:50px;}
.just_as_div1{width:as(div1.width);}

2- replacing (in memory) :
#div1{data-oneGeneratedTempName:50px;}
#div1{width:50px;}
.just_as_div1{width:data(oneGeneratedTempName);}

3- adding a listener to the width of #div1, which would update the value
of data-oneGeneratedTempName.


Wouldn't that be possible without too many complications?



Le 17/01/2012 18:22, Tab Atkins Jr. a écrit :
> On Mon, Jan 16, 2012 at 7:36 AM, Brice PARENT <brice@websailors.fr> wrote:
>> I think this is a two part proposal :
>> 1 - allow to reference a property to another one
>> 2 - ask for those reference to be able to create bidirectionnal
>> relationships.
>>
>> For the first, before being lead to this list, i've created the list
>> http://lists.w3.org/Archives/Public/www-style/2012Jan/0673.html.
>> I copy the examples i proposed here just to be clear :
> [snip examples]
>> About the fact that we could always create a shared css class containing
>> the common values, i agree but it kills some of the benefits of using
>> css : We either have to create lots of classes (smallText, biggerText,
>> hugeText, smallMargins, ...) and have many classes placed on every
>> element, which would lead to setting the style right in the html, or we
>> have to create a very big css file containing every single case for
>> every common properties (div.test1 table.test2 td:first-child, div.test3
>> ul, div.test4 ul:hover...{color:red}), and it wouldn't allow to share a
>> color and a background color.
>>
>> This referencing would shorten a lot the css selectors, and would help
>> to have a simple new kind of inheritance.
>>
>> It should not be seen as the programming goto, but more like a variable,
>> which may be called from anywhere. Every element has a set of variables
>> that always have some values (default or inherited at the beginning),
>> that we set using the css propoerties, and some of these properties are
>> just like pointers to those variables. The values that are read are
>> never computed values, but always the values that are asked (default,
>> inherited, set, or pointed).
>>
>> About the second point, i agree that it may be more complicated, and
>> that's not that much what i asked for.
> This is a complicated subject!
>
> Direct value referencing is extremely complicated.  CSS values pass
> through five distinct stages (cascaded, specified, computed, used,
> actual), and it's important to distinguish which stage you're
> referencing.  Each has benefits and disadvantages.  In earlier stages,
> the data is less valuable.  For example, in 'width:auto' the computed
> value is still 'auto' - it doesn't turn into a length until used-value
> time.  So, you probably don't want to reference such an element's
> width at computed-value time.  However, in later stages there are many
> more dependencies between elements and properties, so it becomes very
> complicated to avoid circular dependencies, particularly invisible
> implicit ones (like the fact that line-height's computed value depends
> on font-size if line-height is specified as a percentage, and its used
> value depends on font-size if line-height is specified as a number).
>
> As well, referencing rules by their selector doesn't work.  Multiple
> rules can have the same selector, and simple refactoring can change a
> selector, which would break all the references.  Doing this would
> instead require some way of giving a rule an id, so that one could
> refer to by that id.
>
> Your later idea about @bank, though, *does* work, and is addressed by
> CSS Variables <http://dev.w3.org/csswg/css-variables/>.  Earlier
> iterations of this idea looked similar to yours, with a global
> declaration of variables.  The current incarnation instead leans on
> properties and inheritance to pass variables around, but accomplishes
> the same thing.
>
> ~TJ
Received on Thursday, 19 January 2012 17:35:45 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:48 GMT