Re: SVG 1.2 Comment: Detailed last call comments (all chapters)

At 08:45 AM 10/31/2004 +0000, Ian Hickson wrote:
> > 11.16.1 The overlay property
>
>This property name is very generic and is likely to clash with CSS
>properties added in the future. To avoid this, I would recommend using
>a more specific name such as 'graphic-element-overlay'.

I think that the correct way of doing this would be for CSS group to 
develop a naming scheme for properties and get it reviewed by other groups 
or somehow have namespaced properties to avoid conflicts. I agree that 
current lack of naming conventions can cause potential problems, but on the 
other hand I do not see any reason to rename this property. We have fill, 
stroke, filter, etc., why suddenly we cannot have overlay?

>However, the 'z-index' property may be of more use. It could be
>defined for SVG elements such that 'z-index: auto' on an SVG graphic
>element causes the element to be rendered as per normal, but an
>integer value causes the element to be rendered to a separate canvas
>with that number, with all the canvases then composited onto the
>normal canvas from lowest number to highest number (with negative
>numbers below the main canvas). Elements with non-'auto' values or
>'z-index' which themselves have child graphic elements would
>themselves be handled in the same way, creating a new "normal" canvas
>and a new stack of "other" canvases onto which the children are
>painted, which would then be composited all together before being
>composited into the parent's main background.
>
>This would be compatible with CSS2.1's 'z-index' property.

We certainly discussed in great length possibilities of reusing z-index. 
The main problem is that z-index seems to be not compatible with even SVG 
1.1 painting model, we had some proposals, but none was compatible. Your 
proposal on z-index integration is fairly disconnected with SVG painting 
model, which makes it hard to evaluate. I also do not think it is 
compatible with either CSS 2.1 definition or SVG 1.1 painting model, at 
least I think that in CSS clipping is applied to all descendants, no matter 
if they have z-index or not; in SVG clipping is applied only to element's 
canvas. Every element in SVG creates a new canvas (conceptually, at least) 
and is drawn on that canvas, clipping, masking, opacity and filters are all 
applied to that element's canvas (and filters in addition can use bits from 
enclosing canvases). Then canvas is rendered to the parent element's 
canvas. Overlay property is described in terms of SVG model: overlay simply 
delays painting until overlay-host is reached.  Note also this paragraph in 
CSS 2.1 spec (http://www.w3.org/TR/CSS21/visuren.html#propdef-z-index):

>The root element forms the root stacking context. Other stacking contexts 
>are generated by any positioned element (including relatively positioned 
>elements) having a computed value of 'z-index' other than 'auto'. Stacking 
>contexts are not necessarily related to containing blocks. In future 
>levels of CSS, other properties may introduce stacking contexts, for 
>example 'opacity'.

We certainly do not want any coupling of creation of "stacking contents" 
(in CSS terms) with either "stacking canvas" selection or, even more so, 
opacity - it has to be decoupled. It is clear that in CSS view z-index is 
"bracketed" by any painting "complexities" such as z-index itself or 
opacity. In SVG it is very common for groups to have these properties 
(e.g., opacity), in such environments, z-index becomes little more that a 
tool to rearrange painting of element's children which is not very useful.

The other problems (more minor) problems with z-index are:
- it causes land grab behavior ("I'll assign my z-index to 1000 so it is 
bigger than everyone else's")
- SVG drawing pipeline has to be made less efficient or more complex to 
accommodate arbitrary z-index values, especially negative ones



> > 11.16.1.1 The overlay-host property
>
>This property seems mostly redundant with the previous one, and would
>definitely be redundant with ussing 'z-index' instead of 'overlay'.

It is certainly not redundant. It causes all pending overlays to be drawn 
on this element's canvas. This is the only property that, in CSS terms, 
"creates a stacking context", overlay property does not. It is more that 
CSS z-index does two things instead of one (as clearly stated in its 
definition in CSS 2.1 - see above link):

>For a positioned box, the 'z-index' property specifies:
>         - The stack level of the box in the current stacking context.
>         - Whether the box establishes a local stacking context.

In SVG we have two properties that do these two separate things 
(conceptually, at least - actual details are different).

Peter

Received on Friday, 5 November 2004 21:49:54 UTC