Intent to Prototype: DOM Parts
Mason Freed
Contact emails
mas...@chromium.orgExplainer
https://github.com/tbondwilkinson/dom-parts#readmeSpecification
NoneSummary
In many applications and frameworks, JavaScript code needs to locate and mutate a set of "nodes of interest." The current methodology for finding "nodes of interest" is either a full DOM tree walk or DOM queries, and for updating either that walk is repeated or the "nodes of interest" are then retained in JavaScript data structures or as properties on the DOM objects. There are two major drawbacks to these solutions: 1. DOM mutating methods like clone() are not aware of in-memory references to cloned nodes or special JavaScript properties. They can only clone the HTML content itself. 2. The DOM walks for locating nodes often occur immediately after the browser has already performed that same DOM walk, for example during HTML rendering of the document or <template> nodes. The DOM Parts API is intended to assist in locating, storing, and updating these nodes with new primitives that identify nodes and ranges of nodes at parse time and an imperative API to retrieve, walk, and update these nodes.
Blink component
Blink>DOMMotivation
See the overall description of the feature for the general motivation. The perceived benefits of such an API are enhanced speed and reduced JS code size for framework code.
Initial public proposal
https://github.com/WICG/webcomponents/issues/990Search tags
Template Instantiation, DOM PartsTAG review
TAG review status
PendingRisks
Interoperability and Compatibility
Gecko: No signal
WebKit: No signal
Web developers: No signals
Other signals:
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
Debuggability
Is this feature fully tested by web-platform-tests?
NoFlag name
Requires code in //chrome?
FalseTracking bug
https://crbug.com/1453291Estimated milestones
No milestones specified