- From: Robin Berjon <robin@w3.org>
- Date: Fri, 23 May 2014 14:19:10 +0200
- To: Jonas Sicking <jonas@sicking.cc>, Piotr Koszuliński <p.koszulinski@cksource.com>
- CC: Ben Peters <Ben.Peters@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On 23/05/2014 11:55 , Jonas Sicking wrote: > On Thu, May 22, 2014 at 3:59 AM, Piotr Koszuliński >> 5. Navigating with arrow keys, selection with SHIFT, CTRL modifier. > > Agreed. Developers have to deal with selection moving around anyway > since they should handle touch screens. Even without accounting for touch screens, you really want the platform to be the thing that knows what Ctrl-Shift-Left means so you don't have to support it yourself (and get it wrong often). > But we should definitely fire events whenever cursor or selection is > moved and enable the page to either cancel the movement, or adjust the > location before it takes effect. Agreed. I also think that it is important that if the selection is allowed to have anchors both inside and outside the editing area then the editing MUST NOT retain focus. Anything else would lead to really annoying cases. Note: you keep saying things like "cursor or selection". Can we agree that they are the same thing? A caret on its own is a selection with a single collapsed range (and a direction). Which brings me to think: when we discussed this at the Summit, there was some agreement (between all four of us :) that it was a good idea to support multi-range selections. These are useful not just for tables, but also for bidi. The reason for the latter is that when selecting a line with multiple embedded directions (using a mouse), you want to have the visual selection be an unbroken line (as opposed to the crazy jumping around you get if you follow logical order). It's definitely useful, though it does come with its problems. The question that opens up for me is: do we want to support multi-caret editing as well? The data model certainly supports it, but we have to account for it early if it's an option. At any rate, multi-range selections would be much easier to handle if we had something like Selection.forEachRange(function (r) {...}). > Regarding text entry, I think this is the really hard decision that we > need to make. I.e. should we "only" fire enough semantic input events, > or also implement "plaintext" editing in addition. > > One interesting question is: Are pages generally happy with the > plaintext editing of <input type=text> and <textarea>? Or do they find > themselves often having to override their behavior using the events > that browsers fire? I would say yes and no. I don't think we need numbers to state that there's a lot of content out there that uses unadulterated input/textarea. But they're also handling what is guaranteed to be pure text. That is not at all the same as structured text. Also, a non-negligible subset of those do indeed override the browser's default behaviour. Typical cases are input masking or formatting. (Given the largely useless state of date inputs today, that's not going away any time soon, either.) > What are the use cases of events like compositionstart and > compositionend? Were they added in order to enable webpages to > override composition related editing of <input type=text> and > <textarea>? If you look at the examples I posted, you can see that you can't do your own rendering of composition unless you have these. As far as I know that's the primary use case. > What about the beforeinput event? My understanding is that it is cancellable while input is not, which enables people to pick the one they need based on their needs and its performance implications. A lot of sites nowadays do something like this: have a textarea in which you can enter Markdown, WikiText, or some other horrible goo and with every character you type a preview rendering of your text gets updated. If you use a cancellable text event and carry out the rendering in the event handler, the browser has to wait for the rendering to finish before it can paint the character in the source box. That leads to a small but perceptible lag. Presumably if you operate on events that have already had their default action carried out you're fine here. This isn't to say that this is perfect. It seems to me that this is an area of events that isn't all that interoperable yet so we have some leeway to change things. (Or perhaps even invent something new.) > I think there might be a lot of boiler plate needed to implement > plaintext editing. Not only are there normal "beforeinput" events to > take into account. There's also things like composition events, > backspace vs. delete, modifier+backspace/delete (deleting a > word/line), voice-to-text input (provides data word-by-word), pasting, > (bidi?), etc. It adds up pretty quickly. Not all of those are separate, though. Voice input is just an input (or beforeinput) that's more than one character long. There's nothing wrong with that. So is pasting (though you need cleaning up). Composition you need to handle, but I would really, really hope that the platform gives you a delete event with a range that matches what it is expected to delete rather than have you support all the modifiers (which you'll get wrong for the user as they are platform specific). As seen in the code gist I posted, given such a delete event the scripting is pretty simple. > Some of these things pages will have to deal with no matter what. As > has been pointed out, if the user selects across multiple elements and > presses delete or 'a', then almost certainly the page will have to run > application logic. Likewise if the cursor is placed right after an > element but before a bunch of text, and the user then presses > backspace. > > However it seems like if authors generally are ok with the plaintext > editing that <input type=text> and <textarea> has, and then only have > them worry about things like inserting elements to do styling or > inserting document structure (lists, headers, paragraphs, etc), then > that means less work for the author, and greater likelihood that text > editing works as the user expects. I'm sorry, but I'm not sure that the above makes sense :) If people want plain text and *nothing* else, I have a great solution for them: textarea. If you have a situation that involves markup however, you need to handle it. And I really, really don't think that we will be doing anyone a service if we end up with a solution in which the browser will handle text for you UNLESS you have an element-spanning selection OR MAYBE backspace right after an element AND PERHAPS delete right before one, etc. in which case you have to run some application logic. Maybe I'm missing something and there's an easy way to disambiguate here, but it seems like the sort of path down which madness lies. Do you have some code to illustrate how it would work? > I suspect that the right thing to do here is some experimentation. It > would be very interesting to do a prototype implementation of > contenteditable=minimal which never did any DOM mutations, not even > for IME or text editing. Then see how much code needs to handle all of > the plaintext editing features above. I think we can get a feel for that without having to polyfill cEmin first. That would be neat of course, but given the poor support of even very basic things like selections it's not a small project. > Another thing that we should look at is the ability to style ranges > rather than just elements. In Gecko we have an internal feature that > allows us to style DOMRanges. This allows us to render a red dotted > line under misspelled words and black line under composition > characters. And do that without worrying about managing a lot of extra > elements in the DOM. Yeah, I had the same idea, used it in my example. I think it makes a lot of sense. > Right now pages are forced to sprinkle elements all over the DOM in > order to do the same thing, which then makes editing that DOM more > complex. It would be awesome to find ways to enable styling ranges > which would allow them to keep a simpler DOM. It would actually be pretty awesome. -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Friday, 23 May 2014 12:19:23 UTC