- From: Ian Hickson <ian@hixie.ch>
- Date: Sun, 31 Oct 2004 08:45:32 +0000 (UTC)
- To: www-svg@w3.org
- Cc: Håkon Wium Lie <howcome@opera.com>
Here are some more detailed SVG 1.2 Last Call comments to supplement
my earlier submission. [1] I have sent them as one file, since that's
what was easier for me and Dean said it didn't really matter if it was
one file or many. People who wish to respond to individual parts of
this are encouraged to change the subject line when doing so.
> 1 Introduction
> [...]
> It is believed that this specification is in conformance with the
> Web Architecture [AWWW].
It appears that SVG 1.2 is in conflict with section "4.3. Separation
of Content, Presentation, and Interaction" of the WAAA draft.
SVG 1.2 mixes content markup (e.g. in section "4 Flowing text and
graphics"), presentation markup (the bread and butter of SVG), and
interaction markup (e.g. in section "15.1 Element focus and
navigation"). It would seem that SVG 1.2 should focus on a single one
of these areas, namely presentation, and leave the other two areas,
content and interaction, to other specifications.
This conflict with WAAA is also a conflict with Web Arch [2],
conformance to which is a requirement of the SVG Charter [3]. Thus
this conflict needs to be resolved before SVG 1.2 can enter CR.
> 2 Profiling SVG
This section describes a technique for device-specific profiling of
SVG. Device-specific profiling of content languages is harmful for the
Web, leading to fragmentation of the Web into device-dependent
sections. This is directly counter to the goal of creating device-
independent content that is then styled using device-specific
stylesheets.
The goal of the W3C's accessibility work is to make all content
available to all users. If content specifications such as SVG are
profiled into device-specific versions, content will be designed for
one device market at the expense of the users in all the other
markets.
Similarly, there are now several implementors (Mozilla and Opera among
them) who write single rendering engines that are then used on both
small devices and full desktop machines. These rendering engines are
intended to support the same features, so that content will work
equally well on all platforms. Such browsers will only be able to
implement the level of SVG that can be supported across all these
platforms.
Thus I would ask that the SVG spec specifically _not_ be modularised
or profiled. If there are features that cannot be implemented on small
devices, IMHO they should be removed from the core as well, or defined
in such a way that not supporting the feature falls back gracefully.
(For instance, gradients could be defined so that if they are not
supported they fall back to a single solid colour.)
> 3 XML Binding Language for SVG
My personal preference here would be to remove this chapter and
instead ensure that the XBL specification itself fully defines the way
it affects specifications such as SVG, HTML, and the like. Having a
specification define new features but then leave their side-effects
undefined and up to other specifications to clean up seems like
irresponsible language design.
> 3.1 Introduction
> [...]
> sXBL allows developers to create re-usable, higher-level components
> expressed in a custom XML vocabulary (tag set), where the
> implementation of these components is defined in terms of a shadow
> tree containing SVG content.
This should be clarified to explain that such custom vocabularies
should only be used in the context of SVG images, and not for writing
documents that may be processed by users who are unable to view SVG
content.
> [...]
The current model of binding non-SVG content (such as XForms) to SVG
content, by wrapping the non-SVG content inside an SVG framework and
then explicitly listing the XBL bindings in the document at the
content-level, suffers from the earlier-mentioned problem of lack of
separation of content from presentation.
Authors should be able to style documents that are device-independent,
such as XHTML2+XForms documents, without hard-coding the presentation
into the markup.
> 3.2 Simple example
> [...]
> The highlighted sections below [...]
The sections are not highlighted.
> 3.3.1 Standalone SVG documents restriction
> [...]
> This specification only defines sXBL processing rules or stand-alone
> SVG documents where either of the following is true:
I am concerned that this specification is introducing new elements
without defining the semantics of these elements in all cases. It
isn't the role of future specifications to define how this
specification interacts with other specifications. When a tag is
introduced, the specification doing that introduction should take
responsibility for defining that tag in the face of any namespace it
might find itself in.
In particular, the phrases "defined by the host language" and "a
compound document problem", which are often used to dismiss such
concerns, are in my opinion cop-out solutions that can only lead to
impaired interoperability and greater confusion for implementors and
authors alike.
> 3.3.2 Non-SVG element restriction
>
> Within an SVG document fragment, sXBL binding definitions can only
> be applied to elements which are not in the SVG namespace. Documents
> which contain binding definitions for elements in the SVG namespace
> are in error.
It would seem more logical for SVG to not have a special status here.
SVG elements IMHO should be handled just like any other namespace's
elements, and support XBL in the same way. Why are SVG elements more
special than, say, XForms, XHTML, XSL:FO, or MathML elements?
> The following example shows three binding definitions that are not
> allowed:
> [...]
> <xbl:definition element="MySVGWidget1">
The way sXBL is defined (sXBL public draft, section 2.2, "element"
definition, paragraph 2), this declares a binding for the element
"MySVGWidget1" in the null namespace, not the SVG namespace. (The
second and third examples demonstrate the intended thing.)
> of a rect and a rect
...should be "rect" and "text" respectively.
> on the NodeXBL interface..
Two dots.
> 3.7 The traitDef element
The "valueType" attribute is insanely verbose. Short strings would be
much more usable here.
> 3.8 Trait mutation events
This section omits to define the event's namespace, bubbling
behaviour, and default action. Its IDL doesn't define the
initTraitMutationEvent and initTraitMutationEventNS methods which
should presumably be used to initialise such events. The two
attributes on the event are mutable, unlike similar attributes on
other event interfaces.
> DOM interfaces for custom elements
>
> All non-SVG elements within an SVG document support the xbl::NodeXBL
> interface defined in the sXBL specification and also support all of
> the same interfaces as the g element [...]
This is not a workable definition. Whether a document is an SVG
document or not can vary over time during a single session as DOM
calls create and remove elements from the DOM, yet elements in that
DOM cannot change interfaces on the fly.
Short of specifying that the given interfaces are implemented by
_every_ element (much like NodeXBL), there is not much that can be
done here. Custom elements shouldn't all have SVG interfaces.
> http://www.w3.org/TR/SVG12/images/goflow.svg
This image is not well-formed.
> 4 Flowing text and graphics
This section seems to reinvent large parts of HTML and CSS (albeit in
a semantically poorer manner) in order to achieve a single effect.
Here is a proposal to replace this entire section with something much
simpler which reuses existing W3C standards with just the addition of
a single value to a single property already used by SVG:
Property name: 'overflow'
New value: <uri>
If the 'overflow' property computes to a URI, then if that URI
points to an <svg> element, that element is processed one element
at a time as follows, with coordinates being resolved as if the
<svg> element had been rendered at that point in the document
instead of the element. The element's intrinsic dimensions are then
taken from the <svg> element. This processing creates a list of
fill areas for the element, into which the element's content is
flowed, as described below.
* If it is a simple shape or path, find the area of the shape that
would be covered by fill. Add that area to a list of fill areas
for this element.
* If it is a <use> element, the content to which it refers is
processed as per normal SVG rules and then each element from
that is recursed and examined just like the children of the main
<svg> element being processed here.
* If it is a <g> or <svg> element, the children are recursed in
the same way.
* Anything else is ignored for the purposes of 'overflow'.
If the URI does not point to an <svg> element, or if the element
contains no line boxes, then 'overflow' is treated as 'hidden'.
Within the element's content area, the content is layed out as if
the content edge of the element defined a paginated layout's page
area. The content is layed out one page at a time, with each page
being rendered above previous pages. Each page uses one of the fill
areas, in the order they were given in the <svg> element. The fill
areas only affect the layout of line boxes (as described below) and
the final painting: each page is clipped to the bounding box of the
fill area.
To lay out a line box in such a page, the top of the line box is
moved down from the top of its containing block's top edge until at
least one part of it is within the fill area. Words are then added
to this line box while they fit.
Words consist of all inline content between line breaking
opportunities.
Words are said to fit in the line box if their inline box is
completely within the fill area, without being to the left of the
right edge of any left floats in the same flow, without being to
the right of the left edge of any right floats in the same flow,
and without overflowing their line box's containing block's content
area.
For each word in the current block, the new word is placed in the
line at its appropriate place relative to any words already on the
line according to the bidi ordering. The line box height and
vertical alignment is calculated given all the content on the line.
(This is the bidi processing step.)
The user agent must then find an appropriate horizontal position
for each word in the line box, in visual order, starting at the
edge of the line box specified by the 'text-align' property. To do
this, each word is pushed from its starting position next to the
previous word (after any spaces or word-spacing, with the first
word starting at the start edge of the line box's containing block)
towards the end edge until the word fits. (This takes care of
moving words past any holes in the fill area, after bidi
processing.) For center alignment and justified alignment, the text
should be aligned as for 'start' alignment, and then within each
part that is not broken by a fill area the words are aligned
accordingly (either with the center of that part of the line box,
or justified so that each edge of that part of the line box touches
the side of a word).
If adding a word to a line box causes the words to no longer fit
inside that line box, then the word is not placed inside that line
box, but a new line box is created and the word is placed into that
one using the steps described above again. If that line is moved
down past the end of the last fill area "page" in an attempt to
find somewhere where it can be rendered, then all subsequent text
in that element is hidden, as if it was all placed in a hidden
zero-height line box after the last line box that did fit.
Page breaks in the flow of the element (either explicit page breaks
or breaks caused by reaching the end of the element's content area)
cause the current page to break, and the next page to be started
using the next fill area. If there are no more fill areas, all
subsequent content is hidden.
Elements with 'overflow' set to a value other than 'visible' are
not affected by flow regions defined by ancestors with 'overflow'
set to a URI value, and render normally (they are still clipped by
the fill area along with all the other renderings, though).
All other layout is handled normally.
Example 1:
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" height="100" width="200">
<defs>
<svg id="sample" viewBox="0 0 10 10" height="100%" width="100%">
<circle cx="3" cy="3" r="3"/>
<circle cx="9" cy="3" r="3"/>
</svg>
</defs>
<foreignObject overflow="url(#sample)" xmlns:h="http://www.w3.org/1999/xhtml" width="100%" height="100%">
<h:p>Bla bla bla.</h:p>
<h:p>Bla bla bla.</h:p>
</foreignObject>
</svg>
...might render as:
Bla bla.
bla Bla
Example 2:
<svg xmlns="http://www.w3.org/2000/svg" version="1.2">
<svg id="sample" viewBox="0 0 300 310" height="100%" width="100%">
<path d="M100,50L50,300L250,300L300,50z"/>
</svg>
<foreignObject overflow="url(#sample)" xmlns:h"http://www.w3.org/1999/xhtml" width="100%" height="100%">
<h:table>
<h:tr>
<h:td> ABC DEF GHI JKL </h:td>
<h:td> abc def ghi jkl </h:td>
</h:tr>
</h:table>
</foreignObject>
</svg>
...might render as:
_________________
/ ABC DEF abc def \
/ GHI JKL ghi jkl \
/_____________________\
Example 3:
<svg xmlns="http://www.w3.org/2000/svg" version="1.2">
<defs>
<svg id="sample" viewBox="0 0 10 10" height="100%" width="100%">
<rect x="5" y="5" width="5" height="5"/>
</svg>
</defs>
<style type="text/css">
div { position: absolute; top: 0; left: 0; width: 100%; background: red; }
</style>
<foreignObject overflow="url(#sample)" xmlns:h"http://www.w3.org/1999/xhtml" width="100%" height="100%">
<h:div> X___ </h:div>
<h:div> _X__ </h:div>
<h:div> __X_ </h:div>
<h:div> ___X </h:div>
</foreignObject>
</svg>
...would render as:
______________
| |
| |
| XXXX |
|______________|
...but no red would be visible.
> 4.14.1 The text-align property
This definition, due to its differences with CSS2.1, is incompatible
with CSS. A property cannot have different syntaxes in different host
languages, that is a violation of the CSS model.
> 4.14.2 The progression-align property
This property is redundant with existing CSS properties (namely
'margin') and overlaps with the CSS block rendering model (chapters 9
and 10 of CSS2.1). It should be removed in favour of harmonising with
the CSS model (as, for instance, my proposal above does).
> 4.14.3 Overflow
Firing events during layout is dangerous. It can easily lead to
authors creating infinite loops that are very hard to heuristically
detect and distinguish from iterative layouts and animations.
It is also unclear what the use cases are for these events. The
obvious use cases (such as iterating to find the opimum font size) are
quite hard to achieve using the events as currently defined.
Also, this section omits to define the event's bubbling behaviour and
default action. Its IDL doesn't define the initSVGOverflowEvent and
initSVGOverflowEventNS methods which should presumably be used to
initialise such events. The interface is missing a |view| attribute
(readonly attribute views::AbstractView view;) which is required for
all view-specific events (see, e.g., the UIEvent definition).
> 5 Multiple pages
Why does SVG 1.2 need its own separate way of doing paged media when
both SMIL and CSS provide ways of doing it already?
I would recommend removing this chapter in favour of using SMIL for
the time container features, and placing SVG fragments into an HTML
document that uses CSS' page-break-after property for the multipage
feature.
> All pages are contained within a single pageSet element.
Given that the only content allowed in that element is pages, and
given that that element must be the last element of an <svg> element,
it seems redundant. Why not just say that <page> elements may be used
at the end of <svg> elements, with no other elements between them or
after them?
The model could also be simplified to simply say that first everything
before the first <page> is rendered, then the first <page> is
rendered, and then if the page is changed, the <page> is removed and
the next one is rendered in its place.
> No element from the SVG namespace is allowed between the closing
> pageSet tag and the closing svg tag.
The specification should define how UAs must handle content between
<page> elements as well.
> 5.5 The page-orientation property
This property is redundant with similar constructs in CSS3 Paged
Media. Please refer to CSS3 Paged Media instead of adding
similarly-named properties with subtly different semantics, so that
UAs only have to implement one mechanism.
> 6.1.2 CSS pseudo class for editable text
Please do not introduce a new pseudo-class to perform something that
is already possible using CSS (as is even described in SVG 1.2).
> 6.2 Text Selection
This section omits to define the event's bubbling behaviour and
default action. Its IDL doesn't define the initSVGSelectionEvent and
initSVGSelectionEventNS methods which should presumably be used to
initialise such events. The interface is missing a |view| attribute
(readonly attribute views::AbstractView view;) which is required for
all view-specific events (see, e.g., the UIEvent definition).
This section doesn't define what should happen if the selection
crosses out of the <svg> element into other content. For example, why
is the |selection| attribute on the SVGSVGElement interface instead of
the document?
It would seem better for selection to be defined independent of SVG
(outside the SVG specification, since it applies to more than SVG) and
have SVG re-use such a definition.
> 7 Streaming
>
> The SVG working group is considering streaming enhancements to the
> SVG language.
This phraseology seems inappropriate for a specification.
> Here are two identified uses for streaming:
>
> 1. The SVG Print specification has relatively low-end printers as a
> potential target. These devices may have various limitations such
> as memory. It might be a requirement of SVGP that elements can be
> rendered and discarded immediately, thereby removing the need for
> maintaining an in-memory DOM for the document.
This use case can be handled without any additional attributes in the
document. The way <page> elements are defined, they never need to be
kept in memory except in dynamic environments, and therefore the print
use case is already handled.
> 2. For time-based SVG applications viewed on a display device, we
> would like SVG to allow time-based elements such as animations to
> start while the rest of the document is still downloading.
> [...]
> 7.1 The timelineBegin attribute
This attribute seems to let authors control something that really
should be under the control of the user or the UA implementor. IMHO
this attribute should be removed, in favour of letting the UA estimate
the best possible start time so that the animation can be playing as
early as possible without playing faster than the content is streamed.
This behaviour doesn't correspond to either of the given values.
> 7.2 The streamedContents attribute
Since this attribute only affects pages, it would seem to make more
sense to place its definition in the "Multiple pages" chapter.
> 8 Progressive rendering
In general, this chapter seems like over-specifying what should be an
implementation detail. If a UA wants to only incrementally render
content every few seconds instead of for every start tag, it should be
allowed to do so, especially given that the latter behaviour is a
massive performance hit.
> According to the proposal above
Presumably "proposal" should be "definitions".
> 9 Vector effects
While I am sure there is demand for such features, and while I am sure
such features can be used to create great effects, it still seems like
this is feature creep. Many of the effects achievable by the
mechanisms described in this section are also possible by careful use
of <path>, use of different markers, and existing options on the
"fill" and "stroke" attributes.
It would seem better to have the authoring tools effectively
"prerender" the vector effects than to require that all the SVG user
agents support an entire chapter's worth of additional features.
> 10 Rendering model
Again, while I am sure that there is demand for these new features,
they significantly increase the complexity of an SVG user agent. I
would like to urge the working group to consider dramatically
simplifying the set of new composition operators and related features
introduced by this chapter. For instance, are four new properties
really needed just to do composition? What are the two or three major
use cases that people are needing, and can those be addressed by a
simple addition instead?
To put it another way: purely to test the new additions in this
chapter will probably take around a thousand tests, and that doesn't
take into account the need for testing these feature with each of the
existing features of SVG 1.1 and the need for tests of error handling.
Is the working group really intending to create that many tests for
these features before allowing SVG 1.2 to exit CR, as required by the
W3C process?
> 10.1.3 The clip-to-self property
> [...]
> The clip-to-self property determines if the object effects pixels
> not covered by the object. Some compositing operations effect pixels
> where the source graphic is completely transparent.
> [...]
> 1. Setting clip-to-self to true means that compositing an object only
> effects the pixels covered by the object.
> 2. Setting clip-to-self to false means that compositing an object
> effects all pixels on the canvas by compositing completely
> transparent source onto the destination for areas not covered by
> the object.
> [...]
> Container elements where the clip-to-self property is set to true
> only effect the pixels within the extent of the container element.
Five occurances of the word "effect" here should be "affect".
> 10.1.3 The clip-to-self property
> 10.1.4 The enable-background property
> 10.1.5 The knock-out property
> 10.1.6 The comp-op property
All four of these properties are very SVG-specific yet have very
generic names. In order to reduce the risk of clashes with similarly
named properties introduced by other working groups in future, I
recommend renaming these properties to more specifically describe
their intended use. For instance, 'comp-op' might be better named
'graphic-element-comp-op' or some such.
> 11.1 Background Fill Property
This property is redundant with the CSS1 background-color property.
> 11.2 Background Fill Opacity Property
This property is redundant with the CSS3 rgba() syntax.
Please use the existing CSS properties for background instead of
adding a new one. If the ability to give a URI to a <solidColor>
element is of paramount importance, please request an addition to CSS3
Color rather than inventing two new properties.
In any case, the names 'background-fill' and 'background-fill-opacity'
are very generic and are likely to clash with future properties added
by the CSS working group. I would recommend using more specific names
if reusing existing properties is not possible, such as 'graphic-
viewport-background-fill'.
> 11.3 Inheritance into the shadow tree
> [...]
> dynamic
Please define what this attribute means for host languages that do not
define it (namely, all of them).
> For feImage, when referencing a document resource, 'dynamic' is
> equivalent to 'onUse', but when referencing an element node within a
> document it is equivalent to 'none'.
This does not appear to be backwards compatible with the SVG 1.1
definition of feImage. Could a note be added to the document
explaining the effect on existing UAs?
> 11.5.1 The device-color keyword
For the purposes of the CSS syntax and CSS parsing, the specification
must define exactly what types of data are allowed for the second and
subsequent arguments to the device-color() form. I recommend allowing
only numbers, or numbers and strings.
This is required so that parsers can know whether to drop the property
or whether to cascade it.
> 11.7 Specifying paint
The syntax given for <paint> appears to be corrupt.
> <color> [icc-color( <name> [, <icccolorvalue>])] [device-color(
> <name> [, <devicecolorvalue>])] [icc-named-color( <name> ,
> <colorname> )]*
This means that the following:
red device-color(red) icc-color(red)
...is invalid and must be ignored. Is this intended? Or is the order
intended to be arbitrary?
> SVG supports all of the syntax alternatives for color defined in
> CSS2-color-types, with the exception that SVG contains an expanded
> list of recognized color keywords names.
This should be clarified to point out that UAs may support CSS3 Color,
in which case the allowed colour syntaxes are more varied.
> (see Error processing.
Missing ")".
> 11.8.1 The rendering-color-space property
What is the actual use case for this property? It seems unlikely that
any Web authors will care much about the exact colour space used to
render their images -- most Web authors don't even care much about
gamma correction.
Requiring Web UAs to be so detailed in their handling of colours is
unlikely to be popular with UA implementors. For example, there is no
chance that mobile SVG vendors would want to implement this property.
If this property is specifically targeted at closed-workflow
environments such as print shops, then I would suggest that this
property (and any other features designed specifically for such
environments, such as the device-color and ICC features) be moved to a
separate specification that extends SVG in ways specifically targetted
at such environments, without burdening all other UAs.
> 11.10.1 The prefetch element
Instead of inventing a new element based on an existing SMIL element,
why not use the existing SMIL element?
This is similar to an earlier point. When SMIL features that are
applicable to SVG, it would seem better to actually use SMIL rather
than reinventing the SMIL specification in a different namespace.
> 11.13 The min-unit-scale and max-unit-scale attributes
> [...] sytsem [...]
Typo.
> 11.14 Testing for formats
> [...]
> image/svg+xml,
Extraneous comma.
> 11.15 Testing for font availability
It is not immediately clear how this property would be useful. It is
quite possible for a font to be installed on a system with the same
name as a font the author would like to have available, but for that
font to have radically different metrics than the one the author
expected.
> 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'.
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.
> 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.
I would recommend changing this example to a different one, such as
overlays on a zoomable map.
> 11.17.1 The cursor property
SVG can't really "add a new value" to a property that is defined by
another specification. The 'cursor' property is a part of CSS2.1, not
SVG. While SVG can refer to CSS2.1 (or CSS3 UI) and say that compliant
SVG UAs must also be compliant to the relevant part of that other
specification, it makes no sense to import the property wholesale and
then claim it to be a part of SVG.
> a dynamic pseudo-class ':highlight' is provided in SVG 1.2
Adding new pseudo-classes to CSS is not within the SVG working group's
mandate, so please remove this pseudo-class from SVG 1.2.
In any case, this pseudo-class is redundant with the W3C Selectors
:target pseudo-class. [4]
> 11.19 Automatic text length
> SVG 1.2 adds a new keyword, "auto", to the allowed values of the
> textLength attribute.
Since this is an attribute, not a property, it does not have to be
specified. Why, then, does it need an explicit default value?
> 11.20.1 The cache property
> 11.20.1.1 The static property
> 11.20.2 The snap property
Experience with HTML has shown that most authors will never make use
of properties of this nature, and that most authors who _do_ make use
of it will drastically abuse them, with rules such as:
* { cache: true ! important }
...or:
:focus { static: true; }
I therefore strongly recommend that these properties be dropped. My
prediction is that if they remain in SVG 1.2 and SVG 1.2 becomes
widely implemented and used, that these properties will end up having
to be ignored by UAs that wish to remain performant in the face of
real Web content.
> 12.1 The audio element
> 12.2 The video element
Specific features for embedding audio and video does not belong in "a
modularized language for describing two-dimensional vector and mixed
vector/raster graphics in XML". Indeed these features appear to be
redundant with the existing <foreignObject> element and with SMIL.
For instance, a SMIL wrapper would be a better way of synchronising
audio and SVG animation than embedding audio straight into the SVG.
The <foreignObject> element could be extended to support linking to
external content much like HTML's <object> element. This would then
allow SVG to embed any kind of non-XML data, not just video.
> 12.3 Alternate content based on display resolutions
This section would seem to be redundant with using the <switch>
element and the <image> element and the min-pixel-size/max-pixel-size
attributes. I would recommend focussing on making <switch> work for
this case rather than introducing a set of new elements to perform the
same purpose.
> 12.4 Media Properties
This property seems to be redundant with existing features in SMIL.
> 13.1 The animation element
The comments made regarding <video> apply to <animation> as well.
> 13.2 Media elements
> 13.3 Time containers
> 13.4 Attributes for run-time synchronization
> 13.5 Time Manipulation
> 13.6 Enhanced ElementTimeControl interface
These sections appear to be redundant with SMIL. I would prefer to see
SMIL be reused directly rather than the SVG namespace importing half
of SMIL and requiring SMIL+SVG UAs to introduce two codepaths for each
shared feature.
> 15.1.1 The focusable property
This property does not appear to be limited to SVG. It would thus be
better to define this property in a non-SVG specification, so that it
can be used by authors using other languages.
> 15.2.2 The tooltip property
This property does not appear to be limited to SVG. It would thus be
better to define this property in a non-SVG specification, so that it
can be used by authors using other languages.
This property name has been proposed several times in the context of
CSS for other purposes. If SVG 1.2 keeps this property instead of
moving it to a more appropriate specification, it would be better to
rename the property to something more specific, such as 'hint-element-
visibility' or some such.
> 16 Events and Scripting
> [...]
> text/ecmascript
This MIME type is not a registered MIME type. If using a registered
MIME type is indeed not a requirement, I would recommend using the
more popular text/javascript type.
> 16.4 Processing order for user interface event
> [...]
> * [...] If none of the activation event handlers take an explicit
> action to prevent further processing of the given event (e.g., by
> invoking the preventDefault() DOM method), then the event is
> passed on for:
> * Processing of any relevant dynamic pseudo-classes (i.e., :hover,
> :active and :focus) [...]
The SVG spec should not redefine :hover, etc. The :hover pseudo-class,
for example, is defined by CSS to be independent on event handlers.
The current definition can result in a document causing certain
elements to enter :hover but not exit it (by only cancelling mouseout
events), and requires UAs to implement two distinct processing models
for :hover depending on whether the top-most element is in the SVG
namespace or not.
> (For those user interface events which invoke hyperlinks, such as
> mouse clicks in some user agents) Link processing.
I would suggest defining link processing as being the default action
of the DOMActivate event on the link, not special-casing link
processing at the DOM Event Handling level.
> (For those user interface events which can select text, such as
> mouse clicks and drags on 'text' elements) Text selection
> processing.
Similarly, this should just be defined in terms of default actions.
> A.9.1 The ShapeChange event
This section is unclear about the event's name and namespace, bubbling
behaviour, and default action. Its IDL appears to have an invalid
interface name and doesn't define the initShapeChangeEvent and
initShapeChangeEventNS methods which should presumably be used to
initialise such events.
> A.9.2 The RenderedBBoxChange event
This section is unclear about the event's name and namespace, bubbling
behaviour, and default action. Its IDL appears to have an invalid
interface name and doesn't define the initRenderedBBoxChangeEvent and
initRenderedBBoxChangeEventNS methods which should presumably be used
to initialise such events. The interface is missing a |view| attribute
(readonly attribute views::AbstractView view;) which is required for
all view-specific events (see, e.g., the UIEvent definition).
> B.1 SVGTimer Interface
This interface appears to be a more complicated version of the widely-
implemented window.setTimeout() and window.setInterval() methods. I
would recommend not reinventing existing interfaces, since these
interfaces are well understood and easy to specify and use.
It also seems strange that a vector graphics language would be
defining what really should be core DOM interfaces.
> B.2.1 URLRequest interface
This interface appears to be a more complicated version of the widely-
implemented XMLHttpRequest interface. I have written a specification
for XMLHttpRequest that the SVG working group is welcome to refer to
or copy verbatim into a generic specification for scripted HTTP:
http://whatwg.org/specs/web-apps/current-work/#scripted
However, I do not understand why this feature is being added to SVG
itself. It also seems to be completely redundant with DOM3 Load and
Save.
In HTML, Microsoft's dominance in the HTML browsing market has made
Microsoft's XMLHttpRequest interface (which was released well before
DOM3 Load and Save) quite popular (it's even used by large sites like
GMail). This has resulted in a demand for that specific interface. In
SVG, however, there is no such huge demand for a specific interface,
and therefore it would seem more within the spirit of the W3C to use
the DOM3 Load and Save interface.
Inventing a third interface for the same role seems unnecessary.
Note that implementing URIRequest on top of an XMLHttpRequest
implementation would be non-trivial, requiring as much code as the
original XMLHttpRequest implementation itself, because the two
interfaces do not map well from one to the other (there are numerous
subtle differences, such as the values for readyState, and what each
method should return in each state).
> B.2.3 Socket Connections
This section is incomplete (the semantics of the interface's members
are not defined).
Allowing arbitrary socket connections is either very dangerous, or of
limited use, depending on the security restrictions. If it is allowed
for any host, it can be used for sending spam. If it is allowed only
for the originating host, it can be used to perform attacks from HTTP
ports to HTTPS ports (as noted in the previous section). If it is
restricted to the originating port, then it is no more powerful than
the previous section, and significantly harder to use.
> B.3.1 The Progress event
This section omits to define the event's namespace, bubbling
behaviour, and default action. Its IDL doesn't define the
initProgressEventNS method, and the initProgressEvent method is
missing the progressArg argument.
> B.4.7 Security considerations
> The file upload feature has security implications. However it does
> not add any security-related issues above those in the common HTML
> file upload form widget.
This is somewhat incorrect, as the HTML form upload control does not
allow script to access the file contents directly, nor is script able
to detect whether or not a file has been selected. The only thing that
the HTML file upload control does is allow the user to send one or
more files to the remote server without any client-side script
intervention.
> B.5 Persistent Client-side Data storage
It seems strange for this section to be in a vector graphics language
specification. It would seem better suited for a generic DOM
specification.
> The user agent keeps a table of persistent values separate for each
> domain.
The term "domain" should be defined in this context. For example,
would an SVG file on damowmow.com be able to access the persistent
storage of an SVG file on www.damowmow.com? How about in the other
direction?
> Node parseXML(in DOMString source, in Document document);
This appears to be redundant with DOM3 Load and Save.
> Appendix C: SVG DOM Subset
This appendix would seem to belong more in the SVG 1.2 Tiny profile
specificaton, rather than in SVG 1.2 itself.
> A.2.7 Text Node Access
Instead of using traits, it would seem more compatible with DOM3 Core
to use the .textContent attribute. This would also be easier to author
with, while not being any more complicated to implement.
> Appendix D: Feature strings
This section is unclear on how a UA implementor should determine that
a particular feature is supported or not. How many bugs can a feature
have before a UA must stop claiming to support a feature?
SVG 1.2, including SVG 1.1, is a very large specification, and is
complex enough that it is unlikely that most implementors will be able
to implement the entire specification in any reasonable amount of
time. This reduces the usefulness of SVG, as described in SVG 1.2
chapter 2.
In conclusion, I recommend dropping chapters 2, 3, 4, 5, 7, 8, 9, and
12, and severely simplifying chapters 6, 10, 11, and 13. The result
would be a small set of additions that could be added to the SVG 1.1
specification to create a true SVG 1.2, that is, a small incremental
improvement of SVG 1.1, instead of the significant leap in complexity
that is SVG 1.2. Along with removing features from SVG 1.1 that have
been found to be of limited use, this would keep SVG 1.2 a reasonable
implementation target.
As it currently stands, SVG 1.2 duplicates functionality from multiple
existing specifications including CSS2.1, CSS3 UI, W3C Selectors,
HTML, and SMIL, and reinvents de facto standard interfaces that are
already supported in multiple UAs such as XMLHttpRequest. It also
seems to stray from its role as a vector language, instead attempting
to solve problems from completely different areas such as Web
application development.
SVG is not well suited for content creation; it is at heart a
presentation language. I would recommend that the SVG working group
focus primarily on vector graphics, and that SVG working group members
join the Web Applications working group upon its creation to create
Web Application formats in a more appropriate forum.
In my earlier submission I also indicated that SVG 1.1 had poor
interoperability. I base this assertion on the poor results that
high-profile UAs obtain on my own tests for SVG:
http://www.hixie.ch/tests/adhoc/svg/
The SVG 1.1 test suite is woefully inadequate given the size of the
specification in question. For example, the entire markers section has
only two tests:
http://www.w3.org/Graphics/SVG/Test/20030813/htmlframe/full-painting-marker-01-f.html
http://www.w3.org/Graphics/SVG/Test/20030813/htmlframe/full-painting-marker-02-f.html
As a professional QA engineer, it is my opinion that this is not
enough to ensure that there are interoperable implementations of the
marker features of SVG 1.1.
Certain areas of the specification are completely untested (appendix F
in particular appears to have no tests).
I urge the SVG working group to add the tests I have written (cited
above) to the SVG test suite (they are in the public domain). My own
tests are but a fraction of those that would need to be added to get a
thorough test suite for SVG 1.1, however. I would therefore also
encourage the SVG working group to focus on increasing the breadth and
depth of the SVG test suite.
I would like to recommend that SVG 1.2 use the same CR Exit Criteria as
CSS2.1:
http://www.w3.org/Style/Group/css2-src/cover.html#crec
Along with a throrough test suite, this would help raise the quality of
the SVG specification. (Using such a strict exit criteria, and requiring
detailed tests, has resulted in numerous issues being ambiguities being
discovered and resolved before the specification reaches the REC stage.)
PS: Comparison to other groups are irrelevant here, but since my last
message resulted in such a comparison, I feel compelled to correct the
misconceptions surrounding the CSS group's own test suites [5].
The CSS1 test suite has 106 tests, for a specification that is
approximately 100 pages long. [6]
The CSS2.1 test suite is in development, so officially has no tests.
(The development version currently has 264 tests, but it is nowhere
near complete. We expect to publish a very early draft with these
tests in a few weeks.)
The W3C Selectors test suite has 303 tests, for a specification with
about 50 pages. [7] (I'm only counting XHTML tests here, since the XML
and HTML tests are just automatically generated variants of those
tests, and thus don't really find more bugs.)
The SVG 1.1 test suite has, according to Chris Lilley, 258 tests. I
could not find that many when I looked (I found 181), but maybe I
miscounted. That's for a specification with some 500 pages.
Also, note that W3C Selectors and CSS2.1 have not exit CR yet. The CSS
working group is aware that UAs have not yet reached a mature stage, and
has therefore not prematurely moved the specifications to PR and to REC.
Like I said, I don't want to play the comparison game, I just wanted
to correct the numbers that I've seen people throwing about.
The SVG working group should also not feel singled out by these
comments. Many other working groups in the W3C are creating new
specifications without adequately testing their existing work, and
many drafts are exiting CR without more than lip service being made to
the interoperability requirements.
-- References --
[1] http://lists.w3.org/Archives/Public/www-svg/2004Oct/0088.html
[2] http://www.w3.org/DesignIssues/Architecture.html
[3] http://www.w3.org/2003/07/svgwg-charter.html
[4] http://www.w3.org/TR/css3-selectors/#target-pseudo
[5] http://www.w3.org/Style/CSS/Test/
[6] http://www.w3.org/Style/CSS/Test/CSS1/current/
[7] http://www.w3.org/Style/CSS/Test/CSS3/Selectors/current/
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 31 October 2004 08:45:35 UTC