W3C home > Mailing lists > Public > www-style@w3.org > July 2005

Re: [css3-values] New WD for Values & Units

From: Christoph Päper <christoph.paeper@tu-clausthal.de>
Date: Fri, 29 Jul 2005 19:08:57 +0200
Message-ID: <42EA62A9.6060009@tu-clausthal.de>
To: www-style@w3.org

3.1. Keywords

   Would it be useful to have a 'default' value (...)?

IMHO it would.

3.4.2. Relative length units

   unit 	relative to
   ...	...
   vw  	the viewport's width
   vh 	the viewport's height
   vm 	the viewport's height or width, whichever is smaller of the two

Wouldn't it be better, i.e. more flexible, to do the last one with 
functions, 'min()' (and additionally 'max()')? That means, "50vm" would 
become "min(50vw, 50vh)". That's probably a little less performant on 
viewport resize, though.
I'm not sure whether the viewport width and height should be 100, like 
currently defined in the WD, or 1.0.


The values and units in text and illustration mismatch in part, e.g. 1.3 
mm vs. 1.4 mm and 12 ft. vs. 140 in. Although in CSS units directly 
follow the values, in prose there should always be a (non-breaking) 
space between them, except when it's sample CSS code of course.

Could 'px' be defined as an actual angular value with a safe margin?
For example 375 µrad ± 50 µrad or 1.3' ± 0.1'.

Actually I think it would have been a valid option to make 'px' the 
device's pixel, like many people assume anyway, and instead allow 
angular units for relative lengths, representing the visual angle of the 
user. For example:

   small {font-size: 0.20deg/* 12', ~9.4px @ 96 dpi, better more */}
   p     {font-size: 0.25deg/* 15', ~11.75px, better more */;
          line-height: 0.30deg/* 18', 1.2em, ~14px, better more */;
          max-width: 20deg/* ~940px, better 18deg (~845px) or less */}

Sure, that's nothing webdesigners are used to, but actually the most 
appropriate way to do it, although the UA has to know or guess viewing 
distance and display size.


 From the current Text module draft:
   Sections relating to text layout (vertical text, grids,
   'text-combine') will be moved to a separate Text Layout module.

This Values and Units module draft still references "CSS3 Text module 
[CSS3TEXT]", which links to an superceded draft which included text 
layout. I'm not sure this is acceptable.

3.4.3. Absolute length units

I don't think it's that important, but if CSS is intended to be used in 
professional printing, it should perhaps support other points as well 
(Didot, PostScript, metric). Of course it would then have to introduce 
'cmyk()' etc. into the Color module, too.

3.4.4. Percentages

The example explains that percentages are not inherited, but the 
computed value is. Shouldn't that be in the prose?

3.4.5. Angles

   Angle values (...) are used with aural cascading style sheets.

That may be the case now, but it sounds as if they only ever could be 
used with aural properties (see above). Times and Frequencies also have 
this unnecessary restriction, where the latter may be used for more than 

   Angle values should be normalized to the range 0-360deg (...)

"360deg" being clipped to "0deg", of course. IMHO this should be worded 
independent of the value, using degrees as an example.
Not that you could change it now, but why is it 'grad', not 'gon'?
Without a "pi" constant 'rad' is pretty much useless, a unit 'pirad' or 
'pi' might not.

3.7. Functional notation

   The functional notation is used to denote colors, attributes and
   URIs in CSS3.

What about counters (and calculations)?

3.7.1. The 'attr' function

Do I understand correctly, that it's not possible to parse

   <foo red="0" green="127" blue="255"/>

into a CSS color ("rgb(0, 127, 255)")? Or would

   rgb(attr("red", integer, 0),
       attr("green", integer, 0),
       attr("blue", integer, 0))

work? If not, should it? If the ML allowed alternative attribute values 
(hexadecimal, percentage, zero to one floats, keywords or something 
else) 'attr()' would be screwed anyway, except when 'rgb()' etc. 
accepted their parameters in strings (like 'url()' does), or if there 
was a 'raw' attribute type. Then it fails, when the ML uses a different 
notation than RGB(A) and HSL(A).

I think the example

   color: attr(color); /* 'color' doesn't accept strings */

strongly supports the note

   Ideally, it shouldn't be necessary to specify the type
   if it is obvious.

I would also answer the question

   Should there also be a "keyword" type (...)

with a yes.

   The attr() expression cannot return everything, (...). This is
   intentional, as the intent of the 'attr()' expression is not to
   make it possible to describe a presentational language's formatting
   using CSS, but to enable CSS to take semantic data into account.

That sounds like a reasonable idea, but it seems just like an excuse, 
because several of the things it can do are only meaningful with 
presentational markup. (It answers my question regarding colors, 
though.) 'attr()' does support some of HTML's rightfully deprecated 
attributes, but the 'start' and 'value' attributes in ordered 
lists---deprecated, too, but that was a questionable decision---are not 

3.7.3. The 'counter' function

   p:before { content: counter(par-num, upper-roman) ". " }

There should be a two colons before "before".

3.7.4. The 'calc' function

   Should we introduce mathematical expressions to calculate values?

I think the majority of webdesigners would say yes. I'm undecided. I'm 
also not sure whether a generic 'calc()' or distinctive 'add()', 
'sub()', 'mul()', 'div()', 'mod()', 'pow()' etc. functions were preferable.

3.8.2. Colors

Hexadecimal colors wouldn't be a special case, if all integers could be 
hexadecimal ... No, I'm not really suggesting that. Think about it, 
"#07F" = "#0077FF" -> "127" = "30719"!

	Christoph Päper
Received on Friday, 29 July 2005 17:09:04 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:19 UTC