W3C home > Mailing lists > Public > www-svg@w3.org > November 2005

Re: [SVGMobile12] Comments: Rendering Model

From: Chris Lilley <chris@w3.org>
Date: Tue, 8 Nov 2005 15:36:28 +0100
Message-ID: <1846214527.20051108153628@w3.org>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: www-svg@w3.org

On Tuesday, May 17, 2005, 8:36:47 PM, Boris wrote:

BZ> 3.3

BZ> This section doesn't define what the rendering order actually is. I
BZ> assume it's meant to be document order (depth-first, preorder
BZ> traversal of the DOM tree); if so, this should be stated explicitly.

We agree and have changed the spec to explicitly state:

Elements in an SVG document fragment have an implicit drawing order.
Element are rendered using a pre-order, depth-first walk of the SVG
document fragment. Subsequent elements are painted on top of previously
painted elements.

BZ> It's not clear to me how this section interacts with foreignObject.

the content of a foreignObject is treated as atomic from the point of
view of SVG compositing.

BZ> For example, what happens if an SVG fragment is present in an XHTML
BZ> document (something this specification explicitly allows) and
BZ> contains a foreignObject containing XHTML (something it also
BZ> allows). Given the CSS2 description of z-ordering (which applies to
BZ> both the XHTML outside the SVG and the XHTML inside the
BZ> foreignObject), what should happen?

The outer CSS-rendered XHTML will use the z-order property to re-order
the rendering order (within the limits of the stacking context per CSS
rules). The rendering of the svg element and its children will form a
new stacking context, so the outer HTML is either all above it or all
below it.

The SVG will render using painters algorithm and pre-order, depth-first
walk of the SVG document fragment. One of those elements is the
foreignObject, which renders as an atomic unit.

The inner CSS-rendered XHTML will use the z-order property to re-order
its internal rendering order (within the limits of the stacking context
per CSS rules). So, all of that inner XHTML subtree can be re-ordered,
absolutely positioned, etc but only within the context of that subtree.
The rendered result of the inner XHTML then gets composited by the SVG
in the place where it occurs in the tree.

BZ> For example, could we have a case where all the SVG content is
BZ> painted before some sibling node of <svg> _except_ for a node that's
BZ> a descendant of the foreignObject, which is painted after said
BZ> sibling node?

No. Stacking context is essential when considering this use case.

BZ> 3.4

BZ> foreignObject doesn't seem to be a shape, it's not text, so it must
BZ> be a raster image or video? Or is there a fifth fundamental type of
BZ> graphics element?

We agree that foreignObject was not covered, and have altered the spec
to say:

SVG supports three fundamental types of graphics elements that can be
rendered onto the canvas:

    * Shapes, which represent some combination of straight line and curves
    * Text, which represents some combination of character glyphs
    * Replaced content:
       - Raster images, which represent an array of values
         that specify the paint color and opacity (often termed
         alpha) at a series of points on a rectangular grid.
         (SVG requires support for specified raster image formats
         under conformance requirements.)
       - Video, which represents a timed sequence of raster images.
       - Animation, which represents a timed vector animation
       - Foreign objects, which represent rendering of non-SVG

BZ> 3.4.2

BZ> This is using the verbs "render" and "paint" interchangeably (and
BZ> never actually says that explicitly). Please pick one verb and stick
BZ> with it.

We agree, and 'paint' is used with a different meaning elsewhere. We
have retitled 3.4.2 Rendering raster images.

Please let us know shortly if these responses and spec changes do not
satisfy your comment.

 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG
Received on Tuesday, 8 November 2005 14:36:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:08 UTC