SVG 1.2 Comment: Detailed last call comments (addendum)

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