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

Re: [css3-values] types and where attr() and calc() can be used

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 11 Apr 2012 10:36:30 -0700
Message-ID: <CAAWBYDCExOQhukFMyOC1WfJZDZABr6ZSHLgeRoqgkP4kufnmEw@mail.gmail.com>
To: "Kang-Hao (Kenny) Lu" <kennyluck@csail.mit.edu>
Cc: WWW Style <www-style@w3.org>
On Wed, Apr 11, 2012 at 5:36 AM, Kang-Hao (Kenny) Lu
<kennyluck@csail.mit.edu> wrote:
> The attr() section says
>  # If the type is not valid for where the ‘attr()’ expression is
>  # placed, the whole ‘attr()’ expression is invalid.
> , and my interpretation of this sentence is that 'attr(<wqname>
> integer)' cannot be used where <number> is expected. (This
> interpretation might not match the intention of the person who wrote
> this prose, but if that's the case I request this vagueness be
> clarified. )

This is already handled - the definition of the <number> type says
"either an integer, or ...".  So an <integer> is a <number>.

> On the other hand, it's not clear to me whether we should do this in the
> other way around. That is, accept 'attr(<wqname> number)' when <integer>
> is expected. Some of the relevant options, ordered by my preference:
> A. Properties accepting <integer> also accept 'attr(<wqname> number)',
> with either truncating or rounding applied when necessary.
> B. Drop 'integer' as a <type>. 'number', when used as the <type>, infers
> from the property whether the attribute value should be parsed as
> <number> or <integer>.
> C. Drop 'integer' as the <type>. The attribute value is always parsed as
> a <number>. Apply truncating or rounding when necessary.
> Some of the reasons why blurring the boundary between <number> and
> <integer> might be a good idea:
> 1. Two CSS books targeting designers at my hand don't talk about the
> difference between <number> and <integer> when introducing CSS types
> (which include color, length, etc.), a bit like how w3schools.com
> introduces 'z-index'[2] (it says 'z-index' accepts /number/). It's not
> clear to me how many percent of CSS authors are aware of <integer>.
> 2. This would be consistent with JavaScript, which doesn't have integer
> type at all.
> 3. 'integer' is harder to type and spell.
> The obvious drawback of the above proposals is that some people do know
> <integer>, including those who read materials containing property tables
> from CSS 2.1, say MDN[3]. This seems to suggest that either Proposal B
> or C above is already not an option, but I am not sure.

I'd prefer to fail early as we currently do when non-integers aren't supported.

> The section of 'calc()' says
>  # It can be used wherever <length>, <frequency>, <angle>, <time>, or
>  # <number> values are allowed.
> It seems that <integer> is intentionally left out. Why? If the reason is
> "lack of use cases" then that applies to <number> too, I think.

Same as above - integer is defined as a subtype of number.

> == Other Questions Related to "Where can I use attr() and calc()?" ==
> Do we want attr() to be used inside @font-face, @viewport,
> @counter-style. If yes, the spec should mention that the "originating
> elmeent" in this case is the root element (or the context element for
> scoped style). If no becuase there's no strong use case, the spec should
> explicitly disallow this. The spec now says
>  # The attr() function returns the value of an attribute on the
>  # element for use as a value in a property.
> , which isn't very clear.
> Can attr() be used as a value for media query? My guess is no because
> there's no suitable definition of "originating element" (the root
> element is not the reference element for relative units).

Ooh, good point!  We do need to fix this.  I'm not sure how - I"ll
start a new thread.

> Can 'attr(<wqname> string)' be used as a value for 'font-family'? My
> guess is yes, but CSS 2.1 says <font-family> accepts "strings" instead
> of "<string>".

Don't pay too much attention to CSS 2.1's slightly more lax
descriptions of syntax.  When it says "strings" it means <string>.

The prose defines that <font-family> is either a <string> or a
sequence of <identifier>s, both of which are valid values that attr()
can represent, so yes, attr() can be used there.

> Can 'attr(<wqname> string)' be use in a '@import'
> statement? My guess is no but CSS 2.1 says it accepts "string" too.

We should probably explicitly disallow @import to take attr(), even if
we define some way for attr() to be used outside of a rule.

> Given that different modules refer to basic values types very
> differently (<font-famliy>, <alphavalue>), I think we should instead
> maintain a list of locations where attr() and calc() *cannot* be used:
>  * locations where the corresponding token(s) (NUMBER, DIMENSION, URI,
> FUNC STRING ')') are unexpected (attr(), calc())

This is already in the definition.  (Each has a resolved type, and is
only valid where that resolved type is valid.)

>  * @import, @namespace (attr())
>  * media query value (attr())
>  * keyframe selector (attr(), calc())

Yes, when we decide whether or not to allow attr() outside of a rule,
we'd need to decide exactly what accepts it.

calc() in keyframe selectors is... interesting.  I suspect we should
disallow it for simplicity, but I don't see anything in particular
*wrong* with it.  I'll start a thread about it.

>  * as an argument to calc() or cycle() (attr(), calc())
>  * as an argument to attr() (attr())‡

>  * as an argument to rgb() or rgba() (attr(), calc(). Does this make
> sense?)

There's no reason to disallow either of these.

> (This means that attr() and calc() can be used as a value of 'opacity',
> 'font-family', 'font-weight'[4], and relavant properties in @font-face,
> @viewport, @counter-style. attr() can be used in 'image()', 'url()')

The prose for opacity defines <alphavalue> to be a <number>, so that's
already fine.  (Though it should just be changed to actually say
<number>, because it's silly right now.

I've already addressed font-family - attr() is allowed.

font-weight accepts either 9 specific integers, or a few keywords.
attr() and calc() are both valid if they can provide these.

The relevant properties in @font-face, @viewport, and @counter-style
all accept calc(). Whether they accept attr() depends on how we
resolve attr() outside of rules.

attr() can definitely be used in image().

attr() can't be used in url() - "url(attr(foo))" parses as
"baduri1:url(attr LEFT-PAREN IDENT RIGHT-PAREN RIGH-PAREN".  We can't
ever use *anything* in url() because of the parsing rules.  url() is
*fucked up*.

> ‡ The spec says
>  # The fallback value must not be another ‘attr()’ expression; if it
>  # is, the outer ‘attr()’ expression is invalid.
> . I think it reads s/not be/not contain/,

Yup, you're right.  That should change.

> but I think this restriction
> is a bit odd given that 'cycle()' and 'calc()' are still allowed.

I kinda agree.  We'll revisit this decision.

I've logged all of the issues from email as LC comments.  I'll update
this or the relevant threads as we resolve them.

Received on Wednesday, 11 April 2012 17:37:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 12:35:07 UTC