Re: [w3c/webcomponents] shadow tree -> iframe <- contentWindow.frameElement encapsulation issue (#507)

Sorry, I thought I'd replied to this.  

I still don't think @rniwa's solution is great.  It partially solves the problem, but consider that I create a custom component that uses an iframe and I give that component to one of you guys.  The shadow dom used by the component is closed so that you can't manipulate the contents and I comfortably know that I can make updates without breaking your page.  You use the component to load some content but you don't quite like the style of the component, but instead of asking me to add a new feature, you decide to hack something in yourself.  From within the loaded content, you access `window.frameElement` and change something with the 'innerHost'.  Now updates to my component risk conflicts with your hack which could potentially break something.

An API to change where `frameElement` points to would be fine.  In reality, this is another part of the awkwardness of trying to do things with iframes before their document scripts run, which I raised over at https://github.com/whatwg/html/issues/2161.  If WebKit fixed the non-configurable issue and there were easier ways to customise iframes before script elements are run then I suppose this wouldn't be needed.  Unfortunately, that issue also went stale.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/507#issuecomment-327422445