W3C home > Mailing lists > Public > www-style@w3.org > November 2010

[CSS21] zindex.html E.2 issue: ordering contradictions

From: Peter Moulder <peter.moulder@monash.edu>
Date: Fri, 05 Nov 2010 14:28:55 +1100
To: www-style@w3.org
Message-id: <20101105032855.GA24538@bowman.infotech.monash.edu.au>
[Please let me know if there's a preferred convention for subject lines
 when reporting issues in either editors' draft or last call versions of
 the CSS2.1 specification, other than including the string "[CSS21]".]

This is a review comment for the Editors' Draft of CSS2.1
as published Oct 2010 (and is equally applicable to
http://www.w3.org/TR/CSS21/zindex.html as visible at that date).


If I understand correctly, zindex.html as currently written includes some
items (say the background image of element X) more than once: various
places in the list include "all [qualifier] descendents [of E]", which
typically includes descendents of some different E that's also included in
the painting order.

This would constitute an issue because double inclusion in the painting
order entails conflicts of the form "A precedes B, which precedes A".  
(Alternatively, if each item in the painting order were to be interpreted
 as "paint this", then instead of a contradiction, we get double painting.
 Apart from imposing unnecessary performance cost on those implementations
 that adhere to this interpretation, I believe that this will in some cases
 result in different appearance compared to implementations that render
 only once.  (For example, I would expect that it can affect the appearance
 if a background image is in a format such as png that allows partial
 opacity.))

For example, item 5 with respect to the root element consists of
"[a]ll non-positioned floating descendants, in tree order", followed by a
sentence which (by my understanding) explains that inclusion of a floating
descendant should be considered equivalent to expanding this big list with
respect to that floating descendant, but excluding [the expanded painting
order of] "any positioned descendants and descendants which actually create
a new stacking context".

One issue is that it isn't clear that that is what the text means; while
the other is that (under this interpretation) it doesn't exclude inline
blocks or non-positioned floating descendants, so non-positioned floating
descendants of those inline blocks or non-positioned floating descendants
would be included first in item 5 with respect to that inline block or
floating descendant, and then included again in item 5 with respect to the
root element.

(Possibly the intended meaning of "descendants" is such that it doesn't
 include any inline blocks or non-positioned floating "elements", but that
 interpretation would seem to make item 5 equivalent to an empty list.)


Some issues are:

  - It is unclear what inclusion of an element in the painting order means.
    The most obvious guess would be that it means to expand the big list
    with respect to that element, but the specification doesn't actually
    say this, so any contradictions found in that interpretation lead one
    to explore other interpretations.

    Part of the problem is that the list only provides an ordering among
    the descendants of a given element, and there's room for doubt as to
    whether all named descendant painting items of element A must precede
    all named descenant painting items of element B if element A precedes
    element B in the list: "treat elements A & B as if they created a new
    stacking context" isn't enough to say that inclusion of "element A"
    in the list is equivalent to the painting items that are mentioned
    in this ordering; it might be read as merely giving the ordering among
    any painting items that are included as part of "element A".
    And indeed in some sense it's quite deliberate that there's no
    specification of what painting items to include as part of 
    a given element, because the spec is trying to allow UAs to paint
    e.g. outside markers even though they're not listed in the painting
    order of an element.

    To counter this, I suggest slightly tightening the description of the
    list as an "order" (which doesn't necessarily imply that any of the items
    in the ordering are actually part of painting the element, it only
    gives an ordering among whatever of those items are done),
    to introducing the concept of the "painting sequence" for an element,
    and say that the list forms a subsequence of the painting sequence for
    the element, and explicitly mentioning that it's a subsequence because
    it excludes outside list markers and optionally outlines.

    I tentatively suggest wording it in such a way that the full sequence
    can only be formed by inserting outside list markers and outlines (and
    any other CSS2.1 item not in the existing list); i.e. I tentatively
    suggest that it be made non-conformant for a UA to paint other things
    as well.  I believe that something like that is required for the test
    suite to be correct: there's no way to test visibility:hidden if
    conforming UAs are allowed to render things other than what CSS directs
    them to render, such as something looking exactly like the thing that
    should be hidden.

  - "Treat X as if it created a new stacking context" is unclear.
    However, if the above suggestion is adopted, and if the big list
    is just described as a subsequence of the painting sequence of an
    element E without requiring that E establish a stacking context,
    then we can instead word the list in terms of the painting sequence
    of X.

  - Without having tested what implementations do, I suggest that
    the painting sequence of elements that do not establish a stacking
    context should exclude all descendants that are floats, inline blocks
    (including those generated by display:inline-table), and positioned
    elements, and descendants of those.

    One way of doing this is to talk of "the painting sequence for an
    element E", and then within that list say "if E does not establish a
    stacking context" for each time that it includes the painting sequence
    of an element.
  

pjrm.
Received on Friday, 5 November 2010 03:29:28 GMT

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