Support setting $.html() on shadow roots
|Reported by:||jan@…||Owned by:|
The forthcoming public support for Shadow DOM components (https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html) in Google Chrome opens up the possibility of creating reusable web UI components. To date, nearly all Shadow DOM examples use the native DOM API, but it should be possible to use jQuery for this purpose. As it turns out, jQuery is already very nearly able to manipulate the contents of a Web Component. A small change to core.js will enable proper support.
Example: http://jsfiddle.net/Jan_Miksovsky/y9hSm/ This fiddle creates a very basic Web Component that adds some simple text to its content. When viewed in a production browser, the fiddle will display a simple list of names like "Ann". When viewed in a Shadow DOM-capable browser like Google Canary (or, I believe, beta channel), the fiddle will display additional text around each name: "Hello, Ann."
This is done by creating a shadow root, then setting its innerHTML to "Hello <content></content>". It's not possible in jQuery 1.9 to directly manipulate the innerHTML of a shadow root using html(). The issue is that core.js checks to make sure that the nodeType of an element being manipulated by html() is of nodeType 1 (element). However, a shadow root is actually of nodeType 11 (document fragment). Unlike normal document fragments, shadow roots expose an innerHTML property just like regular HTMLElement nodes.
I have a small fix and accompanying unit test for this, and am filing this bug in preparation for a pull request. (This fix is applied in the private jquery.js used in the fiddle.) This fix updates the check in core.js to permit shadow roots. With that, html() can directly manipulate the innerHTML of shadow roots — that is, Web Component content — correctly. (To see the effects of such manipulation in Google Canary, be sure to turn on "Show Shadow DOM" in the Chrome debugging tools.)
Shadow DOM support will likely land in production Chrome in the not-too-distant future, followed by Mozilla later this year, so this seems like a proactive time to make this fix (or something similar that accomplishes the same objective). This fix doesn't require Shadow DOM support, and in fact doesn’t directly test for Shadow DOM; it should be backward compatible with other browsers, and safe to roll out at any point, even before Shadow DOM-capable browsers become widespread.
Change History (11)
comment:7 Changed 4 years ago by dmethvin
- Component changed from unfiled to manipulation
- Priority changed from undecided to low
- Status changed from new to open
comment:10 Changed 4 years ago by dmethvin
- Resolution set to plugin
- Status changed from open to closed