Re: [webcomponents] Custom Components and CSS Regions

On Fri, Dec 7, 2012 at 10:52 AM, Alan Stearns <stearns@adobe.com> wrote:

> >On 12/6/12 3:25 AM, "Dominic Cooney" <dominicc@google.com> wrote:
> >
> >>On Wed, Dec 5, 2012 at 9:56 AM, Alan Stearns <stearns@adobe.com> wrote:
> >>
> >>...
> >>
> >>An insertion point is a <content> element inside a shadow DOM subtree.
> >
> >This is one kind of insertion point. There is a second kind,
> >called <shadow>, which is used when multiple shadow roots are
> >applied to a given element to specify how the shadows are
> >merged for rendering.
>
> Thanks for the correction.
>
> >...
> >
> >>Insertion Points:
> >>1. Content assignment done in HTML
> >>2. One-to-one mapping of content to insertion point
> >
> >If you replace /insertion point/ with /content element/ this
> >is right for the children of a given host element in the context
> >of that host element¹s shadows but not for a document in general.
> >When there are multiple shadows and reprojection, where a node
> >is presented in the (virtual) flattened tree can depend on
> >multiple insertion points.
>
> What I mean here is that the end result is a simple mapping for each
> content element to a specific insertion point. The end result may depend
> on multiple insertion points, but there's always just one insertion point
> where each content element gets displayed. I am trying to contrast this
> with taking content and flowing it between two boxes as you can do with
> CSS Regions (my first use case below).


Yes, this is the qualitative difference.


> >>3. Content must come from insertion point shadow host
> >
> >This is incorrect in the case of reprojection.
>
> Would it be more precise to say that the content must come from somewhere
> up the parent chain? Here I'm trying to contrast between the scoped
> selectors that insertion points use and the general selectors that can
> have flow-into assignments. This fits in to my multiple source use case
> (#4) below.
>

To be precise you have to define “parent chain” very carefully, but yes –
Shadow DOM projection pulls content from a defined scope; CSS Regions have
more of a flat, global namespace going on where content is pushed into
flows and is pulled from flows.


> >...
> >
> >>4. Can assign multiple selectors to a single insertion point
> >>5. Cannot chain insertion points together
> >
> >I¹m not sure what you mean by ³chain², but reprojection and
> ><shadow> make two kinds of chaining possible.
>
> By chain I mean create a fragmentation context - akin to multicolumn
> layout. The column boxes are "chained" together and content flows from one
> column to the next. In CSS Regions each region box participates in a
> region chain, and content flows from one box to another.
>

Ah, I understand now. This is right.


> >...
> >
> >>Should use Regions
> >>1. If you need to chain boxes together inside a template
> >>  (create your own multicol component)
>
> Here I'm not thinking so much of faithfully recreating multicol layout,
> but of making a custom element that contains two or more columns
> (expressed as CSS Regions). Take a simple case of displaying your content
> in two columns separated by some graphical element in the gutter between
> the columns. Which content fits in the first column depends on its height
> and width, and any overflow content in the block direction flows into the
> second column. You can do this with CSS Regions defined in your template.
> I do not think you can do this with insertion points without choosing how
> to divide the content between the columns.
>
> >>...
> >>
> >>4. If you need to pull content from multiple sources
> >>  (breaking news from two or more components)
>
>
> Consider the Shadow DOM example of the news widget separating breaking
> news into its own section. What if you had two or more of these news
> widgets (say, international and local news) and you wanted to combine the
> breaking news from each into its own widget? You could create a "news
> page" widget that contained the list of news widgets in order to get
> access to all of the breaking news content across the widget list. But
> that would require an additional wrapper in the HTML.
>
> Instead, you could just add a "breaking news" widget, assign all of the
> .breaking content to a named flow, then assign that named flow to an
> element in the "breaking news" widget. CSS Regions can pull content out of
> each custom element (or anywhere else) and redirect it to a separate
> custom element without requiring a common parent.
>
> Thanks,
>
> Alan
>
>