Some confusing bits and pieces...

Greetings everybody, my name is Manu, typing from the UK.

I am working with various specification documents to create a CSS
implementation in a non-browser context. Many things are quite clear and in
general, albeit the complexity (and power) of CSS can be quite overwhelming,
I'm finding my way around and I seem to understand most of the described
concepts pretty easily.

In the interest of offering a modest contribution to the effort and helping
improve the specifications where I possibly could, I thought I'd mention a
few things that did confuse me.

I'm currently looking at the document CSS3 Values and Units:
http://www.w3.org/TR/css3-values/#specified0

1) Right in the opening paragraph of section 4 there seems to be something
missing between the words "then the and finally". It looks like an entire
sentence on the concept of Used Value is missing!

2) The same opening paragraph asserts "The final value of a CSS3 property
for a given element is the result of a four-step calculation" however, with
the introduction of the term "Cascaded Values" at a first glance it now
seems to be a 5-step calculation. Of course it is reasonable to consider it
a four-step "calculation". After all only the steps from specified to actual
are largely mathematical in nature and hence the use of the term
"calculation" can be restricted to those. I would argue however that
all-else-being-equal the wording "The final value of a CSS3 property for a
given element is the result of a *five*-step *process*", would include
properly the cascade -and- any underlying non-mathematical computations
involved (i.e. the conversion of a relative URL into an absolute one).

3) In section 4.1 the sentence "When there is no winning declaration, there
is no cascaded value" allows a null output as the result of the cascade. I
find this confusing. Conceptually my understanding is that all properties
have an initial value stored somewhere in the User Agent. Somehow the
various specification distinguish between initial values left to the User
Agent and initial values specified by the specifications. I can't see
however why an implementation would want to store both types of initial
values in anything but the User Agent's stylesheet. And as the UA stylesheet
is considered by the cascade I can't see how it can ever return a null
result. Can somebody shed some light?

3b) Why isn't the "initial value" called the "default value"? It is after
all the value to use if all else fails!

4) -IF- the reasoning in point 3 is valid I would argue that the result of
the cascade is in fact -the- "specified value" rather than the "cascaded
value". This is because the result of the cascade would -always- be a value
that has been -specified- in a stylesheet somewhere, be it the UA's, the
author's or the user's.

5) -IF- the reasoning in point 3 and 4 is valid I would then suggest for
paragraph 4.2 "Specified values" to be renamed to "Resolved values", as the
output of this step is either an "inherit" or an "initial" value converted
into a value useful to the computation step. In this context the text for
paragraph 4.2 could become:

"If the specified value is anything but 'inherit' or 'initial' no processing
is needed and the resolved value is identical to the the specified value.
See example (a) in the table below. If the specified value is 'inherit' or
'initial', the resolved value contains the inherited and initial value,
respectively. See example (d) and (e) in the table below."

Notice that this would require the addition of a column in the table,
"resolved value", and would render the "winning declaration" column
partially redundant with the new content of the "specified value" column.

6) The distinction between Used and Actual values makes me somewhat uneasy.
To get from computed values to used values it seems to me that some
potentially intensive computations are needed. Why then not go all the way
and wrap the various example in both the Used and Actual values section into
one? It might be just a matter of taste but it seems to me the two sections
could be merged in "Actual values" and read as follow:

"Computed values are processed as far as possible without formatting the
document and without consideration for the given execution environment. Some
values, however, can only be determined when the document is being laid out
or must take in account the hardware in use. For example, if the width of an
element is set to be a certain percentage of its containing block, the width
cannot be determine until the width of the containing block has been
determined. Alternatively, a user agent may only be able to render borders
with integer pixel widths and may therefore have to approximate the computed
width. Also, the font size of an element may need adjustment based on the
availability of fonts or the value of the 'font-size-adjust' property. The
actual value is the result of taking the computed value and resolving any
remaining dependencies into an absolute value.

By probing the actual values of elements, much can be learned about how the
document is laid out. However, not all information is recorded in the actual
values. For example, the actual value of the 'page-break-after' property
does not reflect whether there is a page break or not after the element.
Similarly, the actual value of 'orphans' does not reflect how many orphan
lines there is in a certain element. See examples (j) and (k) in the table
below."
6b) I'm not quite sure about the example for the 'font-size-adjust'
property, but if Used and Actual are merged as I suggest there could be a
case for removing the example.

Apologies if some of these issues have been discussed before. Feel free to
remind me to the appropriate messages in the archive should this be the
case. Still, I hope this helps. What do you all think?

Manu