Interoperability and Compatibility
The main interoperability risk would be that other browsers fail to implement this API. This feature is roughly polyfillable, so it should still be usable while other implementations are being completed.
Gecko:
Some conversation, no conclusionsWebKit:
Some comments, no conclusionsWeb developers: Positive See many comments from developers on the prior thread resolving *not* to move forward with declarative Shadow DOM. Most are positive and want a solution to this problem. Start after this comment:
https://github.com/whatwg/dom/issues/510#issuecomment-370980398Ergonomics
Much thought has been given to the ergonomics of this API. A more ergonomic alternative, that of a new <shadowroot> element, would create significant web compat problems for browsers that do not yet support the new element. The biggest risk of the current proposal is that it does not *also* solve the declarative adoptedStylesheets problem. That is, to include stylesheets within declarative shadowroots, inline <style> elements must be used. That isn't as large of a penalty as it would seem, but it is a stumbling block. See
https://github.com/whatwg/dom/issues/831#issuecomment-585451735, point #3 for more discussion of this issue.
Activation
This feature is rather polyfillable - see
https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md#feature-detection-and-polyfilling. However, any such polyfill would require Javascript to work, and the prime motivation for this feature is no-JS SSR. However, for sites that want to use Web Components and Shadow DOM, it would seem that such a polyfill could be written in a way that does not impact performance for browsers that have implemented this proposal, and does no worse for browsers that have not yet supported this API.
Security
The prior implementation of <template> caused significant parser security issues. While this proposal attempts to re-use as much as possible of the existing <template> implementation, there are a few required changes. It is possible that those changes introduce new security holes. Additionally, the existing implementation of <template> could also still contain undiscovered security problems.