Shadow DOM serialization strategy is inconsistent with overall serialization philosophy |
||||
Issue descriptionDesign doc for the shadow DOM serialization: https://docs.google.com/document/d/1GrP-c7dOYv6JFyy6eOxF_xY39pRJvT4sRuc-xAhaDRM https://codereview.chromium.org/2912213002/ implemented support for serializing shadow DOM. However, the option we implemented is not consistent with how we generally implement serialization support. We currently require runtime fixups, which means the serialized page won't work correctly when loaded in other browsers, such as Safari. For everything else we serialize, we do extra work at serialization time to guarantee that the markup can interoperate reasonably well: - when serializing just <td></td> elements, we do extra work to make sure we include <table> and <tr> as well. - when serializing elements that inherit styles via classes, we inline the styles. Implementing the analogous approach for shadow DOM would mean implementing option 2 (Convert Shadow DOM CSS Pseudo-class Selectors), which would be more complex. However, I think this is the right long-term approach.
,
Sep 25 2017
Declarative Shadow DOM is under the discussion : https://github.com/whatwg/dom/issues/510
,
Oct 1 2017
I talked with hayato and it seems like there is currently no good solution for this. It's unfortunate, because it means we're stuck with a bit of code (that affects all loading paths) just to make shadow DOM work in MHTML. ... this makes me tempted to try to figure out how to execute JS in MHTML...
,
Oct 2 2017
If you are interested, we'd appreciate if you could input the MHTML use case at https://github.com/whatwg/dom/issues/510. That might be helpful for people to understand the need of Declarative Shadow DOM.
,
Oct 5 2017
Added to https://github.com/whatwg/dom/issues/510. Thanks for driving this.
,
Nov 21 2017
,
Dec 6 2017
Lower to Pri-3 since we don't have time to work this. |
||||
►
Sign in to add a comment |
||||
Comment 1 by jianli@chromium.org
, Sep 14 2017