W3C home > Mailing lists > Public > www-style@w3.org > April 2011

[css3-regions] comments on regions module

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Sun, 3 Apr 2011 11:01:42 +0000
To: www-style list <www-style@w3.org>, "Arno Gourdol (agourdol@adobe.com)" <agourdol@adobe.com>
Message-ID: <D51C9E849DDD0D4EA38C2E539856928411F172C5@TK5EX14MBXC213.redmond.corp.microsoft.com>
I sent a list of comments on the initial proposal, it didn’t get a lot of traction here yet… The updated editors draft has some of my questions addressed, so let me try the rest (I’ve removed resolved issues from below)

From: Alex Mogilevsky
Sent: Friday, March 11, 2011 4:17 PM
To: www-style@w3.org; Arno Gourdol (agourdol@adobe.com)
Subject: RE: CSS Regions proposal


1)      Module name
The word “region” is good in representing that the shapes involved are not necessarily rectangular. It doesn’t represent however that the containers are connected. “thread” is better in communicating that, so perhaps it would work as the module name? Other options:

·         “Named flows” (as previously used in GCPM [2])

·         “Page flow” – because it is paginated content

·         “Linked boxes”, “linked containers”, “connected frames” – some other terms I’ve seen in products or in implementation.



2)      Does flow source have to be in same document?

Documents that are as complicated as magazines probably have a complex workflow that involves multiple files and different people working on design and content. Wouldn’t it be more scalable if the content could come from a file?



E.g.
    <iframe src="content.html" style="flow:into(content)"></iframe>

or
    <object data="content.html" style="flow:into(content)"></object>



3)      Can there be multiple sources?

What happens if multiple elements have “flow:into(content)”? It can be defined that all sources are concatenated (and it may make sense in GCPM examples). However if content is from multiple files concatenation in layout can be complicated. Regions module [1] hints that “quotations” thread can have multiple sources. I am not convinced however that use cases that call for source concatenation can’t be solved better by simpler means. Perhaps that should be optional…



4)      ‘display’ on ‘flow:into’

Is it important that ‘flow-thread’ is only applicable to blocks? If that element becomes the root element of content of a flow region, is it any different HTML from another source being in an iframe? Then whatever is applicable to HTML element should apply there… ‘display:table’ should work fine…


5)      Region-based styling

It is different in the new draft, it is scoped and actually possible to implement (although still not easy).

It is now a strong override (higher specificity than ‘style’ property)  - that makes it strong and really unambiguous. But it is now very different in concept and behavior from first-line.

Can I ask again – what are use cases for ‘content-style’?

It *can* be similar to ‘first-line’ if applied at first page:

                p::first-page { color:blue; } – this won’t affect H1 or explicit colors within a <p>
                *::first-page { color:blue !important; } – really makes everything blue

It is more complicated if regions/pages other than first want to style content…

[1] http://dev.w3.org/csswg/css3-regions/Overview.src.html

[2] http://www.w3.org/TR/2007/WD-css3-gcpm-20070504/


Received on Sunday, 3 April 2011 11:02:20 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:39 GMT