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 Thursday, 6 September 2012 18:29:50 UTC