Closed clshortfuse closed 11 months ago
Because
[part]
is "just as unique" as[id]
Parts are in no way unique, you can have as many parts with the same name as you want:
<style>
#wrapper::part(someName) {
color: blue;
}
</style>
<div id="wrapper">
<template shadowrootmode="closed">
<!-- All of these elements will be styled by the ::part(someName) selector -->
<p part="someName">Part 1</p>
<p part="someName">Part 2</p>
</template>
</div>
Thanks. That's my ignorance on this subject. I wasn't aware.
There is a https://drafts.csswg.org/css-shadow-parts/#shadow-root-part-element-map and maybe there's some value in access to that map, but I'd have to reassess a new proposal with that in mind.
First off, this is not related to the DOM Parts API. This is related to the [part] attribute and
::part()
CSS syntaxEssentially, instead of my current structure is
Interpolate (once):
Store References (once per element):
Render
As it stands, there's only one DOM walk needed and it's on interpolation. While
getElementById
is faster, likely because it's indexed by the browser, than walking the nodes, using an XPath, orquerySelector([part="foo"])
, it gets convoluted when the ID is needed for anchor destinations (#hash
).Because
[part]
is "just as unique" as[id]
, but without the conflict with HTMLAnchorElement, it should be "just as good" asgetElementById
.I had considered if this should be on
ShadowRoot
's prototype, but that would mean you would have to attach it to theShadowRoot
first, before you can find the nodes. There is some value to do moreDocumentFragment
manipulation before landing on the active document.Mixing in with DOM-Parts could be interesting, though I'd imagine the API will get renamed before shipping: https://github.com/WICG/webcomponents/issues/902