Re: Should minimal contentEditable default text input (was: contentEditable=minimal)
On May 26, 2014, at 1:25 AM, Anne van Kesteren wrote: > On Mon, May 26, 2014 at 4:17 AM, Yoshifumi Inoue wrote: >> To implement text composition with this, I would like to have "wave >> underline", "dotted underline", "thick underline" etc. > > Range.prototype.style seems complex in the context of overlapping > ranges and such. Suddenly you're no longer applying CSS to a tree. Yeah, especially if we allow text layout to be affected by this, e.g. bolding, font size. That would require some fundamental changes to our engine (WebKit). We can probably add the ability to style text without affecting layout though; e.g. background color, underline. - R. Niwa
Re: Should minimal contentEditable default text input (was: contentEditable=minimal)
On May 29, 2014, at 3:50 PM, Julie Parent wrote: > Without default text input, the current proposal for > contentEditable="minimal" is essentially just enabling cursors (drawing them, > dispatching events, performing default actions). Rather than calling the > mode "minimal", which is ill-defined, why not explicitly call it what it is: > "cursor-only"? Or, have contentEditable take a list of features to turn > enable: contentEditable="enable-cursors enable-CommandEvents". > > Or, rather than tying this concept to contentEditable, with all the > assumptions and complications that brings up, why not expose this building > block as a completely separate attribute? Explicitly listing features to enable sounds like a superior approach. - R. Niwa
Re: Should minimal contentEditable default text input
On 30/05/2014 00:50 , Julie Parent wrote: Without default text input, the current proposal for contentEditable="minimal" is essentially just enabling cursors (drawing them, dispatching events, performing default actions). Rather than calling the mode "minimal", which is ill-defined, why not explicitly call it what it is: "cursor-only"? Sure, but (assuming we go this route) I'm not too worried about the name at the moment. We can define what it does, then pick a good name for it. That's the easiest bit to change. Or, have contentEditable take a list of features to turn enable: contentEditable="enable-cursors enable-CommandEvents". I'd rather we agreed on the pieces we're going to have before we see if this can make sense. Or, rather than tying this concept to contentEditable, with all the assumptions and complications that brings up, why not expose this building block as a completely separate attribute? We can, but this isn't necessarily simpler. Saying we add an "editable" attribute, we then have to define what happens when you have contentEditable editable> (and various other niceties). It's not the end of the world, but it's a bit of extra complexity. Reusing the attribute name and giving it a value that triggers new behaviour doesn't bring in the complications, but it does give us a relatively clean syntax entry point. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: Should minimal contentEditable default text input
On 30/05/2014 08:25 , Anne van Kesteren wrote:
On Fri, May 30, 2014 at 12:50 AM, Julie Parent wrote:
Or, rather than tying this concept to contentEditable, with all the
assumptions and complications that brings up, why not expose this building
block as a completely separate attribute?
Just a DOM API perhaps as you're not going to get far without
scripting anyway?
I prefer it to be possible to say [contentEditable] { outline: dotted
1px; }. There's :read-write but it also matches input/textarea.
--
Robin Berjon - http://berjon.com/ - @robinberjon
Re: Should minimal contentEditable default text input (was: contentEditable=minimal)
On Fri, May 30, 2014 at 12:50 AM, Julie Parent wrote: > Or, rather than tying this concept to contentEditable, with all the > assumptions and complications that brings up, why not expose this building > block as a completely separate attribute? Just a DOM API perhaps as you're not going to get far without scripting anyway? Interaction with contentEditable features will have to be defined. This could maybe throw if the element was already editable and if this is already active, maybe contentEditable stuff should have no effect. -- http://annevankesteren.nl/
Re: Should minimal contentEditable default text input (was: contentEditable=minimal)
Without default text input, the current proposal for contentEditable="minimal" is essentially just enabling cursors (drawing them, dispatching events, performing default actions). Rather than calling the mode "minimal", which is ill-defined, why not explicitly call it what it is: "cursor-only"? Or, have contentEditable take a list of features to turn enable: contentEditable="enable-cursors enable-CommandEvents". Or, rather than tying this concept to contentEditable, with all the assumptions and complications that brings up, why not expose this building block as a completely separate attribute? On Mon, May 26, 2014 at 1:25 AM, Anne van Kesteren wrote: > On Mon, May 26, 2014 at 4:17 AM, Yoshifumi Inoue > wrote: > > Range.style is cool idea! I assume Range.detach() removes styles added > > Range.style. > > detach() is a no-op. http://dom.spec.whatwg.org/#dom-range-detach > > > > To implement text composition with this, I would like to have "wave > > underline", "dotted underline", "thick underline" etc. > > Range.prototype.style seems complex in the context of overlapping > ranges and such. Suddenly you're no longer applying CSS to a tree. > > > -- > http://annevankesteren.nl/ > >
Re: Should minimal contentEditable default text input
On 26/05/2014 10:25 , Anne van Kesteren wrote: On Mon, May 26, 2014 at 4:17 AM, Yoshifumi Inoue wrote: Range.style is cool idea! I assume Range.detach() removes styles added Range.style. detach() is a no-op. http://dom.spec.whatwg.org/#dom-range-detach You're jumping in without context. In talking about Range.style you need a way of clearing that style once attached. Range.detach() was suggested as a possible candidate there To implement text composition with this, I would like to have "wave underline", "dotted underline", "thick underline" etc. Range.prototype.style seems complex in the context of overlapping ranges and such. Suddenly you're no longer applying CSS to a tree. So, since Gecko supports that, do you know how it's done? -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: Should minimal contentEditable default text input (was: contentEditable=minimal)
On Mon, May 26, 2014 at 4:17 AM, Yoshifumi Inoue wrote: > Range.style is cool idea! I assume Range.detach() removes styles added > Range.style. detach() is a no-op. http://dom.spec.whatwg.org/#dom-range-detach > To implement text composition with this, I would like to have "wave > underline", "dotted underline", "thick underline" etc. Range.prototype.style seems complex in the context of overlapping ranges and such. Suddenly you're no longer applying CSS to a tree. -- http://annevankesteren.nl/
Re: Should minimal contentEditable default text input (was: contentEditable=minimal)
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 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 > >
Should minimal contentEditable default text input (was: contentEditable=minimal)
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
