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

Re: [css3-regions] content:flow-from() vs. flow-from

From: Vincent Hardy <vhardy@adobe.com>
Date: Thu, 11 Aug 2011 13:40:01 -0700
To: Alan Stearns <stearns@adobe.com>, Alex Mogilevsky <alexmog@microsoft.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <CA698A1C.FA11%vhardy@adobe.com>
Hi Alan,

On 8/10/11 6:42 PM, "Alan Stearns" <stearns@adobe.com> wrote:

>On 8/10/11 4:07 PM, "Alex Mogilevsky" <alexmog@microsoft.com> wrote:
>
>> I would like to revisit the issue of named-flow property
>> 
>> "content:flow-from(flowname)" vs. "flow-from:flowname"
>> 
>> We did have a WG resolution for 'content', but at the time of the
>>discussion
>> the difference appeared to be purely syntactical, however it isn't, as
>> described here:
>> 
>> http://lists.w3.org/Archives/Public/www-style/2011Jul/0477.html

>> 
>> In short:
>> 
>> * 'content' replaces natural content of the element, combining it with
>>any
>> ':before' and ':after', potentially with fallbacks, while
>> * 'flow-from' takes over the whole box, giving it a different layout
>>model
>> (where ':before' and ':after' have no meaning)
>> 
>> It is possible to define how before/after blend with flow content in a
>>subset
>> of region use, but it is something that was never called for, yet it is
>> complicated to define and implement.
>
>The regions spec currently defines ::region-before and ::region-after,
>which
>"...have the same definition as the Œ::before¹ and Œ::after¹
> pseudo-elements" but a different processing model.
>
>Why not ditch those and give ::before and ::after meaning in a region
>context equivalent to what you plan to do for ::region-before and
>::region-after? Then the current issue with content:flow-from() goes away.
>
>Option 5:
> 1) "content:flow-from()" defines a region (no change)
> 2) css-regions updates section 4 to use pre-existing pseudo-selectors


[VH] Ok, so you are suggesting a different meaning for ::before and
::after on regions. I am not sure if we have guiding principles for cases
like this (in other words, is it ok to have a property/pseudo-element
behave differently depending on another property's setting. CSS has some
properties which are not meaningfull unless another one has a specific
value: for example, top/left is not relevant for non positioned elements.
So I would think it is ok to go this route.


>
>I'd further like to pursue making ::before and ::after behavior with
>regions
>be as close to other elements as possible. This version of the spec might
>note that inline use would be desirable but admittedly difficult, so
>something like this would be required:
>
>Content content content content content
>                (...continued on page 3)
>
>But something like this would merely be a recommendation at this point in
>time, and could fall back to the behavior above:
>
>Content content (...continued on page 3)

[VH] The thing that is unique about regions is that the inserted content
basically comes at break boundaries. For the ::before pseudo-element, it
seems easier than for ::after because the generated content would be
inserted at a break point and influence where the break point would be.
This seems non trivial at all and this is what made us propose the
different processing model in the current (in progress, not ready for
review) editor draft.

Vincent

Received on Thursday, 11 August 2011 20:40:45 GMT

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