[whatwg] More HTML Editing Commands questions

Wed May 18 15:57:54 PDT 2011

On 18 May 2011 19:32, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> (I assume you meant to send this to the list and only accidentally
> sent it to me because I accidentally sent my reply to you instead of
> the list.  So I'm replying on-list.)

You're right, thanks. I failed to notice that.

>> Another argument against wrapping whitespace is that it can have an
>> unwelcome visual effect if, for example, the wrapping elements have a
>> CSS border applied.
>
> Borders only apply to boxes, and collapsed whitespace generates no
> boxes, so it will generate no border.  Nor backgrounds, margins,
> padding, etc.

That may be what the CSS spec says (I confess I haven't checked), but
the reality is that both Gecko and Opera produce an extra empty box
around the whitespace node inside the span between paragraphs in the
following example:

<!DOCTYPE HTML>
<html>
<head>
    <style type="text/css">
        span { border: solid black 1px; }
    </style>
</head>
<body>
    <p><span>One</span></p><span>
    </span><p><span>Two</span></p>
</body>
</html>

> I'm thinking I should define some concept like "ignored node", make
> the algorithms treat them specially, and require that implementations
> not allow users to create Selections in ignored nodes (although script
> still could).  This seems like it would roughly match browser
> behavior, although it would require testing.

In practice, I don't think I've observed that any browser allows
script to create a selection that the user cannot. Adding a range to
the selection that the browser can't handle (for example, a collapsed
range inside an empty inline element in WebKit) generally seems to
result in the selection approximating the position and getRangeAt()
returning a different range from the one that was added to it.

>>> You mean, with a collapsed selection?
>>
>> Yes. Caret, insertion point, cursor, collapsed selection. I never know
>> which to go for.
>
> "Collapsed" is the unambiguous term here, because it maps directly to
> the .collapsed property of Selection objects.
>
>>> I did write tests for that, but
>>> found that browsers do nothing special for collapsed selections.  But
>>> now I see that it's because I was only looking at the DOM.  It seems
>>> that when you run a command like "bold" on a collapsed selection, it
>>> doesn't do anything to the DOM, but it sets some internal flag or
>>> other that creates or splits or whatever the element when the user
>>> starts typing, and also changes the answer that queryCommandState()
>>> returns.
>>>
>>> I guess this is to avoid leaving useless elements littered around if
>>> the user decides not to type something after all.  The more obvious
>>> thing would be to create an empty tag and move the selection inside
>>> it.  But if this is what browsers do, I'll have to spec it.  Thanks
>>> for pointing it out to me, I've added it as an issue to the spec:
>>>
>>> http://aryeh.name/gitweb.cgi?p=editcommands;a=commitdiff;h=08c5d27
>>
>> This corresponds exactly with my conclusions. Note that creating an
>> empty element and moving the caret inside it is impossible (at least
>> via the Selection / Range APIs in JavaScript and also by attempting to
>> place the caret via mouse or keyboard) in WebKit
>> (https://bugs.webkit.org/show_bug.cgi?id=15256), IE < 9 and Opera.
>
> Well, not quite.  WebKit is subtler: it allows you to put the caret
> there if the element creates a box, or something like that.  Try
> adding an explicit height and width to the element, then it works.
> Opera doesn't seem to allow it at all, no.  IE < 9 I don't pay any
> attention to, for my sanity's sake.

That's a subtlety in WebKit that I didn't know about, but not terribly
useful in this instance, or in general. Regardless, browsers all do
the sensible thing (in my view) of creating no new elements until
content is entered, so no problem.

> But interesting point anyway.  It's plausible that maybe things only
> work this way because IE didn't allow the obvious thing, and then
> Gecko did allow the obvious thing but copied IE's behavior anyway, and
> IE kept the behavior even now that it does allow the obvious thing.
> Still, the spec should follow implementations when we have interop,
> unless there's good reason to the contrary.
>
>> This is another use case for a selection change event that works
>> reliably for any kind of selection change (see my mail to the list
>> about this last week): reliably keeping track of and removing styling
>> flags for content inserted at the current caret position is not
>> possible without such an event.
>
> I'm not sure why.  DOM mutation events in their current form (i.e.,
> synchronous) should work, no?  And if the selection change event is
> not synchronous, you might not be able to use it anyway, because maybe
> by the time the handler runs all sorts of changes happened and you
> don't know which happened before vs. after the selection change.

What I have in mind doesn't involve DOM mutation. Imagine the
selection is collapsed in the middle of a text node and the bold
command is called. The browser now has an internal flag set but there
is no change in the DOM. However, if the selection is moved away from
its current position, that flag is unset and that position is no
longer notionally bold, even if the selection is then returned to its
original position before anything else happens. This happens in all
browsers. To achieve this with JavaScript running in the page, you
need a reliable selection change event. For the purposes of simply
tracking the user moving the selection, an asynchronous event would be
fine.

Tim