Re: [CSS21] Issue 60 Edit Validation

On 11/02/2011 02:20, fantasai wrote:
> There were too many mismatches in the edits for Issue 60 for me to put
> them all in
> the issues list, so I am sending a separate email.
>
> I would like Anton and Sylvain to review these mismatches and evaluate
> which changes
> are editorially equivalent or superior, and which are real problems.

The bulk of these mismatches stem from Bert's desire to view the list of 
painting layers as forming the components of the "current" stacking 
context which itself forms part of an assumed, referenced, but undefined 
"tree of stacking contexts".

This is editorial equivalent to the old approach in which the list of 
painting layers formed the components of the (unstated) closest ancestor 
stacking context, without implicit reference to a tree of stacking 
contexts.  (Sylvain's and my proposed wording is faithful to the old 
approach.)

Note that such a tree does exist, if one believes that a box tree 
exists.  However, I prefer the old approach if the tree is to go 
unstated.  Moreover, the new approach gives rise to dodgy wording (see 
Mismatch E, below) which needs fixing IMO.  However, the choice of 
approach is a purely editorial decision; both are technically valid.


> === Mismatch A ===
>
> The proposal specified:
> | 2. the stacking contexts of descendants with negative stack levels (most
> | negative first).
> The current spec reads:
> % 2. the child stacking contexts with negative stack levels (most negative
> % first).
>
> The change is from
> stacking contexts of descendants
> to
> child stacking contexts
>
> I am unsure whether this is a problem.
>
> The same change is present in mismatches C and D.

Here, "child" is used with respect to the tree of stacking contexts.  In 
some ways it's less sloppy than the proposed/old wording ("descendants", 
when what was really meant was "dependants" as defined in [1]; my 
proposal to fix that was rejected).  However, given that the tree goes 
unstated, I think that the new wording is still not crystal clear.


> === Mismatch B ===
>
> The proposal specified:
> | 4. non-positioned floats.
> The current spec reads:
> % 4. the floating descendants.
>
> This is most definitely an error. As Anton points out, it's a regression of
> Issue 60a.
> http://lists.w3.org/Archives/Public/www-style/2010Jul/0077.html
> http://wiki.csswg.org/spec/css2.1#issue-60a
>
> This error is also present in Mismatch E.

Agreed.


> === Mismatch C ===
>
> The proposal specified:
> | 6. positioned descendants and stacking contexts with stack level '0'.
> The current spec reads:
> % 6. the child stacking contexts with stack level 0, and the positioned
> % descendants with 'z-index: auto'.
>
> This change exhibits change A.

As above.

> It also replaces
> with stack level 0
> with
> with 'z-index: auto'
> in the case of positioned descendants

This is a purely editorial decision.  However, I prefer our proposed 
wording (assuming the addition of the word "child" in line with the new 
approach).  The raw 'z-index' property translates to the friendly "stack 
level" concept, and I see no need to re-introduce z-index into the list 
of painting layers, when the stack level concept can be used instead. 
There is value is separating the model from the delivery mechanism. Note 
that descendants (actually, dependants) with stack level 0 are precisely 
the stacking contexts with stack level 0 and the positioned descendants 
(dependants), and so the proposed sentence was correct and more concise.


> === Mismatch D ===
>
> The proposal specified:
> | 7. the stacking contexts of descendants with positive stack
> | levels (least positive first).
> The current spec reads:
> % 7. the child stacking contexts with positive stack levels (least
> % positive first).
>
> This is an instance of change A.

As above.


> === Mismatch E ===
>
> The proposal specified:
> | The contents of positioned elements with 'z-index: auto',
> | non-positioned floats, inline blocks and inline tables are
> | stacked as if they generated new stacking contexts, except that
> | any positioned elements and any elements that actually create
> | new stacking contexts take part in the parent stacking context.
> The current spec reads:
> % Positioned elements with 'z-index: auto' (in layer 6),
> % floats (layer 4), inline blocks (layer 5), and inline tables
> % (layer 5), are painted as if those elements generated new
> % stacking contexts, except that their positioned descendants
> % and any child stacking contexts take part in the current
> % stacking context.
>
> This mismatch exhibits several changes:
>
> 1. The change from
> non-positioned floats
> to
> floats (layer 4)
> is error B.
>
> This is definitely wrong.

Agreed.

> 2. The verb has been changed from
> stacked
> to
> painted
>
> I am unsure whether this is a problem.

This reflects the difference between the two different approaches.  Our 
proposed wording is identical to the old spec as concerns this issue, 
and what it is saying is:

The contents of <some types of element> are stacked [composited] as if 
they [the <some types of element>] generated new stacking contexts, 
except <conditions>.

Bert's new wording says:

<some types of element> are painted [their painting layers (ie contents) 
are composited] as if those elements generated new stacking contexts, 
except <conditions>

The new wording is clearer IMO, since "they" was ambiguous in the old 
wording.  (My original proposal to clarify that word was rejected.)

> 3. The last phrase
> parent stacking context
> has been changed to
> current stacking context

See above; in the old approach, "parent" stacking context really meant 
closest ancestor stacking context and the elements being discussed in 
this paragraph were not being viewed as belonging to a "current" 
stacking context; rather, the viewpoint was external to the tree.

In the new approach, we're assuming that the action is taking place 
inside the "current" stacking context.  Hence the new wording makes 
sense in the context of the new approach.  However, the new wording of 
the paragraph lacks a certain clarity to that effect.

> 4. The subject of the sentence is changed from
> The contents of positioned elements
> to
> Positioned elements
>
> I'm unsure whether this is a problem or not. Not that the subject in the
> proposal does not include the backgrounds of the element in question,
> whereas the current phrasing does.

See my response to point 2.  Backgrounds were in fact taken account of 
in the old wording, but the sentence was not very clear.

> (I have to say, the removal of this sentence from the original spec:
> # They are then painted atomically in the inline stacking level.
> makes this paragraph very, very confusing. Would have preferred a
> correction.)

But that sentence is no longer accurate under either our proposal or 
Bert's new wording, since the paragraph is no longer concerned with just 
inline-level items (non-positioned inline blocks and non-positioned 
inline tables) but rather all items which form "pseudo–stacking 
contexts" including non-positioned floats and positioned elements with 
'z-index: auto'.

Instead, I think the confusion with the new paragraph lies in its use of 
the phrase "child stacking contexts":

5. The last clause contains a change from
any elements that actually create new stacking contexts
to
any child stacking contexts

"child stacking contexts" is very misleading here; it's talking about 
closest descendant stacking contexts of <some types of element> but of 
course the <some types of element> don't actually form stacking 
contexts; they form pseudo–stacking contexts (which is of course the 
whole point of the paragraph).  Hence these latter elements don't form 
part of the stacking context tree, and hence it's pretty much incorrect 
to talk about their "child" stacking contexts.  Indeed, what the 
paragraph is trying to say is that these supposed "child" stacking 
contexts are children of the current stacking context [in the stacking 
context tree], and do not belong to the intervening "pseudo–stacking 
contexts".  In other words, the paragraph is implicitly trying to 
reinforce the idea that "pseudo–stacking contexts" do not feature in the 
stacking context tree.

I strongly feel that if Bert's approach is to be used then the stacking 
context tree needs to be made explicit, and that the misleading 
paragraph needs to be clarified.  The latter might be achieved as follows:

   | <ins>Within each stacking context, </ins>positioned elements with
   | 'z-index: auto' (in layer 6), floats (layer 4), inline blocks
   | (layer 5), and inline tables (layer 5), are painted as if those
   | elements <ins>themselves</ins> generated new stacking contexts,
   | except that their positioned descendants and any <ins>would-
   | be</ins> child stacking contexts take part in the current stacking
   | context.

If those changes were to be made, I think I would prefer Bert's approach.

Either way, there's still some editorial work needed here.

[1] http://dev.moonhenge.net/css21/spec/z-index/#descendant

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Monday, 14 February 2011 19:45:00 UTC