- From: Ojan Vafai <ojan@chromium.org>
- Date: Wed, 5 Sep 2012 13:53:53 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg@lists.whatwg.org, Aryeh Gregor <ayg@aryeh.name>
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> <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. > > > > 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