[whatwg] More HTML Editing Commands questions

(Somehow Gmail's autodetection of from address failed, so this was
sent from the wrong address and bounced.  Resending, please resend any
feedback to the list.)

On Mon, May 16, 2011 at 6:59 AM, Tim Down <timdown at gmail.com> wrote:
> 1) Will there be any provision for special handling of whitespace text
> nodes? I notice that WebKit leaves them alone. For example, running
> document.execCommand("bold", false, null) for the following HTML with
> selection boundaries denoted by pipes:
>
> <p>|One</p>
> <p>Two|</p>
>
> ... in Chrome 10 you get
>
> <p>|<b>One</b></p>
> <p><b>Two|<b></p>
>
> The whitespace between the <p> elements has been ignored. This also
> leads to a bug, since it seems the check for whether the selection
> content is already completely bold does take into account the
> whitespace node and rerunning the command now has no effect. Opera
> surrounds the whitespace node within a styling element, while Firefox
> seems to have some voodoo magic to decide whether or not to surround a
> whitespace node. In the simple case above, it leaves it alone so long
> as I haven't previously manipulated the DOM manually with my own
> script.

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

Unless it's impossible for the user to put the cursor in that
particular whitespace node, I guess -- then it would make sense not to
bold it.  Perhaps that's actually the case here.  Quick testing seems
to show that I can't actually get the cursor in such a text node in
the browsers I tested.  Thanks for bringing this to my attention, I
expanded my existing issue a bit to remind me to look at it later:

http://aryeh.name/gitweb.cgi?p=editcommands;a=commitdiff;h=0f2f379f

> 2) Will the spec specify what happens when executing commands on an
> insertion point/caret?

You mean, with a collapsed selection?  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

Received on Monday, 16 May 2011 15:38:33 UTC