[WICG/webcomponents] Proposal: DocumentFragment.prototype.getElementByPart(name) (Issue #1021)

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: https://github.com/WICG/webcomponents/issues/902

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/1021
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/1021@github.com>