- From: Robin Berjon <robin@w3.org>
- Date: Fri, 23 May 2014 13:39:41 +0200
- To: Piotr Koszuliński <p.koszulinski@cksource.com>, Jonas Sicking <jonas@sicking.cc>
- CC: Ben Peters <Ben.Peters@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>
Starting a new thread for this specific topic as I think it's one of the important early points of contention. On 22/05/2014 12:59 , Piotr Koszuliński wrote: > 3. Typing characters. It works in textarea and I think it should work > out of the box in cE=minimal. Otherwise, cE=minimal will be useless for > simple cases (mentioned Twitter), because you'll always need a pretty > complex library to handle text input. Additionally, I don't remember any > problem with typing characters, so this seems to work well already in > cE=true. There's also the IME which scares me, but I don't have any > experience with it. I hear your point about essentially making simple things simple, but I really want to resist supporting as much built-in behaviour as possible. Of course, it's a trade-off, but I think we should strive for the smallest possible amount of behaviour. Note that 1) the complexity of simple things by and large depends on the quality of the primitives we provide and 2) on the interoperability of what is supported. And the simpler the functionality, the more easily interoperable. Inserting text as the default behaviour for text input events has implications: Things get very weird if you support it when you have a caret (i.e. a collapsed selection) but not when you have a selection. And a selection can have arbitrary endpoints around and into an element. This means that typing with an active selection can do more than add some text to a node: it can delete or modify elements. Sure enough this can be described interoperably, but it does bring us back to issues we dislike. It also means that the browser needs to handle composition and its rendering, which while it is ongoing may produce relatively weird states in the DOM. I agree that the Twitter box is a good very basic example. It basically needs: 1) Words that start with @ or # to be a specific colour. 2) Links to be a different colour, and to have their characters counted as the shortened link rather than the full thing. 3) Newlines must be taken into account. 4) Characters beyond 140 are highlighted in red. I'm ignoring complications with files and the such. In fact, for the purpose of our use case it is only useful IMHO to look at how best to handle (3) and (4). I tried to bang together some code that would do the Twitter box, adding a few features along the way and documenting assumptions and issues. It looks like that (untested, off the top of my head): https://gist.github.com/darobin/8a128f05106d0e02717b#file-twitter-html It looks a bit scary, but if you remove the part that handles excess text and the wordy comments, you just get: https://gist.github.com/darobin/8a128f05106d0e02717b#file-like-textarea-html Granted, that's still a fair bit of boilerplate. But I think we have to take into account the following: • This is meant to be low-level. I'm happy to make things easier but only so long as we don't introduce magic. • We can make introduce some convenience methods for the non-obvious parts of the boilerplate. Just having Selection.replace(node|text...) or something like new Range(sNode, sOffset, eNode, eOffset) would make things a lot nicer. It's likely I've forgotten stuff though (notably paste filtering, which I'm unsure how to best handle here — see comments). Please review the code so that we have an idea for a baseline of what we'd like to get at the end. -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Friday, 23 May 2014 11:39:53 UTC