Proposal: DocumentFragment.prototype.getElementByPart(name)

[clshortfuse]

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

[Jamesernator]

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>

[clshortfuse]

Thanks. That's my ignorance on this subject. I wasn't aware.

[clshortfuse]

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.