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

Tab Atkins Jr. wrote:
> On Wed, Apr 29, 2009 at 4:05 PM, Andrew Fedoniouk
> <news@terrainformatica.com> wrote:
>   
>> 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.
>>     
>
> You are presupposing a particular implementation of text selection,
> which, as you demonstrated, is certainly not designed well for a
> document which may be displayed in something other than source order.
>   
That is common implementation and I haven't seen selection implemented 
other way.

That common implementation is CSS agnostic - if you have DOM positions 
"A" and "B"
then you will always get the same fragment no matter what styles you 
have applied to the DOM.

> Of course, as you noted, floating and positioning can already cause
> problems with this.  Template Layout presents basically identical
> challenges.  The only difference is that Template Layout makes it much
> easier to create a functional website with heavy use of these
> techniques.
>
>   
Yes, indeed, one of goals layout managers in CSS is to reduce need of 
positioning and floats for basic layout
purposes. So better selection is one more benefit we will get from 
having layout managers. But they must not
make things worse.
>>>> 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.
>>     
>
> I presume your "comment above" was about the non-optimal results that
> a particular text-selection algorithm produces.
>
> That doesn't answer the question, however.  Being able to have
> separate display and source orders are very desirable, especially for
> accessibility purposes.  This is why there are such ridiculous
> float-based hacks like One True Layout and such - people want to put
> the page content before the sidebar content, but be able to put the
> sidebar on the left ("before" in display order).
>   
Yes it is desirable on macro level when, say, you will need provide 
content *block* first
and side bars at the end of your document.

But I am talking about different thing. That slot() construction in 
Bert's proposal assumes that content of that
[pseudo-but-still] *block* will be assembled from different 
non-consecutive parts of your
document. Beside of problems with the text selection I've mentioned it 
will play badly with incremental rendering.

If you have content section (that will be designated by "@" slot I 
suspect) then highly probable that
user will need selection inside that section. And if you will have DOM 
elements picked from different
parts of the DOM then any attempt to select text there will produce very 
frustrating results.
Usability of this solution will be below the zero.

The solution is as I said is to drop that slot() feature completely. 
Slot can be occupied by only single
DOM element. In this case you will not need that artificial slot() thing 
as you can always style that element
in the slot itself without any need of introduction of completely new 
entities for CSS.
And it will guarantee that content of the slot consists of consequent 
DOM elements so user will be able
to do text selection without surprises at least inside that [macro]sections.

(Needless to say that flow: vertical | horizontal | etc. plays well 
better with text selection)

>   
>>>> 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?
>>     
>
> When interacting with the text in a visual UA, the "order of the text"
> is determined by the order that it appears in.  In many simple cases
> this is identical to the source order, but it is obviously different
> here.
>   
I assume that "In many simple cases" means "rest of the CSS" and 
"different here" means "this particular
variant of the Template Layout"? If "yes" than this is not so good. 
Ideally introduction of layout manager
should not require the way how DOM events and other existing mechanism 
are handled at the moment.
>   
>>>> 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.
>>     
>
> Oh, indeed, but we're talking about how to select displayed text.  The
> stream that produces the text is completely irrelevant to the
> end-user.
>   
It is irrelevant only in one case - if you have any other *reliable* way 
of saying "I have element A and this
element B next to it". Yes, you can define something like this:
    <p style="position:relative; top:-100px">Woo-hoo</p>
but I would like to see practical algorithm that will recognize what 
will be the element after it.
That would be something close to CAPTCHA recognition algorithm built-in 
in browsers, eh?

>   
>>>> 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.
>>     
>
> Similar issue, however.  Selecting bidi text produces a conflict
> between visual ordering and source ordering when you are trying to
> select text.  For example, given this sourcetext:
>
> englishhebrew
>
> Which has this visual display:
>
> englishwerbeh
>
> What happens when you start a selection in the middle of "english" and
> end in the middle of "werbeh"?  The optimal answer may not follow
> source-order.
>
>   
It is fine if you have, say, Arabic text. But real troubles start when 
you have mix of  RTL and LTR in
one *sentence/paragraph*. Let's not make things even worse by 
introduction of chaotic (for the user) mix
of paragraphs - user will have no clue that some visually consecutive 
paragraphs are in different order in fact.
>> 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.
>>     
>
> If you are rearranging *paragraphs* in the middle of a paper, you
> either know what you're doing or aren't interested in making sense.
> ^_^  The standard use-cases for Template Layout move independent
> sections.
>   
Again I am talking about situation when slots content accepts multiple 
elements.
That pretty much means that any, say, inline style with position: A..Z 
may change the order
of elements that appear in any section.  That would be really nightmare 
to maintain: element
that is inside left sidebar *block* may appear as a first or last or 
even in between of right sidebar
or content sections.
>   
>>>> 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?
>>     
>
> The ::slot() pseudoelement allows you to style the sections of your
> page that your template specifies, which isn't easily possible.  It
> does *not* style the contents of the slots; it *can't*, as none of the
> contents inherit from the ::slot.  Your example about font is indeed
> impossible to put directly on the slot.
>   
So as I said in practice you will end up with defining dedicated element 
for each slot.
But you never be sure that it will be the only element in that slot. The 
whole setup will not
be quite robust.

<quote>

Weinberg's Law:
    If builders built buildings the way programmers wrote programs,
    then the first woodpecker that came along would destroy civilization.

</quote>

> ::slot allows you to specify backgrounds on the section and vertical
> alignment, along with hopefully borders, padding, and a few other
> properties for further styling and positioning.  The underlying
> reasoning is that these are properties of the container itself, not
> the children, as ::slot has no children (unless/until we can put
> pseudoelements like ::before on ::slot).
>   

Ah, and that ::before ...

I am failed to decipher this:

.note::before {
    content: counter(note);
    position: @;
    vertical-align: super;
    font-size: larger}

(Example V in http://www.w3.org/TR/css3-layout/)


> ~TJ
>
>
>

Received on Thursday, 30 April 2009 01:06:12 UTC