[whatwg] Should editable elements have placeholder attribute?

[Ojan Vafai]

On Thu, Sep 6, 2012 at 3:56 AM, Aryeh Gregor <ayg at aryeh.name> wrote:

> On Sat, Sep 1, 2012 at 4:22 AM, David Young <dyoung at 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  '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.
>

While WebKit does put the magic <br> in, that's not what avoids the
collapsing in this case. If you set the innerHTML to "", it still doesn't
collapse. We actually hard-code that editing hosts don't collapse.


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