W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: Should minimal contentEditable default text input (was: contentEditable=minimal)

From: Yoshifumi Inoue <yosin@chromium.org>
Date: Mon, 26 May 2014 11:17:56 +0900
Message-ID: <CABJ-EHPuHOzJ2P_aRvwM3Q9tXdONW3VM9cssaaNk4wLH7ODWSQ@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC