- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 23 Nov 2004 11:23:01 +0000 (UTC)
- To: www-svg@w3.org
Further comments on SVG 1.2 last call. 1. There has been implementation feedback from Opera [1], Apple [2], and Mozilla [3] to the effect that the proposed line layout algorithm in chapter 4 would negatively impact integration of SVG and CSS line layout code. 2. The line layout algorithm in chapter 4 is not compatible with the CSS line layout algorithm. If multiple line layout must be included in SVG, then please normatively reference the CSS algorithm directly. (An example of this incompatibility is at the end of [1].) 3. There has been implementation feedback from Opera [4], Inkscape [5], and Adobe [6] to the effect that the proposed line layout algorithm is too restricted for high quality work, preventing high-quality implementations from using adaptive balancing justification algorithms and hyphenation. I would request that UAs be allowed to use higher quality line breaking algorithms. 4. The invention of new elements for text flow in chapter 4 prevents authors from complying to WCAG checkpoints 3.1, 3.6 and 3.7 when authoring multiline text in SVG. [7] There have been several proposals to address points 1 through 4. The first is my extension to 'overflow' which I included in my long technical comments under chapter 4 [8]. Unfortunately this is too heavy-duty for the simple use cases of multiline labels on a map (say). The second is to make it an authoring-time problem, and give authoring tools two new attributes with which to perform high-quality flowing [9]. That would prevent simple dynamic effects, though. A third possibility is to extend the existing SVG 1.1 text model to have a way to give explicit text paths for each line, with the path linking to the next one somehow [10]. I personally prefer this third solution. 5. (This is really an open issue for SVG 1.1, but it would be nice for SVG 1.2 to address this.) It is unclear whether leading and trailing spaces on attributes are in error or not. See [11]. 6. The image/svg+xml MIME type should have a "charset" parameter so that it can be handled consistently whether UAs support that MIME type directly or just via RFC3023 support. 7. It should be made clearer that namespace declarations must be provided either directly or via default attributes declared in the internal subset of the DTD, without relying on the DTD (in SVG 1.1) or the Schema (in SVG 1.2). (This would just be repeating what it already says in XMLNS section 4, "Namespace Constraint: Prefix Declared" paragraph 2, but I think it is worth repeating as it is such a common mistake for authors to make.) 8. It should be made clearer that UAs must not assume the SVG namespace on the root element if it has been omitted, even if that element is has a local name of "svg" and the MIME type is image/svg+xml. (There is nothing that says that they _can_ assume that, as far as I can tell, but this is a common bug in SVG UAs.) 9. Now that SVG does not have a DOCTYPE, attribute defaulting is no longer achieved by the DTD, which means that elements have no other attributes than those that are explicitly set. According to XLink, an XLink is only a link if it has the "xlink:type" attribute set to "simple". Does that mean that every element that is a link (and takes xlink:href) must not explicit have xlink:type="simple" specified? If not, does this mean SVG is not an XLink application but merely reuses attributes from the XLink namespace while changing their semantics? The same applies to all the other defaulted attributes ("xlink:actuate", for instance). (This was already possible in SVG 1.1 by omitting the DOCTYPE, but behaviour in that case was under-defined. Since that is now the only case, the problem is more serious.) In addition, I stand by the issues I raised in my technical last call comments [8]. Note that many of those issues were originally raised back in May [3], and many have also been raised by others [12]. These comments are therefore not new, and should not be ignored on the basis that they were sent too late in the cycle. I will also be interested in reading the working group's response to these other last call comments: http://lists.w3.org/Archives/Public/www-svg/2004Nov/0243.html http://lists.w3.org/Archives/Public/www-svg/2004Nov/0173.html http://lists.w3.org/Archives/Public/www-svg/2004Nov/0214.html http://lists.w3.org/Archives/Public/www-svg/2004Nov/0002.html http://lists.w3.org/Archives/Public/www-svg/2004Nov/0419.html http://lists.w3.org/Archives/Public/www-svg/2004Nov/0429.html http://lists.w3.org/Archives/Public/www-svg/2004Nov/0427.html http://lists.w3.org/Archives/Public/www-svg/2004Nov/0426.html http://lists.w3.org/Archives/Public/www-svg/2004Nov/0430.html -- References -- [1] http://lists.w3.org/Archives/Public/www-svg/2004Nov/0011.html [2] http://lists.w3.org/Archives/Member/w3c-svg-wg/2004OctDec/0701.html [3] http://lists.w3.org/Archives/Public/www-svg/2004May/0019.html [4] http://lists.w3.org/Archives/Public/www-svg/2004Nov/0103.html [5] http://lists.w3.org/Archives/Public/www-svg/2004Nov/0112.html [6] http://lists.w3.org/Archives/Public/www-svg/2004Nov/0213.html [7] http://www.w3.org/TR/WAI-WEBCONTENT/#tech-use-markup [8] http://lists.w3.org/Archives/Public/www-svg/2004Oct/0144.html [9] http://lists.w3.org/Archives/Public/www-svg/2004Nov/0101.html [10] http://lists.w3.org/Archives/Public/www-svg/2004Nov/0109.html [11] http://lists.w3.org/Archives/Public/www-svg/2004Sep/0160.html [12] http://lists.w3.org/Archives/Public/www-svg/2004Nov/0243.html -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 23 November 2004 11:23:04 UTC