- From: Yoshifumi Inoue <yosin@chromium.org>
- Date: Mon, 26 May 2014 11:17:56 +0900
- To: Robin Berjon <robin@w3.org>
- Cc: Piotr Koszuliński <p.koszulinski@cksource.com>, Jonas Sicking <jonas@sicking.cc>, Ben Peters <Ben.Peters@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>
- Message-ID: <CABJ-EHPuHOzJ2P_aRvwM3Q9tXdONW3VM9cssaaNk4wLH7ODWSQ@mail.gmail.com>
Range.style is cool idea! I assume Range.detach() removes styles added Range.style. To implement text composition with this, I would like to have "wave underline", "dotted underline", "thick underline" etc. Example:: http://www.w3.org/TR/2012/WD-ime-api-20120524/images/image13.png Also, we can use Range.style for highlighting find result and spelling error. -yosi On Fri, May 23, 2014 at 8:39 PM, Robin Berjon <robin@w3.org> wrote: > 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 Monday, 26 May 2014 02:18:24 UTC