Re: [whatwg] Should editable elements have placeholder attribute?

On Sat, Sep 1, 2012 at 4:22 AM, David Young <dyoung@pobox.com> wrote:
> This demonstrates some unexpected contenteditable results on
> Chrome 21.0.1180.82 under Mac OS X.  I cannot seem to return the
> contenteditable to the empty state again---i.e., to the state where the
> placeholder shows---using Chrome.  All that I have entered is a space.
> Backspacing over the space leaves a <br>.  Inserting a space again
> deletes the <br>.
>
> In Firefox 3.6.19 it is necessary to insert two spaces before a <br>
> appears; the <br> cannot be deleted, not even by inserting a space. :-)

It should never be possible to make a contenteditable element contain
nothing, once it has something in it, because then it would collapse
to zero height and you wouldn't be able to click on it.  (IIRC, some
browsers have non-standard special cases for contenteditable elements
and make them one line high even if they're empty, but this isn't per
spec.)

So if nothing else would be left, browsers are supposed to put a <br>
in, which they remove as soon as anything else would stop it from
collapsing.  WebKit does this pretty much per spec.  Gecko doesn't
bother removing the <br>'s it's added, which is messier and not per
spec.  IE uses &nbsp;'s instead of <br>'s to stop collapsing, last I
checked, except IIRC, they're magical and can vanish depending on
whether you look at them with DOM methods vs. innerHTML.

All this is relevant to any contenteditable element, incidentally, not
just the editing host.  If you have <p>x</p> and the user backspaces
over the "x", it's supposed to become <p><br></p>.

Received on Thursday, 6 September 2012 10:57:50 UTC