Re: Removing the SVG instance tree (SVG2 issue 51)

Cameron,

I've uploaded my "<use> in web components" experiment to
https://github.com/progers/xuse/blob/master/xuse.js if you would like to
take a look. I'm not a web components expert and I was pleasantly surprised
at how straightforward it was. The <use> style inheritance examples in the
SVG spec worked immediately using
applyAuthorStyles<http://w3c.github.io/webcomponents/spec/shadow/#dfn-apply-author-styles>
(I
suspect shadow dom's style inheritance was partly based on the <use> spec :)

I did hit two minor web component issues that would be nice to address in
SVG2:
1) SVG should allow <shadow>.
The <shadow> element is spec'ed as
HTMLShadowElement<http://www.w3.org/TR/shadow-dom/#shadow-element>which
isn't allowed in the SVG namespace, preventing multiple shadow roots
in SVG. The main issue is similar to the other SVG+HTML element types such
as {SVG,HTML}ImageElement. Spec'ing this may not be as simple as allowing
HTMLShadowElement in SVG because we still need to ensure the elements in
the shadow match the namespace outside the shadow. I've temporarily filed
this as https://www.w3.org/Bugs/Public/show_bug.cgi?id=24181.

2) SVG should drop namespaced attributes (or web components should support
them).
It's not possible to distinguish xlink:href and href currently. I've
temporarily filed this as
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24181.

With these two issues fixed I think we could re-write the <use> section
entirely in terms of web components. I don't think object-fill or
object-stroke would be a problem.

Philip

On Tue, Jan 7, 2014 at 9:50 PM, Cameron McCormack <cam@mcc.id.au> wrote:

> Hi Philip,
>
>
> Philip Rogers wrote:
>
>> Can we remove the instance tree in SVG2?
>>
>
> I'm in favour of this.
>
>
>  Over the holidays I implemented SVG's <use> in terms of pure web
>> components. This works well and <use>+web components will vastly
>> simplify the SVG2 spec.
>>
>
> Great!  As you know we haven't yet made the corresponding spec changes.
>  Did you find anything special that we need to handle in the spec?  How
> does the styling inheritance work with <use> now in Blink?
>
> Is there any impediment to using object-fill, object-stroke, etc. in the
> definition and having them refer to the values of fill/stroke on the <use>
> element?
>
>
>  Can we unify on the event model used by shadow dom and drop the instance
>> tree?
>> http://www.w3.org/TR/components-intro/#events
>>
>
> That sounds sensible to me at first glance.
>
>