[svgwg] Pull Request: Use element re-write & related changes

AmeliaBR has just submitted a new pull request for 
https://github.com/w3c/svgwg:

== Use element re-write & related changes ==
## Overview

Re-write all text related to `<use>` element to be compatible with 
shadow DOM,
to define all the aspects of use elements that are currently undefined
(including those we'd added warnings about last year),
and to address various related issues.

To make it easier to review, I've pushed a built version of the 
changes
to my GitHub Pages branch.  **Major changes are in the section on the 
[Use 
element](https://ameliabr.github.io/svgwg/build/publish/struct.html#UseElement).**
  Other changes include:

- [Symbol 
element](https://ameliabr.github.io/svgwg/build/publish/struct.html#SymbolElement)
- [Symbol & Use-related 
interfaces](https://ameliabr.github.io/svgwg/build/publish/struct.html#InterfaceSVGSymbolElement)
- [rendering re-used 
graphics](https://ameliabr.github.io/svgwg/build/publish/render.html#ReusedGraphics)
 (and some other definitions tweaked in that chapter)
- [clarifying context keywords in "Specifying 
Paint"](https://ameliabr.github.io/svgwg/build/publish/painting.html#context-paint)
- [user agent style sheet now controls never-rendered 
elements](https://ameliabr.github.io/svgwg/build/publish/styling.html#UAStyleSheet);
 there are corresponding prose changes to the relevant element 
descriptions.

See below & issues in the text for some remaining questions.  Please 
**do not** merge until the issues I've added have been removed from 
the source code.

## Breaking Changes from SVG 1.1

Many of these features were never implemented to the SVG 1.1 spec in 
Firefox; some were but have since been changed in Blink.

- Use element shadow trees now consist of actual SVGElement objects in
 a proper shadow DOM node tree, not SVGElementInstance pseudo-nodes.

- The root of the shadow tree is a ShadowRoot object.

- Events bubbling out of a use-element shadow tree must follow the 
shadow DOM re-targetting rules.

- Styles rules are resolved independently for clones versus the 
referenced graphics; in some cases (particularly re interactive 
pseudo-classes), this will result in different styles than the SVG 1.1
 model.

- Some interactive animations are now triggered independently on the 
shadow content vs the referenced graphics.

-  Never-rendered elements will now have a computed style of `display:
 none`.  Rendering shouldn't change.

## Other new requirements & functionality

- The shadow tree must now have a ShadowRoot object, and implement 
extra functionality from shadow DOM specs.
- A new interface SVGUseElementShadowRoot is defined, inheriting from 
ShadowRoot, in case we want to add functionality later that is unique 
to use-element shadow trees.
- All elements in a subtree must now be cloned, not only graphics 
elements.
- The shadow tree has scoped stylesheets.
- Symbol elements can have x/y/width/height properties.
- SVGElement has been extended to replace the core functionality from 
SVGElementInstance.
- SVGSymbolElement now inherits from SVGGraphicsElement (so you can 
call `getBBox`, etc., on a symbol instance)

## Clarified requirements (undefined or inconsistently implemented 
from SVG 1.1)

- External files are processed in secure static mode, so scripts don't
 run and references to additional resources are not followed _unless_ 
the elements that reference those resources are actually cloned into 
this document.  Same-document style blocks, however, _are_ processed, 
and those style rules are copied over and must apply in the shadow DOM
 scope.  Media queries in those copied stylesheets are interpretted in
 the main document's media.  Animations do not run in the external 
document, but they _are_ copied over to the shadow tree, where they 
operate in the main document's timeline.

- External files do not have to be .svg files, so long as the 
referenced element can be a child of an SVG container element.

- Percentage lengths in shadow DOM content are resolved based on the 
coordinate system into which they are rendered, not based on the 
source.  This is _consistent_ with SVG 1.1 spec text, but inconsistent
 with implementations.

- A use-element shadow tree must not be generated if the ‘use’ element
 is excluded because of conditional processing.

- Web Animations API animations must be duplicated, in addition to 
animation element.  CSS animations & transitions are covered under the
 general stylesheet duplication, and so are not duplicated directly.

- Animation elements that are triggered by an event on another element
 are also triggered by that event on an instance of the other element.

- Event listeners defined with `addEventListener` are copied to 
instances, the same as event attributes.



## Clarifications or changes from previous drafts of SVG 2

- All aspects of use elements referencing external resources are now 
defined, so no warnings are required.  (Except re CORS, I haven't 
changed that.)

- refX, refY on `symbol` have an initial value of (none), different 
from a value of 0, to preserve backwards compatibility when the symbol
 has a viewBox.

- audio and video elements have additional requirements to maintain 
synchronization.

- A use element is _not_ automatically a stacking context.  Patterns, 
markers, etc. _are_ automatically isolation groups for blending.  
Previous draft of the rendering chapter tried to apply the same rules 
for both cases.

- Role mappings for `symbol` and `use` have been changed to reflect 
that use-element shadow content must be fully accessible.

- The `instanceRoot` (and `animatedInstanceRoot`) IDL properties have 
been restored on `SVGUseElement`.  The animated version is just an 
alias, there's no requirement to maintain multiple shadow trees.

## Issues Addressed

When merged, this pull request:

- Closes #99, "We should define the behavior of ‘use’ in terms of Web 
Components" by defining use elements in terms of shadow DOM, which is 
related to but not the same as web components.

- Closes #142, "Clarify what is the size of a use element if width and
 height are not specified", by allowing symbol elements to have 
geometric properties (x/y/width/height) and applying the same rules as
 for re-used `<svg>`.

- Closes #193, "Clarify effect of invalid values for width & height on
 <use> elements", by making negative values parse errors and by 
defining the impact of 0 in terms of the shadow element.

- Closes #183, "Define whether <use> shadow tree is interactive" by 
making it fully interactive and accessible, but still read-only.

- Closes #192, "Use !important UA stylesheet rule to override display 
property for never-rendered elements", by doing so.

- Closes #203, "Clarify meaning of context-fill & context-stroke 
keywords in paint definitions", by making the cross-links and wording 
tweaks I discussed there.

## Issues Remaining

Most of these are noted in the text:

- I would really, really prefer to have [x/y/width/height on `<use>` 
elements](https://ameliabr.github.io/svgwg/build/publish/struct.html#UseAttributes)
 be proper geometric properties, instead of simple attributes.  I just
 haven't quite figured out how that would conceptually work.  As is, 
it's going to be a surprise & a pain for authors who are going to want
 to control these properties with CSS.

- Re [`defs` 
element](https://ameliabr.github.io/svgwg/build/publish/struct.html#Overview):
  Is there any justification for continuing to recommend "that, 
wherever possible, referenced elements be defined inside of a ‘defs’ 
element"?

- Re [resolving 
cross-references](https://ameliabr.github.io/svgwg/build/publish/struct.html#UseHref):
  Should this section, or parts of it, be moved to the Linking 
chapter, and made to apply for all external resources (e.g., external 
paint servers, filters, etc.)? Also:  Do we need to reference 
specifics re fetching an external document and security modes? Related
 to #90.

- Should there be some sort of load event that is dispatched after the
 use tree is successfully generated? If so, which event in particular?

- Does it make sense that conditional processing stop formation of a 
use-element shadow tree? Consistent with audio/video not playing with 
conditional processing (see #44), and with the idea that it stops all 
processing (including fetching external resources), not only 
rendering.  (`display: none` does not prevent shadow tree formation).

-  Is `NoModificationAllowedError` the best choice for the error type 
whenever something is blocked by the read-only nature of the shadow 
tree? (Other options include ReadOnlyError and NotAllowedError.) Needs
 to encompass both DOM modification attempts as well as attribute or 
property changes.

- Should width & height on a use element affect foreignObject and 
embedded content? The section on establishing a new viewport also 
includes foreignObject, iframe, and image, although then it qualifies 
that for image and iframe the new viewport actually is created by the 
root element of the embedded document. Mostly, that whole section 
needs re-writing. But for this section: should auto width/height on a 
re-used foreignObject be influenced by width/height on the use 
element? SVG 1.1 didn't allow foreignObject to be re-used, so it would
 not be a breaking change either way.

- Should the details on how animations work in use shadow trees be 
moved to the SVG Animations specification and/or WAAPI? Most of the 
details are dependent on those specs. However, implementers that 
currently support SVG animation elements and Web Animations are going 
to need guidance on how to update those implementations to match the 
new shadow DOM model. Also, it would be nice to have a TR version of 
SVG Animations to link to!

- Is it going to be an implementation hassle to have detached Element 
objects (cloned animation elements that affect the shadow tree but 
aren't cloned as part of it) that must behave as if they are part of 
the node tree? Another option would be to actually make them 
additional child nodes of the ShadowRoot node. I don't think that 
would have any problematic side effects, although I'd need to change 
the wording a few places where I specify that the use-element shadow 
root only ever has one child.

- Is distinguishing between begin="target.event" and begin="event" 
worth the extra implementation complexity? It creates useful 
functionality and is consistent with the CSS model, but it is 
technically a breaking change from SVG 1.1.

- Re [SVGElementInstance 
mixin-interface](https://ameliabr.github.io/svgwg/build/publish/struct.html#InterfaceSVGElementInstance):
 Is it appropriate to define this as a [NoInterfaceObject] interface? 
As defined in this spec, the interface is only used to supplement 
SVGElement. But SVG 1.1 scripts could be explicitly testing for the 
presence of Window.SVGElementInstance to determine if the browser 
supports an inspectable use-element shadow DOM.

- Re 
[SVGElementInstance::correspondingElement](https://ameliabr.github.io/svgwg/build/publish/struct.html#__svg__SVGElementInstance__correspondingElement):
 Should this still point to a valid element object even if it is in a 
different document? That implies that the entire DOM of the external 
file must be maintained in memory (since the element linked from this 
property would be linked to all other nodes in its DOM tree). I've 
already said that that external DOM is read-only, so there's no real 
function to having it available.

## Still To Do

- Re-define paint server cross references in terms of shadow DOM 
trees. (see #121)

- Add new examples of `use` elements in action.

- Update the changes appendix.

See https://github.com/w3c/svgwg/pull/206

Received on Wednesday, 13 July 2016 23:55:22 UTC