W3C home > Mailing lists > Public > www-style@w3.org > November 2012

Re: [css-regions] Concern about CSS regions flowing into generated content

From: Alan Stearns <stearns@adobe.com>
Date: Sun, 11 Nov 2012 13:42:15 -0800
To: Elliott Sprehn <esprehn@gmail.com>, Andrei Bucur <abucur@adobe.com>
CC: www-style list <www-style@w3.org>
Message-ID: <CCC55891.19341%stearns@adobe.com>
>>On 11/11/12 1:07 PM, "Elliott Sprehn" <esprehn@gmail.com> wrote:
>>
>>
>>>On Wed, Oct 10, 2012 at 5:05 AM, Andrei Bucur <abucur@adobe.com> wrote:
>>>
>>>
>>>...
>>>
>>>
>>>From a specification standpoint, the behaviour for pseudo-elements is
>>>currently 
>>>defined like this:
>>>"If the Ścontentą property computes to something else than Śnormalą
>>>(or Śnoneą for a pseudo-element), the block container does not become
>>>a CSS Region. If the Ścontentą property computes to Śnormalą (or Śnoneą
>>>for a pseudo-element), then the block container becomes a CSS Region
>>>and is ordered in a region chain according to its document order."
>>>
>>>This definition basically allows a pseudo-element to become a region
>>>only if the content property evaluates to "none". This way the content
>>>property will always have priority and the pseudo-element's box will
>>>be used to flow content if nothing else is specified.
>>>
>>
>>
>>
>>What you describe seems reasonable, but it still bothers me that the
>>primitive for putting things like form controls into ::before and
>>::after is Regions and we offer no simpler and saner alternative in
>>the platform. :)
>

People requested being able to make regions out of pseudo-elements, and
::before and ::after pseudos are the only existing pseudo-elements where
this might work. As you note, this approached seemed reasonable.

>>I think Mozilla has proposed an alternative to the current design of
>>regions that side steps all this that I like a bit better.
>

Well, it sidesteps the ::before and ::after issue, but only by defining an
entirely new pseudo-element. Whatever problems you see in allowing
arbitrary content inside pseudo-elements will have to be addressed for the
new thing as well.

And as an alternative, it's lacking quite a bit so far. All of the boxes
are required to be siblings, which limits the layout possibilities. There
are scriptability and accessibility hooks missing, because the overflow
boxes are pseudo-elements. It has a ways to go before it addresses the use
cases we're trying to solve with Regions.

Thanks,

Alan
Received on Sunday, 11 November 2012 21:42:44 GMT

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