W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: [webcomponents] Custom Components and CSS Regions

From: Alan Stearns <stearns@adobe.com>
Date: Thu, 6 Dec 2012 17:52:54 -0800
To: Dominic Cooney <dominicc@google.com>
CC: public-webapps <public-webapps@w3.org>
Message-ID: <CCE68407.1AAE5%stearns@adobe.com>
>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).

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

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

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


Received on Friday, 7 December 2012 01:53:24 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:50 UTC