Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Thu, Nov 8, 2012 at 9:55 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> On Nov 8, 2012, at 2:15 AM, Elliott Sprehn <esprehn@gmail.com> wrote:
> On Thu, Nov 1, 2012 at 6:43 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>> On Nov 1, 2012, at 12:41 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> > For example, being able to re-render the page manually via DOM
>> > inspection and custom <canvas> painting code.  Google Feedback does
>> > this, for example.  If shadows are only exposed when the component
>> > author thinks about it, and then only by convention, this means that
>> > most components will be un-renderable by tools like this.
>>
>> As Adam Barth often points out, in general it's not safe to paint pieces
>> of a webpage into <canvas> without security/privacy risk. How does Google
>> Feedback deal with non-same-origin images or videos or iframes, or with
>> visited link coloring, to cite a few examples? Does it just not handle those
>> things?
>
> We don't handle visited link coloring as there's no way to get that from JS.
>
> For images we proxy all images and do the actual drawing to the canvas in a
> nested iframe that's on the same domain as the proxy.
>
> For cross domain iframes we have a JS API that the frame can include that
> handles a special postMessage which serializes the entire page and then
> unserializes on the other side for rendering. Thankfully this case is
> extremely rare unlike web components where it turns out you end up with
> almost the entire page down in some component or another (ex. <x-panel>,
> <x-conversation-view> …). This of course requires you to have control of the
> cross origin page.
>
> For an architectural overview of Google Feedback's JS HTML rendering engine
> you can look at this presentation, slides 6 and 10 explain the image proxy:
>
> http://www.elliottsprehn.com/preso/fluentconf/
>
>
> Are these types of workarounds adequate for the web components case? If not,
> why not?

No, it should be very obvious that you can't do similar workarounds.

The inability to detect history state is largely unimportant.  It's a
trivial loss for most use-cases in this area.

The workaround for the crossorigin security issue (by proxying images)
is completely inapplicable for Components.  With an image, you have
all the information you need right there at the DOM level - you grab
the URL, run a server-side proxy, and you're done.  That's the entire
content of the image.  There is obviously nothing similar for
components with hidden shadows.

~TJ

Received on Thursday, 8 November 2012 18:24:56 UTC