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

Hi, Ian-

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'.

You've made this same argument throughout your email, but I'm not convinced
it's compelling. It's a very slippery slope to start pre-reserving keywords
for theoretical future as-yet-unwritten Specifications.


| 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.

I think that this is an interesting idea. Is it functionally the same as the
proposed SVG overlay syntax? That is, is the rendering model of all grouped
and non-grouped content the same as in the SVG model, with only the syntax
changed?

If so, I can think of two competing arguments. On the one hand, z-index is a
known style property (albeit with an unintuitive name for the uninitiated),
and would help those who are learning SVG and want to achieve this effect.
On the other hand, it doesn't quite explain what's "really going on" and so
might be confusing to people once they've really gotten into the guts and
are experiencing odd behavior.

As it stands, I like your suggestion, since it will be easier for newbies.


| > 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'.
| 
| 
| > The following example shows how to use the 'overlay' property to 
| > create a simple popup menu:
| 
| This example is a very good example of how SVG can be used to 
| dramatically violate the WAAA and WCAG concepts of separation 
| of presentation and content. Using SVG for graphics is a very 
| good use of SVG; however, using SVG for rendering UI elements 
| is an abuse of SVG:
| it has poor accessibility and no semantics.

Are you saying that sXBL is not a good use of SVG? That creating a GUI using
a guiML rendered in SVG is a bad idea? I doubt that's what you mean, but
that's what it sounds like.

The semantics would come from the domain-specific XML; this in turn would
lead to accessiblity (when coupled with SVG1.2's new focus attributes). In
fact, this would be a very good accessiblity case.


| I would recommend changing this example to a different one, 
| such as overlays on a zoomable map.

I thought the example was a very good one, showing how users wanting to do
that precise and common use case would be able to do so. Of course, other
use cases would be helpful, too, such as the one you mention.

Regards-
-Doug

Received on Tuesday, 2 November 2004 00:27:31 UTC