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

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 likely not desirable for two reasons:

1. Some <integer>-like properties actually accept <number>. This
includes 'flex-order' and 'animation-iteration-count'. Authors might be
surprised to see 'flex-order: attr(order integer);' fail to work, for
example.

2. We might extend 'z-index' to accept <number>[1] in the future, but
that shouldn't break 'z-index: attr(z integer)'

Alternative Proposal: We maintain a list of properties that are
<integer>-like but accept <number> and treat them as if they also accept
<integer>. 'line-height', for example, probably doesn't belong to this
category (not sure how fragile this proposal is).


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.


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.


== 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).

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

...


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())
  * @import, @namespace (attr())
  * media query value (attr())
  * keyframe selector (attr(), calc())
  * 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?)
  (To be completed.)

(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 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/, but I think this restriction
is a bit odd given that 'cycle()' and 'calc()' are still allowed.

[1] http://lists.w3.org/Archives/Public/www-style/2011Oct/0850
[2] http://www.w3schools.com/cssref/pr_pos_z-index.asp
[3] https://developer.mozilla.org/en/CSS/z-index
[4] (I fully agree that this is a boring edge case, but the specs should
give a clear 'true' or 'false' answer to the "can calc() and attr() be
used as a value of 'font-weight'?" question. See [5].)
[5] http://lists.w3.org/Archives/Public/www-style/2012Apr/0011



Cheers,
Kenny

Received on Wednesday, 11 April 2012 12:37:21 UTC