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

On Wed, Apr 29, 2009 at 8:05 PM, Andrew Fedoniouk
<news@terrainformatica.com> wrote:
> 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.

Understood, but why are you presuming that this is the only or best
way?  Selecting text has literally *nothing* to do with the source
stream.  I, as a user, don't care one bit about it.  Selection is an
interaction entirely rooted around the presentation of the text.  I
click in one place, drag to another, and I want the things in between
to be highlighted, no matter what.  The theoretical 'purity' of source
order doesn't mean anything at all to me.

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

I'm unsure of what you mean by this.  Why do you think that any
similar layout manager will make things better for the vanilla
selection algorithm?  Template Layout is basically identical to
absolute positioning, except much easier and with additional powers.

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

The ability to flow separate elements into a slot merely moves the
selection problem slightly further in.  Without that ability, you
still can't reliably select text across slots.  Why is it such a
problem in one case but not another?

As for incremental rendering, there is little benefit gained from only
allowing single elements in slots.  You still may have to wait for
elements further down on the page in order to compute width/height of
slots.  If you're looking to avoid repainting, then you have to wait
until all the children of an element are rendered anyway.

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

Indeed, the vanilla text selection algorithm is really bad when you
allow the document to be visually reordered.  It was acceptable only
when there was a close connection between visual order and source
order.  It's passable now only because the things that break it
(floats, positioning) are still very annoying to build a layout out
of, and when used properly are relatively rare anyway.  But layout
managers will continue to get more sophisticated.

A selection algorithm to handle this would simply need to place
multiple hooks on the dom to demarcate the various selected regions.

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

Before dropping a useful feature over this relatively minor issue, I'd
rather explore the possibility of a new selection algorithm that can
handle it properly.  This issue will come up more as we develop
further advanced layout managers that allow source reordering, and so
dodging the issue here won't help us later.

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

No, there are many current cases that don't qualify as simple; namely,
floating and positioning completely screw with selections.

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

Luckily we're not talking about such impossible examples.  Our
use-case here is very simple: you have (possibly multiple) DOM
elements which all have the same position:value, being flowed into a
new container in source order.  Thus we have a very reliable way of
detecting the 'next element' - it's the next element in source order
with a position resolving to the same slot (I have to phrase it this
way to handle the "same" value for position).

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

Is there any reason the user *should* know this?  I'm not seeing any
reason at all to force the user to understand the concept of source
order, except that it's easier because it means you can use the same
simple selection algorithm from back when html didn't have selectable
layout managers.

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

You seem to be under the impression that the ordering of the reflowed
elements is unpredictable.  It's not.  Within a ::slot, elements
appear in source order.  They may come from different points in the
DOM, but the overall ordering is maintained.

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

Eh, not necessarily.  For example, on the Tabbed Layout thread I noted
that Template Layout would be *perfect* for pulling tabs out of cards.
 Given:

<stack>
<card>
  <h1>Title 1</h1>
  <p>foo...</p>
</card>
<card>
  <h1>Title 2</h1>
  <p>bar...</p>
</card>
</stack>

stack{ display: "a" "b"; }
stack h1 { position: a; }
stack card { radio-group: "foo"; }
stack card:not(:checked) :not(h1) { display:none; }

Four simple, easy-to-understand rules, and you've created all the
basic framework for an attractive tabbed interface.  You pull the
<h1>s out of the cards to function as tabs for them, and they flow
together like they were siblings for easy styling.  Since they're
still children of the <card>, though, they'll pass clicks upward to
their parent card appropriately (necessary for :checked).  As well,
their default presentation (within the card) is perfectly acceptable
without CSS.

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

Heh, I'd like to see builders construct every building on a new planet
with new materials and every contractor pulling along his own laws of
physics.  ^_^

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

That's some advanced hackery for doing footnotes without magic.  You
first pull the .note element down to a footnote area (::slot(F)).  The
fact that multiple elements can be flowed into a slot means that you
can have multiple footnotes per section/page.

Then, you create the ::before and flow it back into the @ slot.  Since
slots flow their contents in source order, the ::before moves back to
the space that the .note just vacated, leaving a counter there as an
indicator.  The font-size:larger is necessary to counteract the
font-size:smaller on .note, as ::before is still a child of .note and
will inherit the font-size change.  It's quite clever!

However, in my response I was talking about ::slot::before, which
Giovanni mentioned in a previous email.

~TJ

Received on Thursday, 30 April 2009 04:08:16 UTC