Re: [css-regions] Regions OM

On 8/7/12 9:51 AM, "dglazkov@google.com" <dglazkov@google.com> wrote:

>I finally had a chance to study the Regions spec. I have questions and
>ideas :)

Thanks!

>
>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.

Note that content can be sucked from more than one DOM element, and that
the members of a region chain are not required to be DOM elements, merely
non-replaced block container boxes.

>
>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.

The Region interface abstraction is meant to relieve the dependence on
Elements. While an Element does implement the Region interface, it would
be a good thing to expose OM for other boxes that can be regions, like
pseudo-elements. Then the region chain can really become a sequence of
Regions, which may or may not be 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.

Some of the Regions OM is definitely about rendering (what content fits in
which box, etc.) so I would expect to run into some of the same issues as
selection Ranges.

>
>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.

That's certainly a possibility. Are you suggesting making all of the live
bits of the current Regions OM static, or just some?

>
>* 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.

The flow-into and flow-from assignments are in the style declarations. The
rest of the Regions OM is attempting to provide additional information
that scripts need:

1. The ordered collection of content in a named flow
2. The ordered chain of boxes for the content
3. How the named flow content fits in the region chain

I'm not sure how this information would live in a CSSStyleDeclaration.

>
>* 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?

I think it would be a good exercise to try to rationalize named flows,
region chains and insertion points. But do you see insertion points ever
being extended to flow content from one point to another? In my reading of
Shadow DOM so far I see node-to-point matching, not rendering a node's
content fragmented over multiple insertion points.

Thanks,

Alan

Received on Tuesday, 7 August 2012 18:55:18 UTC