Re: [css3-regions][css3-gcpm] Thoughts on Plan A and Plan B

On Wed, Feb 15, 2012 at 11:26 AM, David Hyatt <hyatt@apple.com> wrote:
> On Feb 15, 2012, at 10:15 AM, Sylvain Galineau wrote:
>
> While I understand the pushback against a solution that requires scripting
> to instantiate region elements, I find solutions that implicitly drop
> dynamic styling and event handling on the floor to be at least equally
> problematic
>
>
> We're in complete agreement on this point. My big issue with regions is that
> scripting and explicit elements are required even for simplistic use cases.
> Again, this isn't really the fault of the regions spec. It's just that we're
> missing the page templates piece, and I think it needs to be there to
> complete the feature. I don't want to ship one piece without the other.
>
> Scripts and explicit elements just shouldn't be the only way to build
> content using regions.
>
> I think relevant features of a page templates spec would include:
>
> (1) The ability to define categories of pages, e.g., page masters, "header",
> "two-column page", "figure page", etc.

Isn't it's unnecessarily limiting to think of the templates as only
page-level? Any non-toy web site will have nested layouts.

> (2) The ability to select which master to use for a particular page.
> (3) The ability to specify the layout of the regions on the page. Options
> for this include:
> (i) CSS multi-column
> (ii) ASCII art grid layout template
> (iii) Positioned slots (the .ibooks way)
> (iv) Shadow DOM
> (v) Explicit DOM
> I think that connecting to shadow DOM is pointless and that just making the
> elements explicit would be fine. Because the explicit elements would be
> building the "outer shell" of a page, i.e., all the containers for actual
> content, I think there is not much of an issue with them being explicit vs.
> shadowed. They wouldn't interfere with event handling on stuff inside the
> slots for example even if explicit, and you avoid a spec dependency on a
> whole other feature.

I don't see it. With shadow DOM, I can define insertion points for
where the contents go. This allows keeping the content and the
template completely separate. So:

1) a template would use elements to create the right layout and put
insertion points wherever the content is presented;
2) page will just have content in it;
3) template is instantiated as shadow DOM for a template layout root element;
4) the page and template content is merged when rendered.

That seems elegant and scalable.

>
> I also think it would be worthwhile looking into how to effectively script
> anonymous containers. We should have a page slot object model that
> facilitates easy scripting. That would cut down on the need for explicit
> elements except in the most complicated of use cases.
>
> dave
> (hyatt@apple.com)
>

Received on Wednesday, 15 February 2012 19:41:49 UTC