Additional Proposed Agenda Items for Today's (Monday's?) SVG TeleCon

Hi folks, 

I realize I am always a little late on these to be in time for the telecon, so if we cannot get to these today, it would be great to get to them on Monday.  Again thanks for your patience.


Item #1 Test Suites
===========
As requested, we were wondering if we can get the self-closing <object /> repaired on the test suites.  We are still gathering information from the web on how often this is used in this matter, but since according to HTML4/5 spec they should not be self-closing, we'd like to see this adjusted (soon :)).

Also, there seems to be no XHTML harness.  Since this a key scenarios, and it seems the test suites were originally extracted from XHTML, should we have those tests as well?

Item #2 Change in Spec vs. Change in Errata
===================================
We've noticed that since September some changes have been made to the 1.1 2nd edition that are not being tracked in the errata (Examples below). Are we right? If so, how can we get these updated in the errata?

-Example 1:  Change in behavior
http://www.w3.org/TR/SVG11/painting.html#StrokeProperties

Current online: "A subpath (see Paths) consisting of a single moveto is not stroked. A subpath consisting of a moveto and lineto to the same exact location or a subpath consisting of a moveto and a closepath will be stroked only if the 'stroke-linecap' property is set to "round", producing a circle centered at the given point."

SnapShot from September: "A subpath (See Paths) consisting of a single moveto shall not be stroked.  Any zero length subpath shall not be stroked if the 'stroke-linecap' property has a value of butt but shall be stroked if the 'stroke-linecap' property has a value of round or square, producing respectively a circle or a square centered at the given point.  Examples of zero length subpaths include 'M 10, 10 L 10, 10', 'M 20, 20 h0', .M 30, 30 z. and 'M 40, 40 c 0,0 0,0 0,0'."

-Example 2:  Added inheritance
http://www.w3.org/TR/SVG11/shapes.html#DOMInterfaces

Current online definition:
interface SVGRectElement : 
                SVGElement,
                SVGTests,
                SVGLangSpace,
                SVGExternalResourcesRequired,
                SVGStylable,
                SVGTransformable,
                events::EventTarget {
  readonly attribute SVGAnimatedLength x;
  readonly attribute SVGAnimatedLength y;
  readonly attribute SVGAnimatedLength width;
  readonly attribute SVGAnimatedLength height;
  readonly attribute SVGAnimatedLength rx;
  readonly attribute SVGAnimatedLength ry; };

In my book:
interface SVGRectElement : 
                SVGElement,
                SVGTests,
                SVGLangSpace,
                SVGExternalResourcesRequired,
                SVGStylable,
                SVGTransformable, {
  readonly attribute SVGAnimatedLength x;
  readonly attribute SVGAnimatedLength y;
  readonly attribute SVGAnimatedLength width;
  readonly attribute SVGAnimatedLength height;
  readonly attribute SVGAnimatedLength rx;
  readonly attribute SVGAnimatedLength ry; };

You'll notice the first has "events::EventTarget" while the second one does not.  

Item #3 Potential Spec Ambiguities, Requests for Updates and differences in browsers
====================================================================================



#3A - 'readonly / non-readonly' (raised before but not sure if this should be revisited)
========================================================================================

The SVG spec has the concept of a "readonly" instance that cannot be changed. IDL also has the concept of a readonly property that does not have a setter. The overloaded use of "readonly" is confusing. It is confusing enough that an appendix was added to the SVG spec to help reduce confusion. Still, it is difficult to talk about these differences when the spec uses overloaded vocabulary (B.8).

We think that the spec would be better worded with the following:

readonly / non-readonly : The IDL definition that describes if a property has a setter method. By default properties are assumed to be non-readonly.

immutable / mutable: Describes if an instance in the SVG DOM throws a NO_MODIFICATION_ALLOWED_ERR if an attempt is made to modify the instance.

There could be a little confusion around the desired exception between attempted modification of readonly and immutable properties.

In the case of IDL readonly properties, a browser may be implemented such that a setter does not exist and a MEMBER_NOT_FOUND exception is thrown. The SVG spec should reflect that a browser be silent about this error and leave the specified behavior to either a different W3C spec or allow the browsers to implement them as they see fit.

Immutable instances are an SVG specific construct and it makes sense that attempted changes to the instance throw a custom exception type. However, attempting to set a readonly property on an immutable instance should still throw the default error type.


#3B - Line caps drawing on zero length lines
======================================
The spec states: "A subpath consisting of a single moveto shall not be stroked. Any zero length subpath shall not be stroked if the 'stroke-linecap' property has a value of butt but shall be stroked if the 'stroke-linecap' property has a value of round or square, producing respectively a circle or a square centered at the given point. Examples of zero length subpaths include 'M 10,10 L 10,10', 'M 20,20 h 0', 'M 30,30 z' and 'M 40,40 c 0,0 0,0 0,0'.

The 1.1 spec seems inconsistent on this point.  In some cases it reflected this behavior for both round & square - see section F.5 ('path' element implementation notes) which specifically addresses zero-length segments and correctly mentioned both round & square.  

Can we get the spec updated to reflect the behaviors for round and square across the board?

#3C - 'symbol' and 'display: none' clarification
================================================

>From http://dev.w3.org/SVG/profiles/1.1F2/publish/struct.html#SymbolElement

'symbol' elements are never rendered directly; their only usage is as something that can be referenced using the 'use' element. The 'display' property does not apply to the 'symbol' element; thus, 'symbol' elements are not directly rendered even if the 'display' property is set to a value other than none, and 'symbol' elements are available for referencing even when the 'display' property on the 'symbol' element or any of its ancestors is set to none.

<symbol id="sym1" x="96" y="96" style="display: none">
    <rect x="0" y="0" width="96" height="96" fill="black" />
</symbol>
<use xlink:href="#sym1" />

Should a black 'rect' render (from the 'use') in the above scenario? It does not specify what happens to 'use' instances of 'symbol's when 'display: none' is specified. It is technically 'available for referencing', but it will never render because 'display: none' can't be overridden by child elements. So it depends on what is meant by 'available for referencing' - it is technically 'available', but it is pretty much useless because it will never be visible or occupy layout.

#3D - Further error processing clarifications
=============================================

In XHTML, we are unclear how the error processing from Tiny 1.2 applies to the scenario below.  It seems that all browsers inherit the strike-through, yet they probably shouldn't.

SVG TEXT should inherit bold in this scenario.
<b>
 <svg><text>I'm bold</text></svg>
</b>

SVG TEXT should not inherit the strikethrough in this scenario.
<s>
 <svg><text>I do not have a strikethrough </text></svg>
</s>


#3E - SVGElementInstance
========================

We see mixed support for SVGElementInstance.  Is this being depreciated?

The spec indicates: 

"An element and all its corresponding SVGElementInstance objects share an event listener list."

This implies that adding an event listener to a referenced object also adds an event to all of its corresponding SVGElementInstances. This makes sense. But the converse - adding an event listener to an SVGElementInstance - also adds that event to the referenced element. Seems strange. This means that you can change the behavior of a referenced element via an SVGElementInstance without going through SVGElementInstance.correspondingElement. That's what the spec says, and that's how Opera and Webkit have implemented it. As far as we know, there's no other way to modify the referenced element without having to go through correspondingElement.

Is this the expected behavoir?

#3F - SVGSVGElement 'width' and 'height'
=========================================

In SVGSVGElement 'width' and 'height' are exposed as SVGLength objects. And

"For outermost svg elements, the intrinsic width of the SVG document fragment. For embedded 'svg' elements, the width of the rectangular region into which the 'svg' element is placed.
A negative value is an error (see Error processing). A value of zero disables rendering of the element.
If the attribute is not specified, the effect is as if a value of '100%' were specified.

For outermost svg elements, the intrinsic height of the SVG document fragment. For embedded 'svg' elements, the height of the rectangular region into which the 'svg' element is placed.
A negative value is an error (see Error processing). A value of zero disables rendering of the element.
If the attribute is not specified, the effect is as if a value of '100%' were specified."

Percentages in SVGLength are defined as one of:
- a percentage of the nearest viewport
- a percentage of the nearest bounding box
- a unit percentage (50% = 0.5)

We believe that the width and height (as well as the x and y) on the topmost 'svg' element do not fall into any of these categories.

Section 5.11.2 should explicitly state what the percent applies to for x, y, width and height in the top most svg element.


#3G - Minor Correction to DOM language
======================================

Minor correction to  http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#RelationshipWithDOM2Events

"These mouse events ([DOM2EVENTS], section 1.6.4):"

Should read:

"These mutation events ([DOM2EVENTS], section 1.6.4):"

#3H - Identified browser discrepancies ('symbol')
======================================

The 'symbol' tag does not have 'x' and 'y' attributes, and it is not defined to establish a new coordinate system. However, Firefox and Chrome do establish a new coordinate system via the (undefined/invalid) 'x' and 'y' attributes on a 'symbol'.


That's all for now. Thanks!

Patrick Dengler
Senior Program Manager
Microsoft - Internet Explorer

Received on Thursday, 4 February 2010 15:51:08 UTC