- 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