[css3-values] Unit normalization and types

A few days ago there was a thread about normalization of angle values.
Some more ago there was a thread about grid positioning.
Here I collected some questions that may need answers in the
css3-values module, plus some ideas that I got while typing.

== Unit Normalization and Absolute Units ==

=== Length ===
Some CSS modules says that the Computed Value for a length is the
absolute version.
According to the current text, the only absolute units are cm, mm, pt,
in and pc.
Does this means that px units are converted to cm (or in if the
developer is British) in the Computed Values, then back to px in the
Actual Values?
What absolute unit should be chosen?
What is the meaning of converting px to cm, considering that the UA
has probably no knowlegde about the diagonal of my monitor?

=== Angle ===
Should turn, rad, deg, grad all be computed to the same unit? Or
instead they give different Computed Values (but maybe the same Used /
Actual Value)?
This is important for example for transitions: either turn and rad
compute to the same unit (that then is interpolated) or they're opaque
until Used Value phase and thus don't get the transition applied.
Should the trim 0 - 360deg be done in the Actual Value, as it is done
for length?

=== Color ===
(I know, this belongs to a different module, but the topic is the same)

What phase should colours be normalized to the same vector (RGBA or
HSLA)? Computed, Used or Actual Value?
The same notices for Angles apply: since we transition on the Computed
Value, if begin and end are specified in different forms and not
normalized, they cannot be interpolated.
In addition, should we have two clipping of the value, one in the
Computed Value (rgb(256,0,0) => rgb(1,0,0)) and one in the Actual
Value (for colours not support by the output device)?

=== Time and Frequency ===
If we decide that all units should be normalized to the same unit in
the Computed Value (all lenghts to cm, all angles to rad, all colors
to rgb()...), we would need to change also Times and Frequencies

=== URIs ===
Are URIs / IRIs checked for comformance when parsing? Do we follow the
Web Addresses standard?
Why do you still reference RFC1738 and RFC1808 instead of the newer ones?
The computed value for url is the relative or absolute URI?
This means: element with inherited urls from style sheets in different
directories get different used values?

== Value types ==

=== Grid ===
Are <grid> units lengths? Do we want to allow them everywhere a length
is accepted?
Else, css3-grid will need to redefine width / heigth / top / bottom /
left / top / border-*-width / margin / padding or any other property
they wish to apply a grid relative unit.
In addition, what is the computed value for a grid unit?
Should this be left to the relevant property using <grid>?
Should this be defined in css3-grid?

=== Fractions ===
Same question as above: are fractions lengths? Do we want to allow
them everywhere a maximum size is expected by the property or we need
a property expansion to accept "fr"?
The css3-grid module uses the * (asterisk) syntax for flexible
lengths: why don't you use "fr" there?

=== Calc ===
Why do you define <atomic-length> as number followed by unit
identifier? This does not allow percentages.
Can "attr" be nested inside "calc"?
Can "gr" and "fr" units (in properties that accepts such units) be
used inside calc?
Why do you need explicit spaces between "+" / "-" and lengths?
Can't you insted write
<length-additive-expression> := [<length-additive-expression> S*]*
<length-multiplicative-expression>
Here I just removed the + / -, to rely on the sign present on length.
Then you need:
<length-term> := [ '+' | '-' ] ‘(’ <length-expression> ‘)’ | <atomic-length>

This would allow calc(1em2px) but I don't think this is a problem: you
can either
- make this mean calc(1em+2px) and stop
- make this mean calc(1em+2px) but say it is not comforming (reported
by a validator)
- make this parse as calc(1em+2px) but then reject the declaration
because the sign is not explicit (first parse, then check)

=== Attr ===
Can "calc" be used as a default value for length "attr"?
"attr" is a valid value of any type: why can't I use it as a default
value for another "attr"?
Can "attr" return grid or fraction units, on properties that accept them?
Can "attr" return shapes (something like attr(coords,path) in
<xhtml:area>) or transformations (to implement SVG presentational
attributes using CSS properties)?
Is it possible to have an "attr" functional notation to return an
arbitrary css value (parsed as if explicitly present in the property
declaration)?
Values outside the relevant range should be ignored (defaulted) or clipped?
Does the above applies also to length (which is normally clipped
instead of being ignored)?

=== String ===
css3-gcpm (and css3-content) define a string() functional notation for
named strings. Should we move it to css3-values and extend all
<string>s to accept named strings?

=== Other types ===
I was sure there was a section about counters (and maybe others). Why
was it removed?

====

I hope that it's all. It sounds much like Last Call comments, but I
strongly feel that we cannot move forward with other CSS3 modules
unless we have a stable Values and Units module: all the other depend
on this. I also believe it should be moved to high priority in the
current-work page.

Giovanni

Received on Wednesday, 25 March 2009 18:26:37 UTC