Re: [css3-values] Unit normalization and types

On 03/25/2009 11:26 AM, Giovanni Campagna wrote:
> 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?

Given that, at this point, 'px' and the absolute units are defined to
map to each other, this isn't an issue. But also, see David Woolley's
response http://lists.w3.org/Archives/Public/www-style/2009Mar/0385.html

> === 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?

We've taken out the normalization to the 0-360deg range, since that
obviously causes problems for transitions. Normalizing the angle
units to each other doesn't really cause a problem, though; they're
all equivalent. It only makes a difference for serialization of
computed values.

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

This is defined by the Transitions module:
   http://dev.w3.org/csswg/css3-transitions/#animation-of-property-types-

> === URIs ===
> Are URIs / IRIs checked for comformance when parsing?

No.

> Do we follow the Web Addresses standard?

In what sense?

> Why do you still reference RFC1738 and RFC1808 instead of the newer ones?

We've updated the text on URLs. Take a look and let us know if there
remain any issues?
   http://dev.w3.org/csswg/css3-values/#urls

> The computed value for url is the relative or absolute URI?

The absolute URI.

> == 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?

I'm of the opinion 'grid' and 'fr' should be defined where (if) they
are used...

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

This section has been rewritten since your comments. Let me know if
you see any remaining issues.

> === Attr ===
> Can "calc" be used as a default value for length "attr"?

Yes.

> "attr" is a valid value of any type: why can't I use it as a default
> value for another "attr"?

Probably because we don't have a good use case. :) It's extra work
to implement and test, so there'd need to be a use case.

> Can "attr" return grid or fraction units, on properties that accept them?

Not currently (except via the default argument)

> Can "attr" return shapes (something like attr(coords,path) in
> <xhtml:area>) or transformations (to implement SVG presentational
> attributes using CSS properties)?

No.

> Is it possible to have an "attr" functional notation to return an
> arbitrary css value (parsed as if explicitly present in the property
> declaration)?

Yes.

> Values outside the relevant range should be ignored (defaulted) or clipped?

Clamped.

> Does the above applies also to length (which is normally clipped
> instead of being ignored)?

Yes, it is also clamped.

> === 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?

I don't think that would be particularly useful. What would you use it for?

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

I'm not sure, but I think counter notations should be defined in css3-content,
as that's where they're used.

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

Tab and I are moving it up in our queues. :) We've revamped much of
the spec, let us know if you find any more issues.
   http://dev.w3.org/csswg/css3-values/

~fantasai

Received on Tuesday, 11 October 2011 01:09:59 UTC