[whatwg] Should editable elements have placeholder attribute?

[Ian Hickson]

On Tue, 1 May 2012, Ryosuke Niwa wrote:
> 
> Would it be useful to have placeholder content attribute on elements 
> that are editable? (i.e. contenteditable=true).
> 
> According to the original WebKit bug 21286, this may reduce the amount 
> of code authors have to write.

contenteditable="" is a low-level primitive for creating text editors. 
It's not clear to me that there is much to be saved by adding a single 
high level feature on top of this. You'd still have to do a ton of work to 
make the editor work.

We can still make it easier to write the code, though. In fact, as far as 
I can tell, it needn't be especially hard with existing specs:

   [contenteditable]:empty::before { content: attr(data-placeholder) }

This wouldn't work if there's stray <br>s, etc, but if that's the only 
problem here, we can provide new selectors for it, as some people 
suggested. I recommend bringing that up in the CSSWG.


On Tue, 1 May 2012, Ryosuke Niwa wrote:
>
> Great. I think the tricky part will be defining exactly how and when the 
> placeholder is displayed.
> 
> e.g. Should it be treated as if there is a text node in the editable 
> element? Should we ignore things like "<br>" or collapsible spaces when 
> determining whether the element is empty or not?

What if parts of the element are positioned, transformed, animated, have 
an SVG filter applied, constantly mutated via the DOM API, etc, etc?


On Wed, 2 May 2012, Aryeh Gregor wrote:
> 
> Currently the spec isn't clear about this for <input>, so I don't think 
> it needs to specify exactly for <textarea> or contenteditable either.

I strongly disagree. <input> and <textarea> are high-level constructs, so 
it's fine for them to be defined by the UA's platform. But contenteditable 
is a very low-level primitive. We can't just punt on how it interacts with 
CSS; otherwise people will have no way to reliably make UIs with it.


On Wed, 2 May 2012, Alfonso Martínez de Lizarrondo wrote:
> 
> Recently I wrote such a plugin for CKEditor, it can be tested here: 
> http://alfonsoml.blogspot.com.es/2012/04/placeholder-text-in-ckeditor.html 
> I don't think that too many people request this feature, but that might 
> be simply because there are other bigger problems and they don't want to 
> waste the time with these details :-)
> 
> In my checks to see if the editor is empty I decided that empty means no 
> real content, only a paragraph or new line, and of course every browser 
> decided that clearing the content might mean a different default content 
> In the end this is the check that I'm using at the moment (I didn't 
> perform extensive tests, just enough to check that it seemed to work)
> 
> var value = data.replace( /[\n|\t]*/g, '' ).toLowerCase();
> if ( !value || value == '<br>' || value == '<p> <br></p>' || value ==
> '<p><br></p>' || value == '<p> </p>' )
>     return true;

Now there's a problem we should fix. Having five different representations 
of "nothing" seems like a terrible position for us to be in.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'