Re: Some confusing bits and pieces...

2009/9/24 Emanuele D'Arrigo <manu3d@gmail.com>:
> 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

Better to look at http://dev.w3.org/csswg/css3-values (editor's draft)

> 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!

Seem to be correct now.

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

Seem to be changed, now the cascaded value is gone.

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

The initial value is a concept of the property (because you can have
"initial" everywhere in CSS3), you cannot implement it with default
stylesheets.

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

Initial is not default for default inherited properties (which get the
computed value of the parent)

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

Maybe this is the reason for the removal of the cascaded value in the
current draft.

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

In the current model, "initial" is a valid Specified Value, and is
converted appropriately when calculating the Computed Value. Resolved
values are not actually needed.

> 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:

The distinction may be just historical (the CSS2 REC merged Computed
and Used, and had separated Actual Values).
In principle it makes sense, since it allows to assume full sRGB,
infinite canvases, arbitrary fractions of units, etc. in the various
algorithm that deal with used values, leaving device specific limits
to the user agents.
For example, without the distinction it is impossible to describe the
width algorithm (CSS2 CR, 10.3) without special-casing text browsers,
PAL TVs, needle printers...

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

Uhm... "font-size-adjust" is an edge case, imo, because you need the
value of the x-height very early in the elaboration of property values
(you need it for resolving "ex" from Specified to Computed Values)...
On the other hand, you need platform information to find the adjusted
x-heigth, which you get only at the Actual Value phase.
An answer from the WG may definitely help

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

Giovanni

Received on Thursday, 24 September 2009 18:38:57 UTC