- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 24 Nov 2004 21:57:34 -0600
- To: www-svg@w3.org
It's not clear to me why this is being introduced in the context of a vector graphics specification. It's also not clear which profiles require this functionality. That should be clearly documented, instead of the vague comments about profiles being able to redefine anything they want about what support is required (which is what section 12.1.1 says now). Apart from the fact that I strongly feel that I should be able to implement a vector graphics language for web use without implementing audio support, and thus feel that this section does not belong in SVG, I have the following comments: 12.1: The prose mentioning "SMIL animation features" should link to where said features are defined, or at the very least normatively reference a specific SMIL version (the former would be far preferable, using a dated link). I don't see the "volume" attribute defined anywhere. Nor do I see a "type" attribute defined. Nor "repeatCount". There is no 'attlist.audio', which is referenced by the RelaxNG schema, in sight. If it's defined elsewhere, it should be linked to. The SVGAudioElement interface does not describe what the "audio" property is, whether it must always be non-null or is allowed to be null, what it returns if the audio resource could not be retrieved. There is no link the the SVGMediaElement definition. I cannot find this definition in either SVG 1.1 or SVG 1.2. The interface definition is inconsistant with that given in Appendix A (and the latter is mis-named "SVGAudiolement"). There is no definition of the SVGAudio interface here and no link to the place where the definition is given. One or the other should be present. I stopped looking at this section at this point, because it's clear that it's just not finished. I'm not sure why it was proposed for last call... To summarize, neither the content model or the DOM interface is described in anything resembling the level of detail that is needed to implement this interoperably without reverse-engineering other specifications. I'd like to request that something other than examples be written for this section of the specification before it goes to CR, if it is not removed altogether per my first comment. 12.2: Again, please link and/or normatively reference exactly which SMIL features are being imported. "The usual features" just doesn't cut it as a specification of UA behavior. Please link the refs in the attlist.video define to the places where they are actually defined. As things stand, it would take me a good deal of time to look up where all those lists are defined, such that I would know what attributes a <video> can be expected to have. I'm not sure what the point of the paragraph after the RelaxNG definition is. It's not normative, it's not particularly informative, and it simply sounds like the working group trying to convince the world that this section of the spec is really OK to have... 12.3.1: There is no definition of exactly what the children of a multiImage element should look like. Defining such things through examples, which is what section 12.3 does, really doesn't cut it. Please provide the RelaxNG schema and a lucid prose description of the functionality. Again, please link to the relevant SMIL specifications. 12.3.2: Where are min-pixel-size/max-pixel-size defined? Please link to the definitions here. Please clearly explain what those attributes do in this context. What happens if a subImageRef has children? Are they rendered? 12.3.3: Can a subImage contain a multiImage? 12.3.4: This section, which explains how all this stuff works, should probably come after the RelaxNG definitions and after a very brief prose passage outlining the overall setup, but before the examples. It's not clear to me whether min/max-pixel-size may be specified in any units desired or only in user units. This needs to be documented. Are the ranges defined by the min/max-pixel-size values exclusive or inclusive? That is, if I have two subImageRef children, one with min-pixel-size="1px" and one with max-image-size="1px", will both of those children be considered to contain the current resolution in their range? Or will it be neither? Or only one? If so, which one? What is the metric used to measure the distance between a range and the current resolution, especially for ranges that contain the current resolution (needed to resolve conflicts when multiple ranges overlap the current resolution)? 12.4: It's not clear to me what the dB change in signal level = 20 * log10(vol) formula means. Change from where? The default volume of the element? If so, say so, please. Clearly this algorithm cannot be applied when vol == 0; that should be made clearer. "all children" should be "all child" 12.5: If images are allowed to not be loaded (or even if they're not allowed, since DOM access can happen at any time), the specification needs to document the behavior of the image DOM interfaces (which allow access to image data, if I understand them correctly) in a lot more detail. -Boris
Received on Thursday, 25 November 2004 04:02:38 UTC