[whatwg] Should editable elements have placeholder attribute?
ojan at chromium.org
Thu Sep 6 08:53:42 PDT 2012
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
> 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>.
More information about the whatwg