W3C home > Mailing lists > Public > www-style@w3.org > February 2013

Re: [css3-regions] Separating regions markup

From: Alan Stearns <stearns@adobe.com>
Date: Fri, 8 Feb 2013 13:31:35 -0800
To: Håkon Wium Lie <howcome@opera.com>, Bert Bos <bert@w3.org>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <CD3AA78E.1D6AE%stearns@adobe.com>
On 1/30/13 2:55 PM, "Håkon Wium Lie" <howcome@opera.com> wrote:

>Bert Bos wrote, on 29 Nov 2012:
>
> > > As I mentioned last week, I've edited the sample code in Appendix A
> > > [1] in CSS Regions to move the regions elements to a separate file
> > > using custom elements from Web Components [2].
> > > 
> > > Bert, Håkon - does this approach satisfy your requirement for
> > > separating content markup from layout?
> > 
> > I think it can work.
>
>Certainly, it's much better than having empty elements in HTML files.
>
>I would probably still prefer to find a CSS-based syntax because:
>
>  - having to fetch yet another resource in yet another format is more
>    work
>
>  - the structure represented in your example (and, most likely, in
>    the common use cases) does not need deep nesting; regions are
>    (mostly) chained, not nested

Nesting is a requirement, in my book. If you are using regions in a
paginated view and there is additional content aside from the named flow
that you want to display on the page, the region chain will nest in
different parents. This is particularly true for the kind of marginalia
that Daniel has been talking about recently [1], and in the pagination
templates I've described [2].

So what's in the example (breaking out of the grid layout) is meant as a
proxy for the nesting requirement. Similarly, the second region in the
example is a proxy for using multicol with regions, even though it's not
strictly necessary for that particular example.

I think the key is your (mostly) - there are and will be uses for nesting
regions, so advancing a regions feature that does not support nesting is
too limiting. We've worked hard to ensure that CSS Regions works with all
positioning schemes and has the proper APIs for extension without
re-implementing everything with an enormous pile of JavaScript [3].

>
>  - a new format creates a need for a new mime-type etc; the new
>    format should not be served as HTML

As I mentioned to Bert, this is something to bring up with the Web
Components people on public-webapps [4]. I happen to like reusing the
existing format, but I don't have a particularly strong opinion on this.

>
>  - having selectors apply to the exteral resouce seems troublesome;
>    what do you do if #region1 matches both an elemen in the local
>    file and in the external resource? (Do we need name spaces here?
>    Ouch, my head start hurting)

I agree. I intend to re-work the example to move the <style> block to the
x-fancy-layout.html file. I think this is much more straightforward and
allows for better fallback - if the external file does not load or custom
elements are not supported, the content flows above the image as if the
'is' attribute did not exist.

Thanks,

Alan

[1] http://lists.w3.org/Archives/Public/www-style/2013Jan/0133.html
[2] http://dev.w3.org/csswg/css3-page-template/
[3] http://infrequently.org/2012/12/reforming-the-w3c-tag/
[4] http://lists.w3.org/Archives/Public/public-webapps/
Received on Friday, 8 February 2013 21:32:15 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:05 GMT