[CSS21] zindex.html issue: what are the elements, what descendents?

This may at first seem like a minor issue because it only makes a
difference in very rare cases, but from an implementation perspective it's
a major issue because the different possible resolutions affect core data
structures: so it might be expensive to change an implementation to match a
different possible resolution.  In other words, it's one of the issues that
more strongly affect whether the spec is ready to be implemented.


In order to implement zindex.html, one needs to know the list of
descendents, in "tree order", of a given "element generating a stacking
context" (and also I believe for "[non-positioned] floating descendants",
"inline-block and inline-table elements", and "positioned descendants", if
I've interpreted correctly).

Relatedly, one also needs to know the list of boxes, in tree order, that
are "a child of [a given element/descendent], in [a given] line box" (item
7.2.1), and a similar child relation in item 7.2.1.4.1.

Unfortunately the current spec doesn't give this information.
For example, "tree order" is defined in terms of the "rendering tree", but
that term isn't defined in CSS 2.1 (and indeed isn't mentioned outside of
zindex.html other than once in visuren.html#propdef-z-index).

Other than the ordering, there is conflicting information about what the
set of descendents of an "element" (in the zindex.html sense) should be;
for example there is conflicting information about whether source elements
that have been broken/split due to line breaking, bidi or section 9.2.1.1
should count as one element or several, and there are conflicting
indications of whether there's a separate "element" for :first-line and
:first-letter, and if so whether this can result in splitting source
elements into two different "elements" / "descendents" for purposes of
zindex.html.

(A related issue is whether :first-line / :first-letter can split what's
considered an "element" for chapters outside of zindex.html.  Note that
counters in particular are affected by how this question is answered; and
in particular note that we would presumably prefer that counters not get
incremented twice as a result of splitting.)

As usual, the answer may well be affected by our old friends run-in and
inside marker boxes.  (Less so anonymous table objects, because often
zindex.html only needs to know the sequence of descendents rather than
whether something's a sibling or a nephew, just so long as the two mentions
of "child" aren't affected.)


The following discussion from the mailing list is somewhat relevant, when
Anton Prowse queried the term "rendering tree" a couple of months ago:

On Sat, 28 Aug 2010, Tab Atkins Jr. wrote:
> On Sat, Aug 28, 2010 at 3:21 AM, Anton Prowse wrote:
> > Appendix E defines "tree order" to mean
> >
> >  # Preorder depth-first traversal of the rendering tree, in logical
> >  # (not visual) order for bidirectional content, after taking into
> >  # account properties that move boxes around such as the 'run-in'
> >  # value of 'display'.
> >
> > I was under the distinct impression that there is no guarantee that the
> > rendering structure is a tree.
> 
> In practice, it is.  There was discussion about this at the FtF which
> just took place; we really want to just bite the bullet and define the
> box-tree properly.  Without it, describing the behavior of a run-in is
> ridiculously circumspect, and the layout modules like Flexbox also
> affect the box-tree.
> 
> ~TJ


pjrm.

Received on Thursday, 4 November 2010 07:08:23 UTC