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

On Wed, Aug 29, 2012 at 4:27 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Sun, 17 Jun 2012, Aryeh Gregor wrote:
> > On Thu, Jun 14, 2012 at 1:11 AM, Ian Hickson <ian@hixie.ch> wrote:
> > > 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.
> >
> > I don't know why you think contenteditable is "lower-level" than
> > input/textarea.
>
> By "high level" I mean something that is self-contained, usable as a
> standalone feature, which typically integrates with other features in an
> atomic fashion; "lower-level", then, means something that in comparison
> requires more work to use, can only be used in conjunction with something
> else, etc. By analogy, a fruit juice box is high-level: it comes with its
> own straw, it doesn't need any additional tools to open it, it provides a
> final product without requiring any additional work. On the other hand, a
> can of frozen grape concentrate requires a bowl in which to mix the
> concentrate and some water, a spoon to stir them together, a jug from
> which to pour the result, a glass in which to pour it and from which to
> drink the resulting fruit juice.
>
> <input type=text> is a high-level construct: it provides a self-contained
> place in which text can be entered, it plugs straight into the form
> submission system, it exposes hooks for setting the value or retrieving
> the user's input that do not require knowing how the control works.
>
> contenteditable="", on the other hand, exposes the DOM directly, has no
> integration with other features like form submission, has a much less
> obvious boundary between it and surrounding content... if you want to use
> it in real content, there's no way to do it without script of some kind,
> and if you want to use it to do anything especially compelling, you need a
> lot of script (to provide all the UI for formatting, etc).
>
> This isn't a criticism of contenteditable="". Low-level primitives are the
> building blocks of platforms. But it does mean that we have different
> tradeoffs to make in the designs of the features.
>
>
> > >> 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>&nbsp;<br></p>' ||
> value ==
> > >> '<p><br></p>' || value == '<p>&nbsp;</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.
> >
> > If you type some stuff and then delete it all, the desired result will
> > vary based on lots of factors, e.g.:
> >
> > * Whether <div> or <p> is being used for paragraph separators.  Both
> > <p><br></p> and <div><br></div> might make sense for "nothing",
> > depending.  This is author-configurable using the
> > defaultParagraphSeparator command.
> >
> > * Whether there was any styling present before.  If all the text was
> > previously bold, for instance, deleting everything might result in
> > something like <p><b><br></b></p>, because per spec, deletion doesn't
> > remove style tags from empty lines.
> >
> > * Whether there was any other special markup.  If something (like
> > execCommand("insertHTML")) made the first line have <p id="foo">, then
> > deleting everything would result in <p id="foo"><br></p>.
> >
> > * What the author specified as the initial contents of the editable
> > area.  If you have <div contenteditable><br></div> to start with, and
> > the user puts the cursor there and then types "foo" and then deletes
> > it, you'll go back to having just <br>, because nothing ever inserted
> > a <p> or <div> or anything.  (As soon as the user hits Enter, both the
> > old and new lines are wrapped in a paragraph separator per spec,
> > although only IE/Opera do this right now.)
> >
> > Really, you can have any HTML markup at all in contenteditable, and we
> > can't avoid that.  There's not going to be any reliable way to figure
> > out what "nothing" is if you can't answer the same question for
> > arbitrary HTML.
>
> Maybe the right way to detect "nothing" is to compare textContent against
> "" and then to look for specific elements that count as palpable content,
> like <img>. Would it make sense to provide an API for that?
>

Seems reasonable to me. That's the trickiest part of making this work from
script. If you had an API for this, hooking focus/blur events is pretty
straightforward. If, in the end, we still decide to add placeholder, it
will just use this API anyways.

Ojan

Received on Wednesday, 5 September 2012 20:54:43 UTC