SVG target fragments issues

As mentioned in this weeks Agenda [1], I had come across a few other little
issues with respect to target fragments:

   - XPointer support
   - URL encoding of target fragments
   - Expected behavior of svgView fragments
   - Expected behavior when target fragments point to elements or views in
   nested SVGs

Detailed notes below.

--AmeliaBR

*XPointer support:*

The current text regarding fragment identifiers [2] uses an XPointer target
fragment in an example, but doesn't include it in the list of valid SVG
fragment types.
Decisions to make:

   - Should XPointer fragments be valid for SVG content?  As far as I can
   tell, they are not well implemented in browsers.
   - If so, how much of the XPointer scheme: bare names, positioning, or
   XPath? See [3] for links to the different XPointer specs

*URL encoding of fragments:*

The current text for svgView fragments includes the following two
paragraphs:

Spaces are not allowed in fragment specifications; thus, commas are used to
> separate numeric values within an SVG view specification (e.g.,
> #svgView(viewBox(0,0,200,200))) and semicolons are used to separate
> attributes (e.g.,#svgView(viewBox(0,0,200,200);preserveAspectRatio(none))
> ).
>


Semicolons used to separate 'SVGViewAttribute' in SVG fragments may be
> url-escaped (as %3B); this is useful when animating a (semi-colon
> separated) list of URLs because otherwise the semicolon would be
> interpreted as a list separator.


There are a couple things wrong with that.

   - Although commas are normally interchangeable with whitespace in
   `viewBox`, they aren't in `preserveAspectRatio`.
   - Most browsers accept whitespace and auto-escape it.  In my testing,
   using plain space characters was the best-supported option for
   setting `preserveAspectRatio`.
   - Explicitly URL-encoding whitespace OR semicolons doesn't work in some
   browsers: either the browsers are double-encoding it or they aren't
   decoding it before interpreting it.

A test case is attached (svgViewFragmentEncoding2.html).  I tried four
different ways of dealing with the whitespace:

   - leave it as is -- supported in all browsers tested (IE, Firefox, Blink)
   - use URL-encoding (%20) -- supported in IE and Firefox
   - using a comma -- supported in IE
   - no delimitor, just one token after another -- supported in IE and Blink

I suspect Safari will be the same as Opera/Chrome, but haven't tested to
confirm.

My recommendation:

   - The specs should clearly state that target fragments *may* be
   URL-encoded, and that browsers *should* apply a URL-decoding algorithm
   before interpretting the fragment.
   - The text relating to spaces and commas should be changed.

*Expected behavior of svgView fragments:*

Blink browsers currently discard the viewBox on the root element if an
svgView fragment is used without a viewBox parameter -- see Chromium Issue
444553 [4] -- which is why the fragments in the previous test page also
specify the viewBox.  In contrast, other browsers use the same behavior as
for <view> elements, only replacing the specified attributes.

See svgViewFragmentReset.html -- Blink browsers treat the SVGs as if they
had no viewBox, and therefore no scaling.

My recommendation: The language for svgView should be updated to match the
language for <view> elements (i.e., to clarify that the Blink behavior is
incorrect).

*Targetting elements and views in nested SVGs:*

The current language is that "the closest ancestor ‘svg
<https://svgwg.org/svg2-draft/struct.html#SVGElement>’ element is displayed
in the viewport" when the target fragment is an element ID (whether that
element is a <view> or not).  This does not seem to be supported in
browsers.

   - Do we want this behavior?  It could be useful for SVG sprite files --
   instead of declaring separate <view> elements and viewTarget, you could
   just use nested SVGs, and could directly target the element you wanted to
   display.
   - If so, can we make the normative requirement more explicit?

The "closest ancestor SVG" language is also used with respect to svgView
fragments.  I'm not sure if it makes any sense in that case.  I would
recommend changing it to "the root SVG element".

[1]: https://lists.w3.org/Archives/Public/www-svg/2015Mar/0009.html
[2]: https://svgwg.org/svg2-draft/linking.html#SVGFragmentIdentifiers
[3]: http://www.w3.org/XML/Linking
[4]: https://code.google.com/p/chromium/issues/detail?id=444553