{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/svgwg/issues/206","repository_url":"https://api.github.com/repos/w3c/svgwg","labels_url":"https://api.github.com/repos/w3c/svgwg/issues/206/labels{/name}","comments_url":"https://api.github.com/repos/w3c/svgwg/issues/206/comments","events_url":"https://api.github.com/repos/w3c/svgwg/issues/206/events","html_url":"https://github.com/w3c/svgwg/pull/206","id":165447650,"number":206,"title":"Use element re-write & related changes","user":{"login":"AmeliaBR","id":9876129,"avatar_url":"https://avatars.githubusercontent.com/u/9876129?v=3","gravatar_id":"","url":"https://api.github.com/users/AmeliaBR","html_url":"https://github.com/AmeliaBR","followers_url":"https://api.github.com/users/AmeliaBR/followers","following_url":"https://api.github.com/users/AmeliaBR/following{/other_user}","gists_url":"https://api.github.com/users/AmeliaBR/gists{/gist_id}","starred_url":"https://api.github.com/users/AmeliaBR/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/AmeliaBR/subscriptions","organizations_url":"https://api.github.com/users/AmeliaBR/orgs","repos_url":"https://api.github.com/users/AmeliaBR/repos","events_url":"https://api.github.com/users/AmeliaBR/events{/privacy}","received_events_url":"https://api.github.com/users/AmeliaBR/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/w3c/svgwg/labels/agenda+","name":"agenda+","color":"d4c5f9"},{"url":"https://api.github.com/repos/w3c/svgwg/labels/Document%20structure%20chapter","name":"Document structure chapter","color":"009800"},{"url":"https://api.github.com/repos/w3c/svgwg/labels/Needs%20WG%20input","name":"Needs WG input","color":"006b75"},{"url":"https://api.github.com/repos/w3c/svgwg/labels/SVG%202","name":"SVG 2","color":"5319e7"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":{"url":"https://api.github.com/repos/w3c/svgwg/milestones/1","html_url":"https://github.com/w3c/svgwg/milestones/CR","labels_url":"https://api.github.com/repos/w3c/svgwg/milestones/1/labels","id":1737671,"number":1,"title":"CR","description":"","creator":{"login":"nikosandronikos","id":4891471,"avatar_url":"https://avatars.githubusercontent.com/u/4891471?v=3","gravatar_id":"","url":"https://api.github.com/users/nikosandronikos","html_url":"https://github.com/nikosandronikos","followers_url":"https://api.github.com/users/nikosandronikos/followers","following_url":"https://api.github.com/users/nikosandronikos/following{/other_user}","gists_url":"https://api.github.com/users/nikosandronikos/gists{/gist_id}","starred_url":"https://api.github.com/users/nikosandronikos/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nikosandronikos/subscriptions","organizations_url":"https://api.github.com/users/nikosandronikos/orgs","repos_url":"https://api.github.com/users/nikosandronikos/repos","events_url":"https://api.github.com/users/nikosandronikos/events{/privacy}","received_events_url":"https://api.github.com/users/nikosandronikos/received_events","type":"User","site_admin":false},"open_issues":26,"closed_issues":50,"state":"open","created_at":"2016-04-29T00:11:55Z","updated_at":"2016-07-19T03:31:38Z","due_on":"2016-06-22T22:00:00Z","closed_at":null},"comments":2,"created_at":"2016-07-13T23:55:08Z","updated_at":"2016-07-20T07:08:15Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/w3c/svgwg/pulls/206","html_url":"https://github.com/w3c/svgwg/pull/206","diff_url":"https://github.com/w3c/svgwg/pull/206.diff","patch_url":"https://github.com/w3c/svgwg/pull/206.patch"},"body":"## Overview\r\n\r\nRe-write all text related to `<use>` element \r\nto be compatible with shadow DOM,\r\nto define all the aspects of use elements that are currently undefined\r\n(including those we'd added warnings about last year),\r\nand to address various related issues.\r\n\r\nTo make it easier to review, I've pushed a built version of the changes to my GitHub Pages branch.  \r\n\r\n**Major changes are in the section on the [Use element](https://ameliabr.github.io/svgwg/build/publish/struct.html#UseElement).**  \r\n\r\nOther changes include:\r\n\r\n- [Symbol element](https://ameliabr.github.io/svgwg/build/publish/struct.html#SymbolElement)\r\n- [Symbol & Use-related interfaces](https://ameliabr.github.io/svgwg/build/publish/struct.html#InterfaceSVGSymbolElement)\r\n- [rendering re-used graphics](https://ameliabr.github.io/svgwg/build/publish/render.html#ReusedGraphics) (and some other definitions tweaked in that chapter)\r\n- [clarifying context keywords in \"Specifying Paint\"](https://ameliabr.github.io/svgwg/build/publish/painting.html#context-paint)\r\n- [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.\r\n\r\nSee 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.\r\n\r\n## Breaking Changes from SVG 1.1\r\n\r\nMany of these features were never implemented to the SVG 1.1 spec in Firefox; in Blink, some SVG 1.1 aspect were previously implemented but have since been changed (to be closer to the new shadow DOM model).\r\n\r\n- Use element shadow trees now consist of actual SVGElement objects in a proper shadow DOM node tree, not SVGElementInstance pseudo-nodes.\r\n\r\n- The root of the shadow tree is a ShadowRoot object.\r\n\r\n- Events bubbling out of a use-element shadow tree must follow the shadow DOM re-targetting rules.\r\n\r\n- 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.\r\n\r\n- Some interactive animations are now triggered independently on the shadow content vs the referenced graphics.\r\n\r\n-  Never-rendered elements will now have a computed style of `display: none`.  Rendering shouldn't change.\r\n\r\n## Other new requirements & functionality\r\n\r\n- The shadow tree must now have a ShadowRoot object, and implement extra functionality from shadow DOM specs.\r\n\r\n- 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.\r\n\r\n- All elements in a subtree must now be cloned, not only graphics elements.\r\n\r\n- The shadow tree has scoped stylesheets.\r\n\r\n- Symbol elements can have x/y/width/height properties.\r\n\r\n- SVGElement has been extended to replace the core functionality from SVGElementInstance.\r\n\r\n- SVGSymbolElement now inherits from SVGGraphicsElement (so you can call `getBBox`, etc., on a symbol instance)\r\n\r\n## Clarified requirements (undefined or inconsistently implemented from SVG 1.1)\r\n\r\n- 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.\r\n\r\n- External files do not have to be .svg files, so long as the referenced element can be a child of an SVG container element.\r\n\r\n- 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.\r\n\r\n- A use-element shadow tree must not be generated if the ‘use’ element is excluded because of conditional processing.\r\n\r\n- 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.\r\n\r\n- Animation elements that are triggered by an event on another element are also triggered by that event on an instance of the other element.\r\n\r\n- Event listeners defined with `addEventListener` are copied to instances, the same as event attributes.\r\n\r\n\r\n\r\n## Clarifications or changes from previous drafts of SVG 2\r\n\r\n- All aspects of use elements referencing external resources are now defined, so no warnings are required.  (Except re CORS, I haven't changed that.)\r\n\r\n- 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.\r\n\r\n- audio and video elements have additional requirements to maintain synchronization.\r\n\r\n- 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.\r\n\r\n- Role mappings for `symbol` and `use` have been changed to reflect that use-element shadow content must be fully accessible.\r\n\r\n- 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.\r\n\r\n## Issues Addressed\r\n\r\nWhen merged, this pull request:\r\n\r\n- 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.\r\n\r\n- 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>`.\r\n\r\n- 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.\r\n\r\n- Closes #183, \"Define whether <use> shadow tree is interactive\" by making it fully interactive and accessible, but still read-only.\r\n\r\n- Closes #192, \"Use !important UA stylesheet rule to override display property for never-rendered elements\", by doing so.\r\n\r\n- Closes #203, \"Clarify meaning of context-fill & context-stroke keywords in paint definitions\", by making the cross-links and wording tweaks I discussed there.\r\n\r\n## Issues Remaining\r\n\r\nMost of these are noted in the text:\r\n\r\n- 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.\r\n\r\n- 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\"?\r\n\r\n- 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.\r\n\r\n- Should there be some sort of load event that is dispatched after the use tree is successfully generated? If so, which event in particular?\r\n\r\n- 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).\r\n\r\n-  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.\r\n\r\n- 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.\r\n\r\n- 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!\r\n\r\n- 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.\r\n\r\n- 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.\r\n\r\n- 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.\r\n\r\n- 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.\r\n\r\n## Still To Do\r\n\r\n- Re-define paint server cross references in terms of shadow DOM trees. (see #121)\r\n\r\n- Add new examples of `use` elements in action.\r\n\r\n- Update the changes appendix."},"comment":{"url":"https://api.github.com/repos/w3c/svgwg/issues/comments/233860898","html_url":"https://github.com/w3c/svgwg/pull/206#issuecomment-233860898","issue_url":"https://api.github.com/repos/w3c/svgwg/issues/206","id":233860898,"user":{"login":"nikosandronikos","id":4891471,"avatar_url":"https://avatars.githubusercontent.com/u/4891471?v=3","gravatar_id":"","url":"https://api.github.com/users/nikosandronikos","html_url":"https://github.com/nikosandronikos","followers_url":"https://api.github.com/users/nikosandronikos/followers","following_url":"https://api.github.com/users/nikosandronikos/following{/other_user}","gists_url":"https://api.github.com/users/nikosandronikos/gists{/gist_id}","starred_url":"https://api.github.com/users/nikosandronikos/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nikosandronikos/subscriptions","organizations_url":"https://api.github.com/users/nikosandronikos/orgs","repos_url":"https://api.github.com/users/nikosandronikos/repos","events_url":"https://api.github.com/users/nikosandronikos/events{/privacy}","received_events_url":"https://api.github.com/users/nikosandronikos/received_events","type":"User","site_admin":false},"created_at":"2016-07-20T07:08:14Z","updated_at":"2016-07-20T07:08:14Z","body":"> Re resolving cross-references: 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.\r\n\r\nThis seems related to #90 \r\nIt would be nice to have in one place. I'd like to get some review from the HTML and DOM editors so maybe leave it for now and we'll see what they recommend."}}
{"actor":{"display_login":"nikosandronikos"}}