[whatwg] More HTML Editing Commands questions

Thu May 19 13:10:05 PDT 2011

On Wed, May 18, 2011 at 6:57 PM, Tim Down <timdown at gmail.com> wrote:
> 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>

My bad.  I didn't check the spec, I just tested in my current browser,
which happens to be Chrome.  You're right, all non-WebKit browsers do
draw a border there.

(You know that

<!DOCTYPE HTML>
<style>
    span { border: solid black 1px; }
</style>
<p><span>One</span></p><span>
</span><p><span>Two</span></p>

will behave the same as what you wrote and is just as conformant, right?)

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

I just wrote and checked in some tests for this:

http://aryeh.name/spec/dom-range/test/Selection-addRange.html

Chrome 12 dev and Opera 11.10 both seem averse to addRange() on ranges
the user couldn't reasonably create, like ones in display: none
elements.  (You can't tell from those tests with Opera, because other
bugs mask the results, but I tried independently on simpler test
cases.)  Opera tends to silently fail if it doesn't like the range,
while WebKit will try to adjust it to the nearest acceptable range in
the document if possible, and silently fails otherwise.

On the other hand, Firefox 4.0 passes every test, so it allows
arbitrary or essentially arbitrary selections to be created by script.
 IE9 doesn't like endpoints in hidden things, like nodes from other
documents or things hidden by display: none, but it seems to tolerate
them in some cases, and allows some selections that the user could
certainly never create (like in document.documentElement).

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

Assuming that your goal here is to replicate execCommand() from
JavaScript, what happens if the user puts the selection somewhere,
bolds, types something, then moves the selection elsewhere?  I guess
that works fine if there are reliable input events (are there?), and
they're ordered properly with respect to the selection change events.

On Wed, May 18, 2011 at 10:32 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> The collapsed whitespace generates no box, but the inline element sure
> generates a box per spec.  And that box can have padding, borders, margins,
> the works.  Aryeh, I suggest actually trying this in your favorite browser.

I did.  Unfortunately, that's all I did, and my favorite browser is
currently Chrome.  :)  I stand corrected.