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

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.

~TJ

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