PolymerElements / iron-iconset-svg

Represents a source of icons expressed as a collection of inline SVGs
https://www.webcomponents.org/element/PolymerElements/iron-iconset-svg
37 stars 34 forks source link

"id" pollutes global namespace #17

Open davidmaxwaterman opened 9 years ago

davidmaxwaterman commented 9 years ago

It seems to me this issue still applies :

https://github.com/Polymer/core-iconset-svg/issues/3

Is it not trivial to use some other attribute than 'id' to avoid conflicts with other ids used in the DOM?

notwaldorf commented 8 years ago

This isn't really a problem in the shadow DOM, since elements are scoped (so the 'id' is only scoped to that particular instance of iron-iconset-svg.). It is true that in the shady DOM we don't have this scoping, but we are working under the assumption that the shadow DOM is coming in all the browsers, and we are working with that future in mind -- in which case, in that future, this polluting will no longer happen.

davidmaxwaterman commented 8 years ago

Are you sure? It seems to me that the elements using 'id' are in light dom not shadow dom.

Please correct me if I'm wrong.

arthurevans commented 8 years ago

So, after some investigation on the Slack, we came to this conclusion:

FWIW, it appears to me that using IDs for SVG defs is the standard way to reference defs (and possibly the only way? I'm not sure):

http://www.w3.org/TR/SVG11/struct.html#Overview

The questions are:

Copying @azakus who's familiar with both the iconsets and vulcanize ...

arthurevans commented 8 years ago

Handing this over to himself. If you think this is just something we should doc & live with, go ahead and assign it back to me and I'll Make It So.

notwaldorf commented 8 years ago

We should consider using an alternate attribute for the unique ID (maybe name?)

touhonoob commented 5 years ago

This issue still persists with Polymer 3.0