Re: [css-variables] Referencing all properties (Issue 4, !important)

Tab, you are again debating that "because this can't solve all the problems, 
it should not exist at all".

I don't see where the problem is to specify that we use the specified value 
to resolve property references (which, as you known, includes the 
inherited/initial value as neeeded). The differences between the computed 
value and the specified value are close to inexistant in most cases. The 
only major difference happens at 'used' time and you know as good as me that 
the computed value of any property can't depend on the used value of another 
one.

I have a simple example demonstrating that referencing native properties can 
be useful.

[1]

If I want to have an element whose padding-left and padding right represent 
10% of the element's width, and that I have 'specified' property reference, 
I can do:

    li.padded {
        width: 100%;
        padding: 0px calc(0.05 * use(width));
    }

    li.twocol {
        width: 50%;
    }

If I can't use the reference, I need to create a new custom property for the 
purpose, and this will mess up my code

    * {
        width: var(width);
        var-width: auto; //oops, I inherit!
    }

    li.padded {
        var-width: 100%;
        padding: 0px calc(0.05 * var(width));
    }

    li.twocol {
        var-width: 50%;
    }

Now, my code is completely inefficient, just because I had to work around 
the fact I can't make a reference to a native propery.

[2]

I regulary need to have something like this in my code:

    a.tile {
        background-color: blue;
        outline-color: blue;
        outline-width: 0px;
        color: white;
        ...
        transition: all 0.3s;
    }

    a.tile:hover {
        background-color: royalblue;
        outline-color: royalblue;
        outline-width: 5px;
    }

If I could simply use a reference, the code would be better and more easily 
maintainable :

    a.tile {
        background-color: blue;
        outline-color: use(background-color);
        ...
    }

    a.tile:hover {
        background-color: royalblue;
    }

Again, writing the same code using a custom property would be cumbersome and 
would slow down the page.

What Brian, Chris and myself would like is a simple specified-value replacor 
that works for all properties and not just for custom ones. We don't want a 
complex solution that requires new internal dependencies and you are 
rejecting this proposal because you don't want a simple solution but a very 
complex solution that's completely impossible to build.



-----Message d'origine----- 
From: Tab Atkins Jr.
Sent: Thursday, September 06, 2012 8:29 PM
To: François REMY
Cc: CSS WG
Subject: Re: [css-variables] Referencing all properties (Issue 4, 
!important)

On Thu, Sep 6, 2012 at 2:37 AM, François REMY <fremycompany_pub@yahoo.fr> 
wrote:
> Historically, one of the first ‘property references’ introduced in CSS has
> been the ‘em’ unit and the ‘currentColor’ keywords. Those are not 
> references
> to some custom, author-defined properties but native properties of the
> browser. Chris, Brian and myself strongly argue that all properties should
> be referencable.
>
> While we understand that should probably be delayed to Level 2, we do not
> want a syntax to be chosen that makes this impossible or cumbersome to 
> add.
> The current syntax var-xxx and var(xxx) makes it imposible to target the
> ‘background-color’ property for use in ‘outline-color’ because
> ‘var(background-color)’ targets ‘var-background-color’. Our proposal
> differentiates use(my-background-color) and use(background-color) very
> easily.
>
> There are also other advantages to this approach: the IDENTIFIER used to
> ‘name’ the property is the same whatever the context you are in (in the
> current proposal, it’s ‘var-x’ when you define it, but only ‘x’ when you
> actully use it, which makes renaming variables using a text editor more
> cumbersome than it should be).
>
> Tab’s response to this has been that “we need the ‘used value’” for that
> feature to be useful (and not the specified value), which seems untrue to
> me. For exemple, having an ‘outline-color’ identical to the
> ‘background-color’ seems a good use case, as well as using
> ‘width’-relative’s ‘padding-left’ and ‘padding-right’, so that you can
> update the ‘width’ property and have the ‘padding-left’ and ‘padding-right’
> automatically default to 5% of the specified width (whether you used %, px
> or em to define it).
>
> Certainly, not everything would work, but I think that this is still 
> better
> than the ‘nothing can work’ that the current Tab’s position implies.

Trying to reference the value of other properties on the current
element is a non-starter, right off the bat.

The computed value of a lot of properties depend on the values of
other properties.  This introduces implicit dependencies between those
properties, which would need to interact with the explicit
dependencies introduced by your referencing.  This could easily be
confusing, with some references failing due to cyclic dependencies
that the author doesn't even know about, and which are difficult to
debug.

Further, it lays claim to *all* remaining dependencies - we could
*never* introduce a new value to an existing property that depends on
another property, because there might be references that would
suddenly turn cyclic and break a page.  This is hostile to the future
development of CSS.  We try to avoid making choices that close off
large portions of future development, particularly when we know we've
made that kind of change in the past.

I think there's likely space to explicitly reference the *inherited
value* of an arbitrary property, but we need to see.  In any case, the
similar ability for Variables has been shifted to level 2, so we have
time to think about it.

> To be complete, another Tab’s argument on the matter has been that ‘native
> property references’ don’t require a fallback mechanism because they 
> always
> exists, which is ignoring the fact that a property may exist in a browser
> but not in another, and that we still need to define fallback for those
> cases. If we need to specify fallback, specifying it in another way than 
> for
> custom properties would not make much sense (or, at least, I was not
> presented a case where it would).

If you're trying to reference a legitimate property that isn't
supported in a legacy user agent, you probably need to do more
adjustment than just providing fallback for the one reference.  This
is what @supports is for.

If you're trying to reference a vendor-prefixed property, and need to
fallback to other prefixed versions, I don't think we should consider
this a valid use-case.  I'm in favor of having prefixed versions be
fragile.  ^_^

~TJ

Received on Friday, 7 September 2012 09:37:26 UTC