W3C home > Mailing lists > Public > www-style@w3.org > April 2009

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 29 Apr 2009 18:17:26 -0500
Message-ID: <dd0fbad0904291617p54e0bf6eu9177c010c21e1954@mail.gmail.com>
To: Andrew Fedoniouk <news@terrainformatica.com>
Cc: Giovanni Campagna <scampa.giovanni@gmail.com>, www-style@w3.org
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.

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.

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

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

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

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

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

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

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

~TJ
Received on Wednesday, 29 April 2009 23:18:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 03:46:58 GMT