W3C home > Mailing lists > Public > www-style@w3.org > March 2011

Re: [CSS21] Issue 60 Edit Validation

From: Anton Prowse <prowse@moonhenge.net>
Date: Mon, 14 Mar 2011 20:35:46 +0100
Message-ID: <4D7E6E12.6090600@moonhenge.net>
To: "www-style@w3.org" <www-style@w3.org>
CC: Bert Bos <bert@w3.org>
On 04/03/2011 21:30, Bert Bos wrote:
> On Monday 14 February 2011 20:44:22 Anton Prowse wrote:
>> On 11/02/2011 02:20, fantasai wrote:
>
>>> === Mismatch A ===

>> 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.
>
> The text may not define "child stacking context" directly, but it does
> define "parent stacking context" and if there is a parent, there must a
> child, isn't it? That's why I felt "child" more natural than your
> "dependant."

Well, it doesn't so much define it as use it ;-)

> But it is easy enough to define "child" (or dependant) explicitly, if
> you think that helps. I'd put it after "Stacking contexts can contain
> further stacking contexts."

I'd really like to see this defined explicitly, or at least have it 
explicitly stated that there is a tree of stacking contexts (in which 
case the terms 'parent' and 'child' don't really need defining).


>>> === Mismatch B ===

>>> This is most definitely an error. As Anton points out, it's a
>>> regression of Issue 60a.

> I added "non-positioned" back.

Great, thanks!


>>> === 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.
>
> Sometimes introducing an indirection can make things clearer, but in
> this case "stack level 0" is confusing: it is equivalent to 'z-index:
> auto' and is different from 'z-index: 0'. Nevertheless, I've replaced
> "'z-index: auto'" with "stack level 0."

Thanks for removing the reference to z-index.  (I disagree that "stack 
level 0" is equivalent to one value of z-index and not the other; 
rather, it purposefully doesn't distinguish between the two values, 
which is precisely why it's more appropriate for use in the list.  In 
future levels of CSS, even more things might be at stack level 0, and we 
want the list to be usefully forwards-compatible with them.)


>>> === Mismatch E ===

>> 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.
>
> I added the three insertions.

Great, thanks!


Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Monday, 14 March 2011 19:36:21 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:38 GMT