Proposal: DocumentFragment.prototype.getElementByPart(name)
clshortfuse opened this issue · comments
First off, this is not related to the DOM Parts API. This is related to the [part] attribute and ::part()
CSS syntax
Essentially, instead of my current structure is
Interpolate (once):
- Walk document fragment tree
-
- autogenerate an ID to each node that will be referenced later if non available
- Store interpolated fragment
Store References (once per element):
- clone interpolated fragment
- find to-be-referenced nodes by fragment.getElementById(name)
- store reference of nodes
- remove ID if it was autogenerated
- append clone to ShadowRoot
Render
- use node reference list to update DOM
- allow attributeChangedCallback to fire
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, or querySelector([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" as getElementById
.
I had considered if this should be on ShadowRoot
's prototype, but that would mean you would have to attach it to the ShadowRoot
first, before you can find the nodes. There is some value to do more DocumentFragment
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: #902
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.