Re: [css3-regions] Comments on Editor's Draft

On 12/07/2011 11:45, Alex Mogilevsky wrote:
> On 11/07/2011 20:46, Vincent Hardy wrote:
>> On 6 Jul 2011 13:00:19 -0700 Anton Prowse wrote:
>>>   # A region is an element that generates a block container box and
>>>   # has an associated named flow
>>>
>>> Here, as above, candidates for regions are explicitly restricted
>>> to elements; but furthermore they are restricted to elements which
>>> themselves generate a container box.  This immediately rules out
>>> columns of a multicolumn element (as stated in 5.2.2 albeit with
>>> incorrect reasoning), since columns don't arise directly from an
>>> element.  [Given that the proposal talks a lot about multicol, it
>>> took me a while to realize that multicol doesn't itself conform to
>>> the regions model (despite motivating it) since, whilst it does
>>> amount to a flow into various areas (columns), it's not a flow into
>>> *regions*.  (It would be good to change that word in 2.3.4.)]
>>
>> I think this reflects the recent change in the spec.
>> Originally, the intent was to ask that column-boxes be addressable
>> as pseudo-elements and be allowed to be regions. However, the WG
>> has decided to not go that way and the section was modify to just
>> say that multi-column boxes are not addressable and therefore
>> cannot be made regions.
>>>
>>> Note that the definition doesn't rule out the multicol element itself
>>> (assuming the wider definition of container); presumably if the multicol
>>> element is itself a region then any flow associated to it fills all
>>> columns and cannot be managed on a column-by-column basis.
>>
>> Yes.
>
> what happens if a multicolumn element becomes a region it is
> ambiguous so far. I think it stops being multicolumn but simply
> becomes a container. But it is not what is implied here, is it? It
> sounds potentially useful, and also potentially complicated to
> implement...

I agree that this is currently unclear.


>>>   # For an<iframe>, an<object>  or a<embed>  element, the 'flow'
>>>   # property has a different behavior. The effect is similar to turning
>>>   # the 'display' property on the element to 'none' while moving the
>>>   # root element of the referenced document to the named flow.
>>>
>>> This seems a bit dubious!  What happens to the UI that would ordinarily
>>> correspond to the element?
>
> the idea is that<iframe> as a source simply provides indirection
> into content of a different document. There may be other ways to
> define that content comes from a file/url (e.g.
> "content:from-flow(url(http:example.com))"), but iframe already
> exists, has defined object model and provides security boundaries.

Indeed, it was the security boundaries that interested me here.  I don't 
claim to be particularly knowledgeable about security UI, but I believe 
it's the case that in current browsers you can right-click on an iframe 
and obtain more details about it (even merely "open in new tab").  It's 
not so clear to me what to expect when the iframe element itself doesn't 
exist and its content is potentially broken across multiple regions.

> As for iframe own UI (default border, scrollbar etc), it seems
> useless when iframe is there just to provide flow content, so it is
> just ignored (iframe itself is never rendered).

Sure.

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Tuesday, 12 July 2011 19:52:28 UTC