W3C home > Mailing lists > Public > www-style@w3.org > July 2012

Re: [css-regions] Shadow DOM and Regions CSSOM

From: Dimitri Glazkov <dglazkov@chromium.org>
Date: Tue, 24 Jul 2012 11:19:10 -0700
Message-ID: <CADh5Ky0eH+rncPV5QpZEAKO7ZsQosWSOgct7Vt4Joh4xf6qmvQ@mail.gmail.com>
To: Andrei Bucur <abucur@adobe.com>
Cc: "www-style@w3.org" <www-style@w3.org>, Alan Stearns <stearns@adobe.com>
Hmm... My initial reaction is that something doesn't add up. Everywhere
else, we were able to enforce the encapsulation boundaries. What makes the
regions so different?

Also -- would insertion point-style approach work here?

:DG<


On Tue, Jul 24, 2012 at 7:37 AM, Andrei Bucur <abucur@adobe.com> wrote:

> Hello Dimitri,
>
> From my understanding, the bug
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15444 is concerned more
> about not leaking the in-shadow selection to the out-of-shadow context.
> For regions, it's obvious the NamedFlow APIs on Document should not leak
> DOM nodes found inside the shadow boundaries. However, there's more to
> that in the context of having content inside the Document and the regions
> inside the shadow DOM. Conceptually the NamedFlow objects exist across
> boundaries and there are use cases when an author would want to
> dynamically alter the region chain of a named flow.
> Imagine a widget (in shadow) that displays an article (from the Document)
> using CSS Regions. Based on the overset properties of the
> NamedFlow/Regions the widget scripts would create or destroy items in the
> region chain. This is not possible without exposing information about the
> NamedFlow inside the shadow tree.
>
> Thanks,
> Andrei.
>
> On 6/22/12 7:23 PM, "Dimitri Glazkov" <dglazkov@chromium.org> wrote:
>
> >On Thu, Jun 21, 2012 at 1:29 PM, Alan Stearns <stearns@adobe.com> wrote:
> >
> >> Since CSS Regions does not depend on Shadow DOM functionality, I'm not
> >> sure it makes sense to define additions to the ShadowRoot interface in
> >>our
> >> spec. Of course, the Shadow DOM spec does not depend on CSS Regions, so
> >> I'm not sure it makes sense to add Regions-specific APIs in their spec,
> >> either. But it should go somewhere, as I want to ensure that our OM is
> >> compatible with theirs.
> >>
> >> Dmitri - do you have an opinion on this?
> >
> >Yes! I think it makes sense to treat Regions DOM APIs similarly to
> >selection or any other rendering abstraction that just happens to also
> >need a DOM API. I have a bug
> >https://www.w3.org/Bugs/Public/show_bug.cgi?id=16527 to track this,
> >but haven't gotten to nailing down the specifics yet.
> >
> >:DG<
>
>
Received on Tuesday, 24 July 2012 18:19:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:57 GMT