This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22457 - Issues with the section on view elements.
Summary: Issues with the section on view elements.
Status: NEW
Alias: None
Product: SVG
Classification: Unclassified
Component: Linking (show other bugs)
Version: SVG 1.1 Full
Hardware: PC Windows NT
: P2 normal
Target Milestone: Test Suite
Deadline: 2018-12-30
Assignee: Doug Schepers
QA Contact: SVG Public List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-25 16:41 UTC by Paul LeBeau
Modified: 2018-12-01 21:31 UTC (History)
2 users (show)

See Also:


Attachments

Description Paul LeBeau 2013-06-25 16:41:51 UTC
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);
  ...
};
Comment 1 Robert Longson 2013-06-25 18:36:14 UTC
suggested actions 1 & 2 seem good but

3. Changing this would break existing content e.g. http://hoffmann.bplaced.net/svgtest/view01.svg

4. There is a DOM: http://www.w3.org/TR/SVG/linking.html#InterfaceSVGViewElement
Comment 2 Robert Longson 2013-06-25 20:13:31 UTC
To select a view you'd have to change the browser's URL (location.href) to something that pointed to the view so that's possible.