RE: Draw order. Algorithm

[Ruslan Fayzrakhmanov:] 

Ruslan, it's important to understand that the algorithm specified
in Appendix E is recursive. Describing it as a serial sequence
is hard. Asserting whether someone's interpretation of the algorithm
is correct is also difficult so I'll stick to those parts where you
have explicit questions.

>As I understand about drawing order for current SC: 
>• we draw current element that creates a new Stacking Context (SC). 
>It can be root element (1). If the element is a block, list-item >or 
>table (2), we draw them in appropriate to their type way.
>• (3) After that we draw all its Stacking Contexts (SCs), which has z-index<0. 
>The sequence of the SCs is ordered according their z->index (in ascending order) 
>and their "tree order".
>• (4) We draw all non-positioned block-level descendant (from normal flow = in-flow) 
>of current element (curr. element creates new SC). >All these elements should belong 
>to the current SC. If the block-level is a table, we draw it as a table.

>• (5) We draw all floats which are non-positioned and with opacity=1. All it's descendant 
>elements which do not create a new SC >belongs to this element. All it's nearest descendant 
>elements which create new SC belongs to the current SC.

Not sure what you mean by 'belongs to this element'. If you mean to say they belong to the float's
painting order then yes. You're right that there is here an ambiguity i.e. a non-positioned that
also creates a new stacking context e.g. through opacity. In that case the float's painting order
is the same but now its descendants are no longer part of the parent stacking context

>• (6) all in-line elements which generate new SC. Is it elements with opacity<1? How to get 
>this elements?

Just like a non-inline element: positioning with non-auto z-index, or opacity.

>• (7) What do we draw?

This section deals with the major difference between inline elements and block elements: they can wrap. So 6.1. says that for each line box the element draws into, go through its boxes in tree order (6.1.1) and treat each according to 7.2.1. The latter enumerates the painting order from background color all the way through text runs and nested inline elements.

>• (8) We draw all positioned elements with z-index="auto" or 0 as well as all elements with 
>opacity<1. Positioned element with z-index=auto and opacity=1 does not create new SC. All it's 
>descendant elements which do not create a new SC >belongs to this element. All it's nearest 
>descendant elements which create new SC belongs to the current SC.
>• (9) All positioned elements with z-index>0
>• (10) We draw outlines for the elements which do not have them yet.

>I do not inderstand the steps 6 and 7. Could you please explain them? Especially, 
sub-steps in 7.2.1.4.1.1.

The latter simply defines the painting order for a run of text: underline/overline, then text, then line-through.

>I also do not know these concepts: "block equivalent element", 

Those would be elements that may be treated as block based on context e.g. run-in, as well as display types that behave externally as a block such as display:table. Also, keep in mind those elements for which display computes to block per 9.7 e.g. if an element is display:inline is also given position:absolute then display for the element computes to block. 

>"block-level replaced element", 
A replaced element with display:block. 

>"underlining"/"deepest element's underlining".
As in text underlining i.e. using text-decoration:underline ?

>About SC. As I understand:
>• all SC can be represented as a tree. When we draw we have a 
>depth-first traversal through this tree.
>• Elements which are * either positioned with z-index<>auto or 
>* have opacity<1 form a new SC.

Note that other properties may create a new stacking context; for instance,
the transform property when not set to none.
--
The best regards
  Ruslan

Received on Monday, 7 March 2011 22:42:34 UTC