[css3-values] Remaining issues before LC

Fantasai and I spent today going through the Values spec again and
resolving what's left of the issues we'd tracked or that appeared in
the mailing list.  Right now, we have three issues for the WG's
consideration.  Once they are resolved, we expect to go to Last Call,
unless further issues are raised.  These issues are tracked in
Tracker: https://www.w3.org/Style/CSS/Tracker/products/8


ISSUE-173 Define required ranges for CSS
--------------------------------------------------------------

We've arbitrarily defined <integer>, <number>, and <percentage> to
require supporting up to +/- 2^30.  Is this reasonable?

For properties with repeated segments (such as shadows, bg layers,
etc.), we've arbitrarily defined a minimum of 30 repetitions.  Is this
reasonable?

Similarly, calc() has been defined to require supporting at least 30 terms.

We have no clue what to do with strings, user-defined identifiers, and urls.

Arron had an action item to do some testing and propose limits based
on this; we're still waiting for this.


ISSUE-195 Unit for ideographic advance
---------------------------------------------------------

Should we define an ideographic advance unit in level 3, or are we
going to wait for level 4?


ISSUE-204 attr() syntax
----------------------------------

The principle of comma usage in CSS value syntax is that commas
separate items in a list of parallel constructs. If we're going with
CSS argument syntax per radial-gradient(), the comma between the
attribute name and the type keyword in attr() thus should be dropped.
(We previously suggested dropping the comma and requiring "as <type>";
we no longer propose adding the "as" keyword as it's not necessary for
unambiguous parsing.)

This appears to be consistent with reasonable extensions that we could
think of: falling back to other attributes has to be done by nesting
attr(), because the fallback value itself may contain commas;
referring to an element other than the one the property is specified
on can be done with the element() function or similar.


Further feature suggestions, such as a cap-height unit or Bert's
suggestion for a random() function, we suggest deferring to level 4.

Thoughts?

~TJ and Fantasai

Received on Tuesday, 13 December 2011 01:12:20 UTC