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

Re: [css-regions] Regions OM

From: Dimitri Glazkov <dglazkov@google.com>
Date: Tue, 7 Aug 2012 10:54:32 -0700
Message-ID: <CADh5Ky0LaOC9YfJSTf1enYbuNxYX74-gW8yVR6L0=27gs6EpYA@mail.gmail.com>
To: www-style@w3.org
Cc: Alan Stearns <stearns@adobe.com>, Andrei Bucur <abucur@adobe.com>
To clarify, by Ranges I meant the use of Ranges in selection. Sorry,
mental shortcut of a discussion that occurred elsewhere.

:DG<

On Tue, Aug 7, 2012 at 9:51 AM, Dimitri Glazkov <dglazkov@google.com> wrote:
> I finally had a chance to study the Regions spec. I have questions and ideas :)
>
> The Regions spec makes some brave changes (not unlike Shadow DOM) to
> current Web platform. I was trying to understand how some of these
> changes (namely, the object model parts of the spec) fit into my
> understanding of DOM.
>
> Viewing simplistically, Regions suck content from one DOM element and
> project (not unlike insertion points in Shadow DOM) it to one or more
> other DOM elements, replacing their respective content.
>
> The projection is controlled by CSS (unlike insertion points in Shadow
> DOM), which in turn means that any change to the document or even
> outside of document (media query reactions, for instance) could affect
> the projection.
>
> In OM world, the specifics of the projection are expressed as a
> collection of NamedFlows, accessible from Document. Each NamedFlow
> object allows retrieving the region chain, associated with it, as
> essentially a sequence of Elements.
>
> This is where I started experiencing discomfort. The Regions OM is
> tied pretty tightly to DOM, from element-bound interfaces to using
> ranges. This is dissonant with the nature of projection, communicating
> a bit more stability to the user of the API than there really is. For
> example, even the fact of existence of a particular NamedFlow instance
> is not guaranteed when one attempts to hold a reference to it.
>
> It appears that it suffers from the same problem as Ranges -- a
> rendering concept that is being shoehorned into a DOM concept.
>
> So, here are my promised questions and ideas:
>
> * Perhaps the OM should be more snapshottey, like all rendering data
> typically is? If you received some data from the OM, it's something
> that was only accurate at the time of querying.
>
> * Maybe the OM should actually live on a CSSStyleDeclaration, rather
> than DOM element? This should help a bit with communicating the origin
> of this information.
>
> * It seems that this general concept of projecting is somewhat similar
> to Shadow DOM insertion points. Are there opportunities to flesh it
> out as such?
>
> :DG<
Received on Tuesday, 7 August 2012 17:54:59 GMT

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