[Bug 22457] New: Issues with the section on view elements.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22457

            Bug ID: 22457
           Summary: Issues with the section on view elements.
    Classification: Unclassified
           Product: SVG
           Version: SVG 1.1 Full
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Linking
          Assignee: schepers@w3.org
          Reporter: paul.lebeau@gmail.com
        QA Contact: www-svg@w3.org

1. The Linking section is very web centric and assumes that Views are always
targets of a link.  It doesn't allow for the fact that a non-web renderer might
use views to render selected parts of a document.

2. Because of #1, important explanations of how views should be handled are
buried in the section on fragment identifiers.

   For example the second bullet in the list at the end of section 17.3.2
contains (among other things) the following important information:

   "Any view specification attributes included on the given ‘view’ element
override the corresponding view specification attributes on the closest
ancestor ‘svg’ element."

   Which brings us to point 3

3. No renderer that I have tried follows this instruction.  FF, IE, Chrome and
Batik all apply the viewBox to the *outermost* <svg> element.

   Since this part of the spec seems to be ignored by the majority of
renderers, there is maybe a case for altering the requirement.

4. Having a <view> viewBox override an ancestor <svg> viewBox can significantly
alter the layout of an SVG document.  It changes what "100%" means.  This IMO
is very counter-intuitive.  However I realise that changing this behaviour is
unlikely because it would break backwards-compatibility.


Suggested actions for consideration.

1. Expand section 17.3.3 with a better explanation of the purpose of Views and
include any important information on rendering behaviour (such as the override
requirement).  Allow for the fact that non-browser renderers may be using
Views.

2. Change "closest ancestor svg element" to "outermost ancestor svg element" in
the section described above (17.3.2 bullet two) to match real world practice.

3. Consider altering the semantics that state that view element attributes
override the svg attributes.  A view should be a view onto an SVG document and
should not alter the layout of the document.

4. There is a DOM interface for SVGViewElement but I don't see any function for
selecting a view.  Should there be?  For instance:

interface SVGDocument : Document, DocumentEvent {
  ...
boolean selectView(in SVGViewElement v);
  ...
};

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 25 June 2013 16:41:53 UTC