Re: [css3-layout] Template Layout Module and text selection.

2009/4/29 Andrew Fedoniouk <news@terrainformatica.com>:
> Template Layout Module allows to put multiple non-consecutive (in the DOM)
> elements into so called slots.
> As far as I understand each such slot is a pseudo block container that
> establishes block formating context (is this correct?).
> Visually such a slot presented to the user as a solid block.
> I am not sure how in principle text selection will work inside such blocks.
>
> Consider following [pseudo] markup:
>
> <p destination-slot="b">One</p>
> <p destination-slot="a">Two</p>
> <p destination-slot="b">Three</p>
>
> And the template:
>  "a"
>  "b"
>
> This setup will presented to the user as a column:
>
> Two
> One
> Three
>
> Now consider following cases of selection ('<' marks selection start and '>'
> is an end of the selection):
>
> Two
> O<ne
> Thre>e
>
> T<wo
> O>ne
> Three
>
> Question: what is supposed to be selected in these cases?

<ne
Thre>

and

<wo
O>

You wrote what the user selected. I really don't see where is the problem.

> ---
> In general: layout managers in CSS when applied to HTML should be designed
> in the way that
> keeps next/previous visual order elements with their DOM positions.

Why?

> Otherwise we will need to change
> principles of how text selection is handled

Text selection, as the name suggests, is "text". That is, you select
the text inside the element, not the box the text is in.

> Absolute positioning and floats
> used for layout purposes are
> already examples making text selection not quite useful for the humans.

This depends on the UA, as CSS defines nothing about what is expected
for selections (which depends on OS conventions, for example X11 and
Win have very different handling of selection)

> Defining layout manager that is
> capable to break next/previous relationship in even static flow will make
> situation even worse.

Why?
We already have such problems (for example if you mix bidirectional
content) and I've never seen any problem (except that this kind of
selection is not usually in visual order, but that is an UA bug).
Moreover, we should define what *static flow* is. I think of it as the
content of descendant blocks that are not flow roots and have the
default layout model (so no tables / templates / floats /
absolute-positioned / inline-blocks / etc).

> Related to this: artificial block containers generation shall be avoided as
> much as possible.

On the contrary, explicit block containers should be avoided as much
as possible. We are designing style, it is our design principle to
avoid dependency on layout-only <div>s.
If you cannot have explicit boxes, then you need artificial boxes. In
general, not all those boxes need to be selected by a selector
(they're anonymous boxes).

> Need of using explicit block containers is in principle less harmful than
> bunch of problems related
> to such zombie elements (need of very artificial slot() constructions in
> CSS, etc.)

This is out of scope of CSS.

> --
> Andrew Fedoniouk.
>
> http://terrainformatica.com
>
>
>

Giovanni

Received on Wednesday, 29 April 2009 19:24:41 UTC