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

RE: [css3-regions] comments on regions module

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Thu, 7 Apr 2011 06:56:00 +0000
To: Mihnea-Vlad Ovidenie <mihnea@adobe.com>, www-style list <www-style@w3.org>, Arno Gourdol <agourdol@adobe.com>
Message-ID: <D51C9E849DDD0D4EA38C2E539856928411F1DA2F@TK5EX14MBXC213.redmond.corp.microsoft.com>
> -----Original Message-----
> From: Mihnea-Vlad Ovidenie [mailto:mihnea@adobe.com]
> Sent: Tuesday, April 05, 2011 7:45 AM
> >2) Does flow source have to be in same document? 
> We didn't think about using another file to flow content, because we
> thought this issue is not really specific only to threading and regions.
> It seems like developers use Ajax to include fragments of HTML in the same
> context, maybe it is a good idea to have something like a <fragment>
> element, but that's out of scope for this specification.

Yes, there is a well developed and well understood use of Ajax for building compound documents. At the same time iframes are widely used as a boundary for styling and security (the latter is particularly important when integrating with content that you don't own).

It is also true that elements (especially replaced) are generally out of scope of CSS. But we have to show somewhere that when all pieces are put together the overall system is working and well designed, and unless there is another forum for that here is perfectly appropriate place to discuss that...

There are specific issues to consider if content may come from another document:
* The content that flows through regions can be defined as the source element itself (appropriate for div) or its content (preferable for iframe)
* Concatenating multiple sources in one contiguous flow can be challenging (depending on underlying implementation). 

> >3) Can there be multiple sources?
> If multiple sources have the same 'flow:into(content)', all sources are
> concatenated using the document order of the elements. Actually, all the
> elements participating inside a flow thread will be rendered as children
> of an anonymous block that spans across all the regions assigned to the
> specified thread.

It is a reasonable approach. I see implementation challenges beyond layout (nothing unsolvable), mostly when it involves interacting with the content - selection across sub-flow boundaries, caret navigation, editing, etc.

> >5) Region-based styling
> We initially thought about a 'first-region' concept, but then we wanted to
> extend it to all the regions, hence the 'content-style' property.

I have to admit the syntax for content style block is an interesting approach. I didn't realize what it does when I first saw it but now I see that the effect matches (or is close) to the effect of first-line (it targets specific elements, not overriding properties of all content).

And thanks for a use case, it makes it easier to understand what other options would work. I would like to eventually see a case where content has local formatting (let's say a hyperlink or highlighted words) that keep or lose their formatting when region style is applied.

Have you considered grouping all styles for a region into one style block (maybe an @ block with multiple selectors in it)? 


Received on Thursday, 7 April 2011 06:56:31 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:45 UTC