Re: [CSS Regions] Update available

Hi Tab,

Thanks for the feedback. We have come up with some answers.

Mihnea

On 4/1/11 12:37 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

>On Fri, Mar 25, 2011 at 12:49 PM, Arno Gourdol <agourdol@adobe.com> wrote:
>> We have an update of our CSS Regions proposal. You can find it here:
>> http://dev.w3.org/csswg/css3-regions/
>>
>> First, apologies for the unprocessed document. This will be resolved
>> promptly. In the meantime, please click Overview.src.html in directory
>>above
>> to get to the document.
>> This version incorporates some of the feedback we've received at the F2F
>> meeting and on this mailing list. Thanks to everyone for your
>>suggestions
>> and comments.
>> The document has been broken up in three major sections: slots (which
>> describe a way of creating elements using CSS declarations and could be
>>used
>> for regions and other purposes), regions (which are a way of
>>implementing
>> story threading) and exclusions (to specify areas to be avoided for the
>> purpose of text layout).
>> We would be very interested in feedback regarding the structure of the
>> document, and whether these proposals should remain in one document, be
>> merged with other proposals, or separated in multiple documents.
>> We also look forward to feedback regarding the new proposed syntax.
>
>Comments on the Slots section:
>
>1.
>Slots should be pseudo-elements in the same way that ::before,
>::marker, etc. are.  In particular, this means that they are *not*
>selectable by normal selectors.  They're created as anonymous elements
>in the CSS element-tree by setting their 'content' property to
>something other than 'none', that's it.

We agree that having slots selectable by normal selectors is not a good
idea. 


>
>This also means that doing something like the example in the draft
>(lightly modified to remove some parts irrelevant to this comment):
>
>body::slot() { content: "first slot"; }
>body::slot() { content: "second slot": }
>
>...just creates a single slot, with the text "second slot" inside of
>it.  This is exactly identical to how ::before would work in the same
>situation:
>
>body::before { content: "first before"; }
>body::before { content: "second before"; }
>
>If you want multiple slots on the same element, they should be
>named/numbered differently.  Either of the following two examples
>should create two slots, as expected:
>
>/* Two named slots */
>body::slot(foo) { content: "first slot"; }
>body::slot(bar) { content: "second slot": }
>
>/* Two anonymous numbered slots? */
>body::slot(1) { content: "first slot"; }
>body::slot(2) { content: "second slot": }
>
>(We may or may not want anonymous numbered slots.  It's not a big deal
>either way - you can just name them with a numbered token, like "s1"
>and "s2".)

It seems like 'slot()' without a name introduces confusion and maybe we
should not support it. In the example with the two named slots, the order
used to layout the two named slots depends on the document order of the
CSS rules. Using only numbers seems to make it easier to sort the slots
that are attached to the same element, but makes it harder to maintain the
CSS rules.  



>
>*************
>
>2.
>I don't understand the need for the %slot-name syntax.  If you want a
>slot to have slots for some reason, you should just chain the
>::slot()s, like "body::slot()::slot()".  Pseudoelements aren't
>currently chainable, but they should be.  Let's assume that this
>functionality exists.

We agree that ³::slot()::slot()² should be possible and that %slot-name
syntax can be removed.


>
>**************
>
>3.
>A bare "::slot()" selector should function exactly like it would if it
>were any other pseudoelement, and create a slot on every element, just
>like if you specified "*::slot()".  If you want a slot on root, just
>say ":root::slot()".

We agree.


>
>***************
>
>4.Feedback on Regions:
>
>1.
>This ability, itself, I think should be called Named Flows.  It's the
>flows that we care about, after all.
>
>****************
>
>2.
>In addition to the into(<ident>) function, which shunts the contents
>into a Named Flow to be picked up by a ::slot() later, we should have
>a cell(<ident> | [ <grid-row> <grid-column> ]) function, which flows
>it directly into a Grid cell (cells would automatically have their
>'content' set up appropriate to grab from the cell() flow, I guess).

We agree that regions spec has to align with the other layout modules. It
seems like both ³into² and ³cell² concepts refer to content placing and it
sounds like we should allow flows and cells use the same naming domain and
use only one function for both use cases.


>
>*****************
>
>3. In general, this seems like it's just an overflow capability.  Can
>we bodge this ability into 'overflow' instead of creating a new 'flow'
>property?  This might not be a good idea, actually; it would mean that
>if you want to, for example, shift all of <body>'s contents into a
>slot, you have to set 'overflow' appropriately and then set
>"height:0", which sounds weird.
>
>~TJ
>

Received on Thursday, 7 April 2011 01:28:22 UTC