[whatwg] More HTML Editing Commands questions

[Aryeh Gregor]

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

On Mon, May 16, 2011 at 4:51 PM, Tim Down <timdown at gmail.com> wrote:
> On 16 May 2011 19:45, Aryeh Gregor <simetrical at gmail.com> wrote:
>> Whitespace-only text nodes will probably need special handling for a
>> bunch of things.  This is one of the issues I list:
>>
>> """
>> I need to pay more attention to whitespace-only nodes. In most cases
>> these will have no visual effect, but they'll make many algorithms
>> behave differently: decomposing a range, block-extending, etc.
>> """
>> http://aryeh.name/spec/editcommands/editcommands.html#issues
>>
>> But I'm not sure I see any need for special handling here.  Currently
>> the algorithm will produce
>>
>> <p>|<b>One</b></p><b>
>> </b><p><b>Two|<b></p>
>>
>> If you don't wrap the whitespace, the user might put their cursor
>> there and it won't be bold when they start typing and they'll be
>> confused.  In a quick test, IE and Opera seem to wrap the node, Gecko
>> and WebKit don't (but you say that Gecko even does, in some cases).
>
> I observed Gecko doing this after twice executing my own bold command
> using the algorithm from the spec (thus apparently restoring the
> original DOM state) and then running the native command. Unfortunately
> as you know the command does quite a bit of DOM manipulation and I
> haven't been able to determine which one persuades Gecko to wrap the
> whitespace node, or produce a simple test case that reproduces it. I
> can reproduce it complicatedly though.

My approach is to try to throw reasonable test-cases at the spec and
various browsers, and refine the spec until it gives the results I
want on all the test-cases.  If browsers behave differently in odd
cases, like when the DOM has been modified in particular ways using
JavaScript, it doesn't matter much to me unless I'm aware of a
specific case where that gives some advantage.  At some point I plan
to look over various implementations' code and bug trackers to see if
I can find more non-obvious test-cases, but that's still a while off.
Better to get the obvious stuff right first so I have a solid base to
work on.

>> I'd be inclined to stick to current behavior.  It will make the
>> serialization a bit messier, it's true, but not bolding it at all
>> seems like it poses bigger problems.
>
> 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.

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.

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

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.