[whatwg] Should editable elements have placeholder attribute?

[Simon Pieters]

On Thu, 13 Sep 2012 23:04:13 +0200, Ojan Vafai <ojan at chromium.org> wrote:

>> But on the other hand, it looks like everyone but Gecko does do it,
>> although I'm sure the details are totally different.  And it's
>> certainly nice for usability.  So it would be nice if we had some good
>> way to spec it.  I wonder if Opera does it in a saner-to-spec way.

I think Opera generally tries to automatically focus the *first*  
contenteditable element (at least for top-level browsing context), which  
inserts a <br> (the <br> adding still happens for iframed documents even  
though we don't focus in that case).

See http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1767  
(click "Rendered view" to get it in a top-level browsing context).

However, this auto-focusing is not implemented by other browsers for  
contenteditable (only for designMode) and has caused us some minor  
problems, so we're most likely going to stop doing so. Automatically  
inserting a <br> before the user has put the caret there seems a bit  
annoying and makes the :empty selector never match.

> The way I'd want to see this happen is to expose a CSS property that
> prevents collapsing empty elements, then we'd add something like the
> following to the UA stylesheet:
> *[contentEditable=true] { empty-collapse-behavior: no-collapse }

That sounds like a good solution on first blush and might even be  
something authors would like to use for other elements. However, the  
selector is wrong since contenteditable is an enumerated attribute which  
allow mixed case, and further the empty string is a valid keyword (meaning  
true). I think this would be correct:

*[contenteditable=true i], *[contenteditable=""] {  
empty-collapse-behavior: no-collapse }

(Bikeshedding: I think the "-behavior" part is usually omitted in CSS;  
c.f. border-collapse.)

-- 
Simon Pieters
Opera Software