W3C home > Mailing lists > Public > www-style@w3.org > September 2010

Re: [css3-values] Suggestion: Allowing attr() in calc()

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 1 Sep 2010 09:56:42 -0700
Message-ID: <AANLkTi=mZETdBbvkF8W0hkUTATzBRtk3=2zr_ohD2RgN@mail.gmail.com>
To: Lea Verou <leaverou@gmail.com>
Cc: www-style@w3.org
2010/8/31 Lea Verou <leaverou@gmail.com>:
> I would be quite surprised if this hasn't been suggested before, but I
> searched the archives quite extensively with no avail.
> As things currently stand, number and length values from attr() are not
> allowed inside calc(), since <atomic-length> is defined as only
> <number><length-unit> and nothing else
> [http://www.w3.org/TR/css3-values/#calc]. It's not as explicitly disallowed
> in the dev version of the spec, but it still doesn't seem to be permitted.
> Is this a deliberate omission?
> I think attr() values in combination with calc() could be enormously useful,
> at least for attr() expressions that return the types integer, number,
> length, angle, time, frequency and the various units. For the other attr()
> types it could be treated the same as if an invalid value was directly put
> into calc().
> Attributes would contain the actual, semantic data and then calc() could be
> used to utilize this data for presentation purposes, operating on them and
> performing any necessary calculations. If attr() cannot be combined with
> calc(), I'm afraid authors may start contaminating their markup with
> attributes that only hold presentational information. A good example for
> this is CSS bar charts (I actually stumbled upon this shortcoming of CSS3
> when trying to create a CSS bar chart with "clean" markup)

I like this idea.  It shouldn't violate the restrictions we're placing
on this version of calc() any.  An attr() that uses the 'integer' or
'number' types can be used anywhere, and one that uses 'length' or one
of the unit types can be used anywhere a length can go in the grammar.

Received on Wednesday, 1 September 2010 16:57:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:49:47 UTC