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

Giovanni Campagna wrote:
> 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 reality text selection is a [consecutive] stream that starts from DOM 
position "A" and ends in position "B".
When you select something on the page and copy it into, say, clipboard 
UA creates html fragment in clipboard.
That html fragment includes everything that is in the DOM between 
positions "A" and "B". Content of this
clipboard fragment reflects exactly what is highlighted.

In the first case content of the clipboard will contain following:

<html><body>
<p><!-- Fragment start-->ne</p>
<p>Two</p>
<p>Thre<!-- Fragment end--></p>
</body></html>

And that is what will be highlighted on the screen.

And in second case you will have:

<html><body>
<p><!-- Fragment start-->ne</p>
<p>T<!-- Fragment end--></p>
</body></html>

That is far from what you have selected. To be short such selection 
cannot be represented in the way
you would expect.
>   
>> ---
>> 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?
>   
To keep metric of our space/time ((C) Dr.O.Hoffmann) continuum intact.

If seriously then see my comment above.
>   
>> 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.
>   
What is the order of the text (e.g. in second case)? Is order defined by 
author (in the source)
or is it defined by the CSS?
>   
>> 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)
>   
Concept of stream of text (sequence of paragraphs and characters inside 
them) is common for all humans.
Even that human happen to use X11 UI.
>   
>> 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).
>   
bidi changes visual order of character runs. It does not change order of 
paragraphs/statements.
If you have phrase "In previous paragraph I have explained..." written 
in English or Arabic it will be comprehendable
no matter which language you will choose.

And static flow in CSS means position:static. Do you think it is 
something else?
>   
>> 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).
>   
That is philosophic question...

Consider this:

<div .chapter>Chapter I<br>
 In this chapter we will define ....</div>

With the style
div.chapter::first-line { font-size: 200%; }

And this:

<div>
   <h1>Chapter I<h1>
   <p>In this chapter we will define ....</p>
</div>

Someone may tell you as second case is bad as "explicit block containers 
should
be avoided as much as possible".

Really I see nothing wrong in this markup:

<body style="flow:horizontal">
  <aside> ... sidebar content ...</aside>
  <div .article>... content...  </div>
</body>

div and aside here have strong semantic meaning and yet will allow to 
use CSS
selectors properly.

Having the same setup but without dedicated <aside> <div .article>
is also feasible with templates and slots but this will rise too many 
problems.

E.g. you will probably need something like this:

body:slot(b) { font: verdana; }

and that will be quite far from

div.article { font: verdana; }

In 99% of cases you will be forced to use dedicated  (explicitly defined 
and
semantically meaningful) containers.  Just to be able to style all this 
properly.

Really I see no benefits for that peculiar slot() construction. But 
probably
Bert could explain  motivation behind them. Bert?
>   
>> 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.
>   
Yes, I think too that slot() should be out of scope of CSS.

--
Andrew Fedoniouk.

http://terrainformatica.com

Received on Wednesday, 29 April 2009 21:05:50 UTC