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