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

2009/4/29 Andrew Fedoniouk <news@terrainformatica.com>:
> 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".

Selection is not Range. Selection is sequence<Range>, in DOM terms.
This means that it begins in A1, stops at A2, begins again in B1 and
ends in B2. [HTML5, section 6.6]

> 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.

1) It is out of scope of CSS such a serialization (HTML5, XML10)
2) It is out of scope of CSS the clipboard operations available

> 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>

Why it should contain that? Or, more precisely, what specification
prescribes this behavior?

> 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.

Because you think in terms of Range, rather than Selection.

>>
>>>
>>> ---
>>> 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.

Answered

>>
>>>
>>> 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?

The order of text is the order I read (or listen to) the text on my
output device. It is defined by CSS and by my nationality (you can
read ltr or rtl)

>>
>>>
>>> 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.

Are images considered "text" for the purposes of selection? X11 says
yes, Win says no. Again, it is out of scope of CSS a selection
algorithm.

>>
>>>
>>> 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.

But it may be in a order different than logical (binary / DOM) order.

> And static flow in CSS means position:static. Do you think it is something
> else?

Position:static/relative, float:none and a lot of other properties
(display:not-table)

>>>
>>> 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?

::slot() are groups of element in the same place.

>>
>>>
>>> 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.

No, adding DOM elements is out scope.

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

Giovanni

Received on Thursday, 30 April 2009 15:19:54 UTC