Because of how the browser DOM works, the above might cause operations on HTML Elements (or any of their ancestors) that make those elements lose their internal state (iframes will reload, video tags will reset playback...). The bug is not Flutter-specific, it's just that Flutter causes it because of the movements described above. In the HTML backend, elements rendered by the user won't be accessible from 3rd party scripts, unless they know they need to look inside of a Shadow Root to locate their targets#. Subtle styling differences because of the CSS reset present in the HTML backend, but not in CanvasKit. Embedded custom HTML nodes do not have a stable location for the developer to debug and manipulate them (e.g. when you right-click and inspect the Chrome DevTools element view loses track of the elements). A possible solution: WebComponents A possible solution to this problem comes from the Web Components suite of tools. Web Components allow for the creation of reusable custom elements# that can be utilized in web apps. Those custom elements may contain their own internal markup that is never exposed to the user (Shadow DOM) and parts of their content customized by the end user via "slots", like so: my-custom-component#Shadow Root

Title ...

Then the component can be used like so: #Shadow Root

This is the Title

Which will result in the h1 tag being rendered in place of the tag of the same name. Applying this to Flutter Web It turns out that it's not necessary to utilize full-blown Custom Elements (defined through the CustomComponentRegistry) for ShadowDOM and HTML Templates (slots) to work. As long as slotted content is a child of an element with ShadowDOM, tags will work#. This makes applying the above technique to Flutter Web relatively straightforward: Attach a Shadow Root to the flt-glass-pane element. Render the whole flutter application inside the flt-glass-pane shadow root, including: The flt-scene-host (where the pixels are pushed) The flt-semantics-host (where a11y happens) The flt-semantics-placeholder (to enable semantics) The flt-ruler-host (where text measurements happen) The default inputs/textareas required by the text editing system. When a platform view of "viewType" (defined by the user) is rendered: A tag with the passed-in name (viewType) is added into the right position of the scene by the framework (this'll end up inside the flt-scene-host, which is contained in the ShadowDOM of the flt-glass-pane). The actual contents of the platform view get a "slot" attribute added to them, with the value of viewType, and rendered as a child of the flt-glass-pane element ("a sibling" to its ShadowDOM). Ensure both the HTML and CanvasKit backends render platform views the same way. Most of the lifecycle and DOM attachment logic for platform views should be reusable. The main difference would only be the creation of the elements. OPEN QUESTIONS Are there implications to rendering performance for this approach? This changes the DOM structure of the app slightly; will (integration) tests / widget Finders be affected? What to do with the custom CSS stylesheets that we have now, and the resets for platform views? We'd need to split up the stylesheets into: rendering, accessibility and text layout. All the rendering parts would be moved into the flt-scene-host shadow DOM. The others can stay where they are. What happens when both the slot tag and its contents have positioning/sizing CSS applied to them? What gets applied to the rendered result? What happens with display:inline elements when rendered as a slot? Do they become display:block? Do they stay as inline? Will it work? REFERENCES See also: "DOM Stability" sections on the Scenelets proposal. TESTING PLAN The web engine has integration tests that run in different browsers. The new rendering approach might change the way some of our tests or test finders work, so we should ensure all current tests pass with minimal-to-no changes.