Re: CSS Referencing

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 Tuesday, 17 January 2012 17:23:07 UTC