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

What I'm saying may be very wrong, I didn't digest the Shadow DOM spec too much. Sorry in advance :).

What's special about NamedFlows is that the content resides in the Document and the regions can reside in the shadow tree.

One consequences of this is that the layout of the content affects the elements inside the shadow tree boundaries.
For example:
If a widget using shadow DOM sets a fixed-font size on the content using region styling in a specific region and then checks the regionOverset property on that region, it can determine information about the content that's being flown inside the NamedFlow (e.g. regionOverset=overflow means that there's more content and regionOverset=fit means that there's less content). Is this something that the Shadow DOM proposal tries to avoid? This is somehow similar with the old trick of checking link colors to see if one was visited before by the user.

If this is a problem, maybe further restrictions need to apply to Regions in the context of shadow trees, not only limited to DOM nodes leak prevention.

Thanks,
Andrei.

From: dglazkov@google.com [mailto:dglazkov@google.com] On Behalf Of Dimitri Glazkov
Sent: Tuesday, July 24, 2012 9:19 PM
To: Andrei Bucur
Cc: www-style@w3.org; Alan Stearns
Subject: Re: [css-regions] Shadow DOM and Regions CSSOM

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<mailto: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<mailto:dglazkov@chromium.org>> wrote:

>On Thu, Jun 21, 2012 at 1:29 PM, Alan Stearns <stearns@adobe.com<mailto: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<