subject:"contentEditable=minimal"


On 28/05/2014 01:39 , Julie Parent wrote:

The discussion of which minimal default handling to include with
contenteditable=minimal makes me wonder if contentEditable=minimal
is necessary at all.  It quickly becomes a can of worms of *which*
default handling should be included, and it seems likely to not satisfy
every use case no matter which decisions are made.  However, minimal
is proposed as a building block because currently, disabling all default
functionality of contentEditable=true is difficult/impossible.  But
with CommandEvents, shouldn't contentEditable=minimal be equivalent to:

// Let editRegion be div contentEditable id='editRegion'

var editRegion = document.getElementById(editRegion);
editRegion.addEventListener(command, handleCommand);
function handleCommand(evt){
   evt.preventDefault();
}

No default actions would be taken, but selection events would still fire
and be handled.  There would be no ambiguity.  If implementing
contentEditable=minimal on top of CommandEvents could just be a few
lines of code, why complicate things by spec'ing another property?


I like the simplicity of this approach, but I have some concerns.

As Travis points out, this implies that all events have to be 
cancellable in this context. This can lead to problems (like we had with 
mutations), it can also have performance implications.


Another aspect that may be problematic is the case of UAs that provide a 
UI (like Safari Mobile) whenever they see contentEditable. I was hoping 
that contentEditable=minimal would serve as a sanity flag not to include 
that. In the above it's not possible.


I am not sure that we can have this work properly without specifying the 
default behaviour, which as we all know is a terrible mess. If you don't 
have reliable default behaviour, can you really rely on the browser to 
DTRT for the cases you don't wish to handle? Won't you end up having to 
use a library anyway?


Again, I'm all for the simplicity; I'm just worried about the snoring 
dragon.


--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: contentEditable=minimal


On 05/06/2014 09:02 , Ryosuke Niwa wrote:

I agree visual selection of bidirectional text is a problem worth
solving but I don't think adding a generic multi-range selection
support to the degree Gecko does is the right solution.


I'd be interested to hear how you propose to solve it in another manner. 
Also note that that's not the only use case, there are other 
possibilities for disjoint selections, e.g. a table (naturally) or an 
editable surface with a non-editable island inside.



 For
starters, most of author scripts completely ignore all but the first
range, and applying editing operations to a multi-range selection is
a nightmare.


I don't disagree that it can be hard to handle, but I'm not sure that 
that's indicative of anything. Most scripts only handle one selection 
because AFAIK only Gecko ever supported more than one.


--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: contentEditable=minimal


On 02/06/2014 23:01 , Ben Peters wrote:

From: Robin Berjon [mailto:ro...@w3.org] I think that the latter is
better because it gives the library the computed range that matches
the operation, which as far as I can imagine is what you actually
want to check (e.g. check that the newRange does not contain
something unselectable, isn't outside a given boundary, etc.).

The former requires getting a lot of details right in the spec, and
those would become hard to handle at the script level. On some
platforms a triple click (or some key binding) can select the whole
line. This not only means that you need direction: both but also
that the script needs a notion of line that it has no access to
(unless the Selection API grants it). What makes up a word as a
step also varies a lot (e.g. I tend to get confused by what Office
apps think a word is as it doesn't match the platform's idea) and
there can be interesting interactions with language (e.g. is
passive-aggressive one word or two? What about co-operation?).

But maybe you have a use case for providing the information in that
way that I am not thinking of?


This seems like it's getting pretty close to the browser just doing
the selection. A browser would still have to figure out what the
selection should look like in the version you suggest. Instead, maybe
each site could decide what is thinks is a word (passive or
passive-agressive). The line example is good, so maybe we should
have a 'line' level selection just like the 'word' level?


Yes, the way I see it the browser *always* figures out what the 
selection is; but the developer gets a chance to cancel (or modify) it.



Yes my understanding is that today you get both. I'm not arguing
against that as the events stand today, but when we talk about
'Intention Events' as an abstract type with certain properties like
commandName, I think you should only get one of those (paste or
command or beforeinput), and I'm suggesting that it should be paste
in this case.


Agreed, that's sanity.

--
Robin Berjon - http://berjon.com/ - @robinberjon

Composition, IME, etc. (was: contentEditable=minimal)


On 05/06/2014 09:09 , Ryosuke Niwa wrote:

On May 23, 2014, at 1:37 PM, Robin Berjon ro...@w3.org wrote:

Semantically, autocorrect and compositing really are the same
thing.


They are not.  Word substations and input method compositions are
semantically different operations.


Ok, I'll accept that depending on the level of abstraction at which 
you're looking at the problem they may or may not be the same thing.


The core of the problem is this: there is a wide array of situations in 
which some form of indirect text input (deliberately going for a new 
term with no baggage) takes place. This includes (but is not limited to):


  • dead key composition (Alt-N, N - ñ)
  • assumed international composition (',e - é, if you just want an 
apostrophe you have to compose ',space)

  • inline composition for pretty much everything
  • popup composition
  • autocorrect
  • speed-typing input (T9, swiping inputs)

In order to handle them you have two basic options:

  a) Let the browser handle them for you (possibly calling up some 
platform functionality). This works as closely to user expectations as a 
Web app can hope to get but how do you render it? If it touches your DOM 
then you lose the indirection you need for sensible editing; if it 
doesn't I don't know how you show it.


  b) Provide the app with enough information to do the right thing. 
This gives you the indirection, but doing the right thing can be 
pretty hard.


I am still leaning towards (b) being the approach to follow, but I'll 
admit that that's mostly because I can't see how to make (a) actually 
work. If (b) is the way, then we need to make sure that it's not so hard 
that everyone gets it wrong as soon as the input is anything other than 
basic English.



Note that if there is a degree of refinement such that we may want
to make it possible for authors to style compositing-for-characters
and compositing-for-autocorrect, then that ought to go into the
styling system.


In older versions of Windows, for example, the browser itself can't
figure out what kind of style is used by IME.  Korean and Japanese
IME on Windows, for example, use bolded lines and dotted lines for
opposite purposes.  And we get bug reports saying that WebKit's
rendering for Korean IME is incorrect because we decided to follow
Japanese IME's convention.


Right. In this case we need to distinguish between the browser not 
knowing and the Web app not knowing.


If the browser doesn't know because the platform can't tell the 
difference between Korean and Japanese (a problem with which Unicode 
doesn't help) then there really isn't much that we can do to help the 
Web app.


However if the browser knows, it can provide the app with information. I 
don't have enough expertise to know how much information it needs to 
convey — if it's mostly style that can be done (it might be unwieldy to 
handle but we can look at it).



We /could/ consider adding a field to compositing events that would
capture some form of ontology of input systems. But I think that's
sort of far-fetched and we can get by with the above. (And yes, I'm
using ontology on purpose. It wouldn't look good :)


In my opinion, it's a requirement that input methods work and look
native on editors that use this new API.  IME is not a nice-to-have
feature.  It's a feature required for billions of people to type any
text.


That is *exactly* my point. At this point I believe that if we just 
added something like a compositionType = deadkey | kr | jp | t9 | 
autocorrect | ... field and leave it at that we're not helping anyone. 
The script will need to know not just how to render all of these but how 
they are supposed to look on each platform. That's why I am arguing for 
primitives that enable the script to do the right thing *without* having 
to know everything about all the possible IMEs.


Having said that, I was initially hoping that a mixture of composition 
events plus IME API would cover a lot of ground already. Thinking about 
it some more, it's not enough.


Can you help me come up with a list of aspects that need to be captured 
in order to enable the app to render the right UI? Or do you have 
another proposal?


--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: [editing] CommandEvent and contentEditable=minimal Explainer


On Jun 6, 2014, at 6:27 AM, Robin Berjon ro...@w3.org wrote:

 On 28/05/2014 01:39 , Julie Parent wrote:
 The discussion of which minimal default handling to include with
 contenteditable=minimal makes me wonder if contentEditable=minimal
 is necessary at all.  It quickly becomes a can of worms of *which*
 default handling should be included, and it seems likely to not satisfy
 every use case no matter which decisions are made.  However, minimal
 is proposed as a building block because currently, disabling all default
 functionality of contentEditable=true is difficult/impossible.  But
 with CommandEvents, shouldn't contentEditable=minimal be equivalent to:
 
 // Let editRegion be div contentEditable id='editRegion'
 
 var editRegion = document.getElementById(editRegion);
 editRegion.addEventListener(command, handleCommand);
 function handleCommand(evt){
   evt.preventDefault();
 }
 
 No default actions would be taken, but selection events would still fire
 and be handled.  There would be no ambiguity.  If implementing
 contentEditable=minimal on top of CommandEvents could just be a few
 lines of code, why complicate things by spec'ing another property?
 
 I like the simplicity of this approach, but I have some concerns.
 
 As Travis points out, this implies that all events have to be cancellable in 
 this context. This can lead to problems (like we had with mutations), it can 
 also have performance implications.

I don't think it will cause problems like mutation events as long as we make 
execCommand non-reentrant.  Asking whether each node can be removed or inserted 
could cause serious problems due to other precondition checks having been 
perfumed already at that point, but firing another event before running an 
execCommand implementation is easy  safe since we already fire other events 
like beforeinput.

 Another aspect that may be problematic is the case of UAs that provide a UI 
 (like Safari Mobile) whenever they see contentEditable. I was hoping that 
 contentEditable=minimal would serve as a sanity flag not to include that. In 
 the above it's not possible.

This makes me think that what we need is a way to hook selection  default 
editing behaviors optimally.  However, we need to need a way to tell UA that an 
element is editable for assistive technology.  Ideally, we don't need to rely 
on ARIA role for that.

- R. Niwa

Re: contentEditable=minimal

On Jun 6, 2014, at 6:40 AM, Robin Berjon ro...@w3.org wrote:
 On 05/06/2014 09:02 , Ryosuke Niwa wrote:
 I agree visual selection of bidirectional text is a problem worth
 solving but I don't think adding a generic multi-range selection
 support to the degree Gecko does is the right solution.
 
 I'd be interested to hear how you propose to solve it in another manner. Also 
 note that that's not the only use case, there are other possibilities for 
 disjoint selections, e.g. a table (naturally) or an editable surface with a 
 non-editable island inside.

Supporting disjoint range is probably necessary but adding the ability to 
manipulate each range separately seems excessive because that'll lead to 
selections with overlapping ranges, ranges in completely different locations 
that are not visually disjoint, etc...  We might need to do something like 
exposing readonly multi-range selection.

 For starters, most of author scripts completely ignore all but the first
 range, and applying editing operations to a multi-range selection is
 a nightmare.
 
 I don't disagree that it can be hard to handle, but I'm not sure that that's 
 indicative of anything. Most scripts only handle one selection because AFAIK 
 only Gecko ever supported more than one.

Given Gecko itself doesn't handle applying editing operations to multiple 
ranges well from what I've heard, I'm not certain we can expect web developers 
to get them right especially in the context where disjoint multi-range 
selection is needed; e.g. bidirectional text, exotic layout model.

- R. Niwa

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

On May 29, 2014, at 3:50 PM, Julie Parent jpar...@gmail.com 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 (was: contentEditable=minimal)

On May 26, 2014, at 1:25 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Mon, May 26, 2014 at 4:17 AM, Yoshifumi Inoue yo...@chromium.org 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: Composition, IME, etc. (was: contentEditable=minimal)


On Jun 6, 2014, at 7:24 AM, Robin Berjon ro...@w3.org wrote:

 On 05/06/2014 09:09 , Ryosuke Niwa wrote:
 On May 23, 2014, at 1:37 PM, Robin Berjon ro...@w3.org wrote:
 Semantically, autocorrect and compositing really are the same
 thing.
 
 They are not.  Word substations and input method compositions are
 semantically different operations.
 
 Ok, I'll accept that depending on the level of abstraction at which you're 
 looking at the problem they may or may not be the same thing.
 
 The core of the problem is this: there is a wide array of situations in which 
 some form of indirect text input (deliberately going for a new term with no 
 baggage) takes place. This includes (but is not limited to):
 
  • dead key composition (Alt-N, N - ñ)
  • assumed international composition (',e - é, if you just want an 
 apostrophe you have to compose ',space)
  • inline composition for pretty much everything
  • popup composition
  • autocorrect
  • speed-typing input (T9, swiping inputs)
 
 In order to handle them you have two basic options:
 
  a) Let the browser handle them for you (possibly calling up some platform 
 functionality). This works as closely to user expectations as a Web app can 
 hope to get but how do you render it? If it touches your DOM then you lose 
 the indirection you need for sensible editing; if it doesn't I don't know how 
 you show it.
 
  b) Provide the app with enough information to do the right thing. This gives 
 you the indirection, but doing the right thing can be pretty hard.
 
 I am still leaning towards (b) being the approach to follow, but I'll admit 
 that that's mostly because I can't see how to make (a) actually work. If (b) 
 is the way, then we need to make sure that it's not so hard that everyone 
 gets it wrong as soon as the input is anything other than basic English.

I'm not convinced b is the right approach.

 Note that if there is a degree of refinement such that we may want
 to make it possible for authors to style compositing-for-characters
 and compositing-for-autocorrect, then that ought to go into the
 styling system.
 
 In older versions of Windows, for example, the browser itself can't
 figure out what kind of style is used by IME.  Korean and Japanese
 IME on Windows, for example, use bolded lines and dotted lines for
 opposite purposes.  And we get bug reports saying that WebKit's
 rendering for Korean IME is incorrect because we decided to follow
 Japanese IME's convention.
 
 Right. In this case we need to distinguish between the browser not knowing 
 and the Web app not knowing.
 
 If the browser doesn't know because the platform can't tell the difference 
 between Korean and Japanese (a problem with which Unicode doesn't help) then 
 there really isn't much that we can do to help the Web app.

This predicates on using approach b.  I'm not convinced that that's the right 
thing to do here.

 However if the browser knows, it can provide the app with information. I 
 don't have enough expertise to know how much information it needs to convey — 
 if it's mostly style that can be done (it might be unwieldy to handle but we 
 can look at it).

The problem here is that we don't know if underlining is the only difference 
input methods ever need.  We could imagine future new UI paradigms would 
require other styling such as bolding text, enlarging the text for easier 
readability while typing, etc... 

 We /could/ consider adding a field to compositing events that would
 capture some form of ontology of input systems. But I think that's
 sort of far-fetched and we can get by with the above. (And yes, I'm
 using ontology on purpose. It wouldn't look good :)
 
 In my opinion, it's a requirement that input methods work and look
 native on editors that use this new API.  IME is not a nice-to-have
 feature.  It's a feature required for billions of people to type any
 text.
 
 That is *exactly* my point. At this point I believe that if we just added 
 something like a compositionType = deadkey | kr | jp | t9 | autocorrect | ... 
 field and leave it at that we're not helping anyone. The script will need to 
 know not just how to render all of these but how they are supposed to look on 
 each platform. That's why I am arguing for primitives that enable the script 
 to do the right thing *without* having to know everything about all the 
 possible IMEs.

Right.  We need a primitive to support all without having to explicitly support 
each.

 Having said that, I was initially hoping that a mixture of composition events 
 plus IME API would cover a lot of ground already. Thinking about it some 
 more, it's not enough.
 
 Can you help me come up with a list of aspects that need to be captured in 
 order to enable the app to render the right UI? Or do you have another 
 proposal?

The biggest difference between European alphabet substation (e.g. e - é) and 
CJK input methods (e.g. jintian - 今天) is that the former typically works on a 
single character at a time (i.e.

Re: contentEditable=minimal


On Jun 6, 2014, at 9:52 AM, Ryosuke Niwa rn...@apple.com wrote:

 On Jun 6, 2014, at 6:40 AM, Robin Berjon ro...@w3.org wrote:
 On 05/06/2014 09:02 , Ryosuke Niwa wrote:
 I agree visual selection of bidirectional text is a problem worth
 solving but I don't think adding a generic multi-range selection
 support to the degree Gecko does is the right solution.
 
 I'd be interested to hear how you propose to solve it in another manner. 
 Also note that that's not the only use case, there are other possibilities 
 for disjoint selections, e.g. a table (naturally) or an editable surface 
 with a non-editable island inside.
 
 Supporting disjoint range is probably necessary but adding the ability to 
 manipulate each range separately seems excessive because that'll lead to 
 selections with overlapping ranges, ranges in completely different locations 
 that are not visually disjoint, etc...

are visually disjoint.

 We might need to do something like exposing readonly multi-range selection.
 
 For starters, most of author scripts completely ignore all but the first
 range, and applying editing operations to a multi-range selection is
 a nightmare.
 
 I don't disagree that it can be hard to handle, but I'm not sure that that's 
 indicative of anything. Most scripts only handle one selection because AFAIK 
 only Gecko ever supported more than one.
 
 Given Gecko itself doesn't handle applying editing operations to multiple 
 ranges well from what I've heard, I'm not certain we can expect web 
 developers to get them right especially in the context where disjoint 
 multi-range selection is needed; e.g. bidirectional text, exotic layout model.
 
 - R. Niwa

Re: Composition, IME, etc. (was: contentEditable=minimal)


On Jun 6, 2014, at 10:13 AM, Ryosuke Niwa rn...@apple.com wrote:

 
 On Jun 6, 2014, at 7:24 AM, Robin Berjon ro...@w3.org wrote:
 
 On 05/06/2014 09:09 , Ryosuke Niwa wrote:
 On May 23, 2014, at 1:37 PM, Robin Berjon ro...@w3.org wrote:
 Semantically, autocorrect and compositing really are the same
 thing.
 
 They are not.  Word substations and input method compositions are
 semantically different operations.
 
 Ok, I'll accept that depending on the level of abstraction at which you're 
 looking at the problem they may or may not be the same thing.
 
 The core of the problem is this: there is a wide array of situations in 
 which some form of indirect text input (deliberately going for a new term 
 with no baggage) takes place. This includes (but is not limited to):
 
 • dead key composition (Alt-N, N - ñ)
 • assumed international composition (',e - é, if you just want an 
 apostrophe you have to compose ',space)
 • inline composition for pretty much everything
 • popup composition
 • autocorrect
 • speed-typing input (T9, swiping inputs)
 
 In order to handle them you have two basic options:
 
 a) Let the browser handle them for you (possibly calling up some platform 
 functionality). This works as closely to user expectations as a Web app can 
 hope to get but how do you render it? If it touches your DOM then you lose 
 the indirection you need for sensible editing; if it doesn't I don't know 
 how you show it.
 
 b) Provide the app with enough information to do the right thing. This gives 
 you the indirection, but doing the right thing can be pretty hard.
 
 I am still leaning towards (b) being the approach to follow, but I'll admit 
 that that's mostly because I can't see how to make (a) actually work. If (b) 
 is the way, then we need to make sure that it's not so hard that everyone 
 gets it wrong as soon as the input is anything other than basic English.
 
 I'm not convinced b is the right approach.
 
 Note that if there is a degree of refinement such that we may want
 to make it possible for authors to style compositing-for-characters
 and compositing-for-autocorrect, then that ought to go into the
 styling system.
 
 In older versions of Windows, for example, the browser itself can't
 figure out what kind of style is used by IME.  Korean and Japanese
 IME on Windows, for example, use bolded lines and dotted lines for
 opposite purposes.  And we get bug reports saying that WebKit's
 rendering for Korean IME is incorrect because we decided to follow
 Japanese IME's convention.
 
 Right. In this case we need to distinguish between the browser not knowing 
 and the Web app not knowing.
 
 If the browser doesn't know because the platform can't tell the difference 
 between Korean and Japanese (a problem with which Unicode doesn't help) then 
 there really isn't much that we can do to help the Web app.
 
 This predicates on using approach b.  I'm not convinced that that's the right 
 thing to do here.
 
 However if the browser knows, it can provide the app with information. I 
 don't have enough expertise to know how much information it needs to convey 
 — if it's mostly style that can be done (it might be unwieldy to handle but 
 we can look at it).
 
 The problem here is that we don't know if underlining is the only difference 
 input methods ever need.  We could imagine future new UI paradigms would 
 require other styling such as bolding text, enlarging the text for easier 
 readability while typing, etc... 
 
 We /could/ consider adding a field to compositing events that would
 capture some form of ontology of input systems. But I think that's
 sort of far-fetched and we can get by with the above. (And yes, I'm
 using ontology on purpose. It wouldn't look good :)
 
 In my opinion, it's a requirement that input methods work and look
 native on editors that use this new API.  IME is not a nice-to-have
 feature.  It's a feature required for billions of people to type any
 text.
 
 That is *exactly* my point. At this point I believe that if we just added 
 something like a compositionType = deadkey | kr | jp | t9 | autocorrect | 
 ... field and leave it at that we're not helping anyone. The script will 
 need to know not just how to render all of these but how they are supposed 
 to look on each platform. That's why I am arguing for primitives that enable 
 the script to do the right thing *without* having to know everything about 
 all the possible IMEs.
 
 Right.  We need a primitive to support all without having to explicitly 
 support each.
 
 Having said that, I was initially hoping that a mixture of composition 
 events plus IME API would cover a lot of ground already. Thinking about it 
 some more, it's not enough.
 
 Can you help me come up with a list of aspects that need to be captured in 
 order to enable the app to render the right UI? Or do you have another 
 proposal?
 
 The biggest difference between European alphabet substation (e.g. e - é) and 
 CJK input methods (e.g. jintian -

Re: Composition, IME, etc. (was: contentEditable=minimal)


On Jun 6, 2014, at 10:13 AM, Ryosuke Niwa rn...@apple.com wrote:

 
 On Jun 6, 2014, at 7:24 AM, Robin Berjon ro...@w3.org wrote:
 
 On 05/06/2014 09:09 , Ryosuke Niwa wrote:
 On May 23, 2014, at 1:37 PM, Robin Berjon ro...@w3.org wrote:
 Semantically, autocorrect and compositing really are the same
 thing.
 
 They are not.  Word substations and input method compositions are
 semantically different operations.
 
 Ok, I'll accept that depending on the level of abstraction at which you're 
 looking at the problem they may or may not be the same thing.
 
 The core of the problem is this: there is a wide array of situations in 
 which some form of indirect text input (deliberately going for a new term 
 with no baggage) takes place. This includes (but is not limited to):
 
 • dead key composition (Alt-N, N - ñ)
 • assumed international composition (',e - é, if you just want an 
 apostrophe you have to compose ',space)
 • inline composition for pretty much everything
 • popup composition
 • autocorrect
 • speed-typing input (T9, swiping inputs)
 
 In order to handle them you have two basic options:
 
 a) Let the browser handle them for you (possibly calling up some platform 
 functionality). This works as closely to user expectations as a Web app can 
 hope to get but how do you render it? If it touches your DOM then you lose 
 the indirection you need for sensible editing; if it doesn't I don't know 
 how you show it.
 
 b) Provide the app with enough information to do the right thing. This gives 
 you the indirection, but doing the right thing can be pretty hard.
 
 I am still leaning towards (b) being the approach to follow, but I'll admit 
 that that's mostly because I can't see how to make (a) actually work. If (b) 
 is the way, then we need to make sure that it's not so hard that everyone 
 gets it wrong as soon as the input is anything other than basic English.
 
 I'm not convinced b is the right approach.
 
 Note that if there is a degree of refinement such that we may want
 to make it possible for authors to style compositing-for-characters
 and compositing-for-autocorrect, then that ought to go into the
 styling system.
 
 In older versions of Windows, for example, the browser itself can't
 figure out what kind of style is used by IME.  Korean and Japanese
 IME on Windows, for example, use bolded lines and dotted lines for
 opposite purposes.  And we get bug reports saying that WebKit's
 rendering for Korean IME is incorrect because we decided to follow
 Japanese IME's convention.
 
 Right. In this case we need to distinguish between the browser not knowing 
 and the Web app not knowing.
 
 If the browser doesn't know because the platform can't tell the difference 
 between Korean and Japanese (a problem with which Unicode doesn't help) then 
 there really isn't much that we can do to help the Web app.
 
 This predicates on using approach b.  I'm not convinced that that's the right 
 thing to do here.
 
 However if the browser knows, it can provide the app with information. I 
 don't have enough expertise to know how much information it needs to convey 
 — if it's mostly style that can be done (it might be unwieldy to handle but 
 we can look at it).
 
 The problem here is that we don't know if underlining is the only difference 
 input methods ever need.  We could imagine future new UI paradigms would 
 require other styling such as bolding text, enlarging the text for easier 
 readability while typing, etc... 
 
 We /could/ consider adding a field to compositing events that would
 capture some form of ontology of input systems. But I think that's
 sort of far-fetched and we can get by with the above. (And yes, I'm
 using ontology on purpose. It wouldn't look good :)
 
 In my opinion, it's a requirement that input methods work and look
 native on editors that use this new API.  IME is not a nice-to-have
 feature.  It's a feature required for billions of people to type any
 text.
 
 That is *exactly* my point. At this point I believe that if we just added 
 something like a compositionType = deadkey | kr | jp | t9 | autocorrect | 
 ... field and leave it at that we're not helping anyone. The script will 
 need to know not just how to render all of these but how they are supposed 
 to look on each platform. That's why I am arguing for primitives that enable 
 the script to do the right thing *without* having to know everything about 
 all the possible IMEs.
 
 Right.  We need a primitive to support all without having to explicitly 
 support each.
 
 Having said that, I was initially hoping that a mixture of composition 
 events plus IME API would cover a lot of ground already. Thinking about it 
 some more, it's not enough.
 
 Can you help me come up with a list of aspects that need to be captured in 
 order to enable the app to render the right UI? Or do you have another 
 proposal?
 
 The biggest difference between European alphabet substation (e.g. e - é) and 
 CJK input methods (e.g. jintian -

Re: contentEditable=minimal

On May 22, 2014, at 1:52 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Thu, May 1, 2014 at 5:31 PM, Ben Peters ben.pet...@microsoft.com wrote:
 Proposal
 To make this simpler for sites, frameworks, and browsers, it makes sense to 
 enable a new, simpler version of contentEditable that provides basic 
 functionality only. For the sake of discussion, call it 
 contentEditable='minimal'. The functionality provided by the browser under 
 contentEditable='minimal' would be as follows:
 * Caret drawing
 * Events such as Keyboard , Clipboard, Drag and Drop
 * Some keyboard input handling- caret movement, typing of characters 
 including Input Method Editor input
 * Selection drawing and manipulation according to the new Selection API spec
 
 This sounds like a super promising approach.

I agree.

 If I understand the proposal correctly, when the user does something
 that causes input, like pressing the enter key, we would fire a key
 event, but we wouldn't actually modify the DOM. Modifying the DOM
 would be the responsibility of the web page.
 
 Likewise, if the user pressed whatever key is platform convention for
 paste, we would fire an event which contains the clipboard data, but
 not mutate the DOM. Copying data from the event (i.e. from the
 clipboard) to the page would be the responsibility of the page.
 
 Is that correct? If so I like it a lot!

I think it'll be nice to allow authors to enable default UA actions; e.g. auto 
paste into DOM.

 I'd like to expand, and clarify, the list of services that you propose
 that the UA provides:
 
 * Caret and selection drawing.
 * Drawing IME UI in response to user typing.
 * Events for clipboard and drag'n'drop (though the UA would not mutate
 the DOM in response to those events).
 * Cursor navigation, including reacting to touch events, mouse clicks
 and keyboard events. Cursor navigation would likely also fire
 cancelable events.
 * Turning keyboard events into events representing text input (but not
 mutate the DOM in response to those events).
 * The Selection API spec for selection manipulation.
 
 I.e. pressing a key on the keyboard would always fire a keyboard
 event, and then, as default action, possibly a cursor navigation event
 or a text input event, depending on what type of key was pressed.
 
 I'm unsure about what the proper way to handle text insertion is. I.e.
 how to handle the second to last bullet.
 
 Can we simply use the same events as we fire in input type=text and
 textarea, but don't actually mutate any DOM? Or is it awkward to
 fire beforeinput when there is no default action of mutating the DOM
 and firing input?
 
 And is it too much complexity to ask pages to deal with composition
 handling themselves?

I think requiring pages to handle composition events will be bad because many 
people don't even know how input methods work, or for that latter, what input 
method is.

 Another approach would be to allow plain text input events to actually
 mutate the DOM as a default action. But allow that action to be
 cancelled. Note that we would never do anything more complex than
 mutate an existing text node, or insert a text node where the cursor
 is located. I.e. no elements would ever get added, removed, split,
 have attributes changed or otherwise be mutated.

I think it would be nice for authors to explicitly enable such default 
behaviors.

- R. Niwa

Re: contentEditable=minimal


On May 27, 2014, at 1:33 AM, Robin Berjon ro...@w3.org wrote:

 On 27/05/2014 01:47 , Ben Peters wrote:
 -Original Message- From: Robin Berjon
 On 26/05/2014 05:43 , Norbert Lindenberg wrote:
 Were any speakers of bidirectional languages in the room when
 this was discussed?
 
 I don't know what languages the others speak. That said, my
 recollection was that this was presented along the lines of we've
 had regular requests to support selecting text in geometric rather
 than logical orders.
 
 I have also heard these requests from the bi-directional experts here
 at Microsoft. A single, unbroken selection is what we're told users
 want, and multi-selection makes this possible.
 
 Thinking about this a little bit more: I don't imagine that the Selection API 
 should prescribe the UI that browsers choose to support in order to select 
 bidi text, on the contrary they should be allowed to innovate, experiment, 
 follow various platform conventions, etc. But if we don't support multi-range 
 selection, then only one model is possible which precludes unbroken 
 selections.
 
 I think that this strongly pushes in the direction of supporting multiple 
 ranges.

I agree visual selection of bidirectional text is a problem worth solving but I 
don't think adding a generic multi-range selection support to the degree Gecko 
does is the right solution.  For starters, most of author scripts completely 
ignore all but the first range, and applying editing operations to a 
multi-range selection is a nightmare.

- R. Niwa

Re: contentEditable=minimal

On May 23, 2014, at 1:37 PM, Robin Berjon ro...@w3.org wrote:

 On 23/05/2014 21:32 , Jonas Sicking wrote:
 On Fri, May 23, 2014 at 4:43 AM, Robin Berjon ro...@w3.org wrote:
 On 23/05/2014 12:28 , Jonas Sicking wrote:
 And on mobile autocorrect of misspelled words is common, though that
 can probably be handled by moving the selection to the misspelled word
 and then writing the fixed word.
 
 Autocorrect should be handled like composition. Composition is pretty much
 what happens whenever you type some stuff and some other stuff comes out.
 (Technical definition.)
 
 I sadly don't think it's that simple. When compositing chinese
 characters, or characters like ü, an underline should be rendered
 during the composition and then removed once a character (or set of
 characters) is selected. This underline should not appear when typing
 on a mobile keyword, even if it supports autocorrect.
 
 It's not clear to me if the difference is just one of styling, or if
 there are semantic differences as well.
 
 Semantically, autocorrect and compositing really are the same thing.

They are not.  Word substations and input method compositions are semantically 
different operations.

 How that gets rendered may be another story, but I'll point out that there 
 are mobile UIs in which the word being typed is underlined.

Just because they're treated the same way in one platform doesn't allow us to 
treat them same in all platforms.  It's crucial for editors on the Web to be 
able to use the same UI for on the platforms that do differentiate the two.

 Note that if there is a degree of refinement such that we may want to make it 
 possible for authors to style compositing-for-characters and 
 compositing-for-autocorrect, then that ought to go into the styling system.

In older versions of Windows, for example, the browser itself can't figure out 
what kind of style is used by IME.  Korean and Japanese IME on Windows, for 
example, use bolded lines and dotted lines for opposite purposes.  And we get 
bug reports saying that WebKit's rendering for Korean IME is incorrect because 
we decided to follow Japanese IME's convention.

 We /could/ consider adding a field to compositing events that would capture 
 some form of ontology of input systems. But I think that's sort of 
 far-fetched and we can get by with the above. (And yes, I'm using ontology 
 on purpose. It wouldn't look good :)

In my opinion, it's a requirement that input methods work and look native on 
editors that use this new API.  IME is not a nice-to-have feature.  It's a 
feature required for billions of people to type any text.

 My assertion is that we don't want to use compositing events when
 typing on a keyboard which has autocorrect. (This might be a wrong
 assertion in which case none of this matters). Rather than composition
 events we fire events like:
 
 insert 'c'
 insert 'a'
 insert 'g'
 selection moved to start at index 0 and end at index 3
 insert 'cat'
 insert ' '
 
 However we've previously said that pages should be able to cancel or
 adjust selection moves. The question is what happens if the page
 changes the selection when autocorrect attempts to select the word to
 be fixed.
 
 Gotcha, and indeed you are correct. If autocorrect were implemented as a 
 change of the selection followed by an insert of the correction, the 
 application could unwillingly interfere with the selection and cause mayhem. 
 But even if that weren't the case this would feel pretty hacky. Maybe you are 
 thinking of this because on recent Androids when you autocorrect there's an 
 animation that more or less makes it look like that's what's going on?
 
 Honestly, I really think that compositing events are the right abstraction 
 here. We can get finicky on style tweaks, but they work for all compositing 
 systems I can think of admittedly not *that* many but still quite a few). 
 They would even work for T9!

I strongly disagree.

- R. Niwa

Re: contentEditable and forms (was: contentEditable=minimal)


On May 27, 2014, at 2:56 AM, Robin Berjon ro...@w3.org wrote:

 On 27/05/2014 09:19 , Piotr Koszuliński wrote:
 Yes, it should be possible to disable whichever feature you don't need.
 In some cases you don't need lists (because e.g. you're editing a text
 that will become a content of a paragraph). And in some cases you don't
 want bold/italic because your use case requires only structured HTML. So
 being able to handle such commands is a one thing. But first of all
 there should be no assumption that a user needs these buttons, because a
 browser just don't know about that. If I think that users need toolbar,
 I can render a custom one.
 
 Much agreed. The browser should not show any markup/styling affordance for 
 cE=minimal.
 
 There's one more assumption that makes editing on mobile devices
 (especially low-res devices) very hard. It's that if user focuses
 editable, then he/she wants to type, so native keyboard should pop out.
 Very often it's true, but in some cases user may want to select some
 text and using toolbar apply styles or lists, etc. And when the keyboard
 is visible there's very little space to do that. If there was any API to
 control whether keyboard is visible, then we could achieve much better UX.
 
 There are quite a few things from forms that I think could usefully become 
 available in an editing context. We could benefit from having the inputmode 
 attribute be allowed on any editable piece of text. For the specific use case 
 you cite, an additional keyword of none might make sense too.
 
 It possibly wouldn't hurt to have the placeholder attribute be available on 
 all editable content, too. I'm less sure about the validation attributes 
 (except perhaps required) but why not.
 
 Obviously validation attributes only make sense if the editable content can 
 contribute to forms. But it would make a lot of sense that it could. Today 
 you have to resort to ugly hacks in which you somehow copy over the edited 
 content into a textarea. That's pretty daft: in most use cases you're going 
 to be submitting the content.

There was a discussion about participating in the form submission in general 
back in Feb:
http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0448.html

 There are several ways in which we could handle this. One is to have any 
 element with cE=minimal contribute to the form data set (when inside a form, 
 or possibly when using the form attribute if someone remembers what the use 
 case for that thing was). That's interesting, but I get a sense that it 
 conflates two features. Another approach is to add a submittable attribute 
 that can make the innerHTML of any element contribute to the form data set.
 
 Thoughts?

I think we should come up with a generic form participation mechanism that 
could be used for cE=minimal.

- R. Niwa

RE: contentEditable=minimal

2014-06-04 Thread Travis Leithead

DOM L3 does require implementations to fire composition event for dead-key 
combinations, so insofar as the (Alt-`) combo results in a dead key for 
accent-grave (and other dead key combos mentioned below), the composition 
events should (or are supposed to) fire as a result.

-Original Message-
From: Ben Peters [mailto:ben.pet...@microsoft.com] 
Sent: Monday, June 2, 2014 2:00 PM
To: Robin Berjon; Julie Parent
Cc: Johannes Wilm; public-webapps@w3.org
Subject: RE: contentEditable=minimal

Great context. Thanks! Let me ask my question another way- should 
CompositionEvents be used when there isn't a composition? Should typing 'a' 
fire CompositionEnd? If not we still need a CommandEvent of type insertText, 
and it seems inconsistent not to fire it for all typing, doesn't it?

 From: Robin Berjon [mailto:ro...@w3.org]

 On 27/05/2014 01:52 , Ben Peters wrote:
  From: Robin Berjon [mailto:ro...@w3.org] On 23/05/2014 01:23 , Ben 
  Peters wrote:
  As I said I am unsure that the way in which composition events 
  are described in DOM 3 Events is perfect, but that's only because 
  I haven't used them in anger and they aren't supported much.

  My thought is that we can use CommandEvent with type=insertText.
  This would be the corollary to execComamnd(insertText), and the 
  data would be the ñ that is about to be inserted.

  But if you only get one event you can't render the composition as 
  it is carrying out.

  I believe Composition Events are very important for IME input, but 
  we should fire CommandEvent with Insert text for all text input, 
  including IME. Are you saying we should use Composition Events even 
  for non-IME input?

 I am not using an IME, and yet I could not type in French on my 
 keyboard without composition.

 Obviously, if I switch to Kotoeri input, I'll get composition *and* an 
 IME popup. But for regular French input (in a US keyboard) I need:

é - Alt-E, E
è - Alt-`, E
à - Alt-`, A
ô - Alt-I, O
ü - Alt-U, U
ñ - Alt-˜, N (for the occasional Spanish)
(and a bunch more)

 Some older apps (you pretty much can't find them anymore) used to not 
 display the composition as it was ongoing and only show the text after 
 composition had terminated. That was survivable but annoying, and it 
 only worked because composition in Latin-script languages is pretty 
 trivial (except perhaps for all you Livonian speakers out there!), but 
 I don't think it would be viable for more complex compositions. And 
 even in simple cases it would confuse users to be typing characters with no 
 rendering feedback.

 Without composition events you can't render the ongoing composition. 
 See what's going on at:

 https://gist.github.com/darobin/8a128f05106d0e02717b#file-twitter-html
 -
 L81

 That is basically inserting text in a range that's decorated to be 
 underlined to show composition in progress. Composition updates
 *replace* the text in the range. And at the end the range is removed 
 and text is inserted.

 The above is for Mac, but I have distant memories of using something 
 similar on Windows called the US International Keyboard where you 
 could have apostrophes compose as accents, etc.. I don't recall how it 
 was rendered though.

 --
 Robin Berjon - http://berjon.com/ - @robinberjon

RE: contentEditable=minimal

2014-06-02 Thread Ben Peters

 From: Robin Berjon [mailto:ro...@w3.org]
 
 I think we agree at the high level but might disagree over smaller details. 
 You
 seem to want something that would roughly resemble the
 following:
 
 BeforeSelectionChange
 {
direction:  forward
 , step:   word
 }
 
 whereas I would see something capturing information more along those lines:
 
 BeforeSelectionChange
 {
oldRange:  [startNode, startOffset, endNode, endOffset] , newRange:
 [startNode, startOffset, endNode, endOffset] }
 
 I think that the latter is better because it gives the library the computed
 range that matches the operation, which as far as I can imagine is what you
 actually want to check (e.g. check that the newRange does not contain
 something unselectable, isn't outside a given boundary, etc.).
 
 The former requires getting a lot of details right in the spec, and those 
 would
 become hard to handle at the script level. On some platforms a triple click 
 (or
 some key binding) can select the whole line. This not only means that you
 need direction: both but also that the script needs a notion of line that it
 has no access to (unless the Selection API grants it). What makes up a word
 as a step also varies a lot (e.g.
 I tend to get confused by what Office apps think a word is as it doesn't match
 the platform's idea) and there can be interesting interactions with language
 (e.g. is passive-aggressive one word or two? What about co-operation?).
 
 But maybe you have a use case for providing the information in that way that
 I am not thinking of?

This seems like it's getting pretty close to the browser just doing the 
selection. A browser would still have to figure out what the selection should 
look like in the version you suggest. Instead, maybe each site could decide 
what is thinks is a word (passive or passive-agressive). The line example 
is good, so maybe we should have a 'line' level selection just like the 'word' 
level?

  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.
 
  I agree, except that I don't know why we want paste to fire two
  'intention' events (paste and input). Seems like we should make it
  clear that the intention is insert text (type, voice, whatever),
  remove text (delete, including what text to remove), or paste (so you
  can clean it up).
 
 I don't think we want to fire both paste and input, but if my reading is 
 correct
 that is the case today (or expected to be — this isn't exactly an area of high
 interop).

Yes my understanding is that today you get both. I'm not arguing against that 
as the events stand today, but when we talk about 'Intention Events' as an 
abstract type with certain properties like commandName, I think you should only 
get one of those (paste or command or beforeinput), and I'm suggesting that it 
should be paste in this case.

Ben

RE: contentEditable=minimal

2014-06-02 Thread Ben Peters

Great context. Thanks! Let me ask my question another way- should 
CompositionEvents be used when there isn't a composition? Should typing 'a' 
fire CompositionEnd? If not we still need a CommandEvent of type insertText, 
and it seems inconsistent not to fire it for all typing, doesn't it?

 From: Robin Berjon [mailto:ro...@w3.org]

 On 27/05/2014 01:52 , Ben Peters wrote:
  From: Robin Berjon [mailto:ro...@w3.org] On 23/05/2014 01:23 , Ben
  Peters wrote:
  As I said I am unsure that the way in which composition events are
  described in DOM 3 Events is perfect, but that's only because I
  haven't used them in anger and they aren't supported much.

  My thought is that we can use CommandEvent with type=insertText.
  This would be the corollary to execComamnd(insertText), and the
  data would be the ñ that is about to be inserted.

  But if you only get one event you can't render the composition as it
  is carrying out.

  I believe Composition Events are very important for IME input, but we
  should fire CommandEvent with Insert text for all text input,
  including IME. Are you saying we should use Composition Events even
  for non-IME input?

 I am not using an IME, and yet I could not type in French on my keyboard
 without composition.

 Obviously, if I switch to Kotoeri input, I'll get composition *and* an IME
 popup. But for regular French input (in a US keyboard) I need:

é - Alt-E, E
è - Alt-`, E
à - Alt-`, A
ô - Alt-I, O
ü - Alt-U, U
ñ - Alt-˜, N (for the occasional Spanish)
(and a bunch more)

 Some older apps (you pretty much can't find them anymore) used to not
 display the composition as it was ongoing and only show the text after
 composition had terminated. That was survivable but annoying, and it only
 worked because composition in Latin-script languages is pretty trivial (except
 perhaps for all you Livonian speakers out there!), but I don't think it would 
 be
 viable for more complex compositions. And even in simple cases it would
 confuse users to be typing characters with no rendering feedback.

 Without composition events you can't render the ongoing composition. See
 what's going on at:

 https://gist.github.com/darobin/8a128f05106d0e02717b#file-twitter-html-
 L81

 That is basically inserting text in a range that's decorated to be underlined 
 to
 show composition in progress. Composition updates
 *replace* the text in the range. And at the end the range is removed and
 text is inserted.

 The above is for Mac, but I have distant memories of using something similar
 on Windows called the US International Keyboard where you could have
 apostrophes compose as accents, etc.. I don't recall how it was rendered
 though.

 --
 Robin Berjon - http://berjon.com/ - @robinberjon

Re: [editing] CommandEvent and contentEditable=minimal Explainer

2014-05-31 Thread Ryosuke Niwa

I agree it's better to let authors define what behavior they want from UA 
instead of defining the set of behaviors ourselves.

Furthermore, I'd argue that we should separately have a mode where scripts 
would get intention events but UA wouldn't enact any builtin editing commands 
as default actions.  This is  useful for non-text editing applications such as 
drawing and presentation apps.

- R. Niwa

 On May 28, 2014, at 1:39 PM, Ben Peters ben.pet...@microsoft.com wrote:
 
 Great idea! If Intention Events (Clipboard, Selection, Command) cover all of 
 the editing operations that a site would want to handle themselves, we don’t 
 need CE Min as a feature, only a concept that can achieved with 
 preventDefault().
  
 From: Julie Parent [mailto:jpar...@gmail.com] 
 Sent: Tuesday, May 27, 2014 4:40 PM
 To: Ben Peters
 Cc: public-webapps@w3.org
 Subject: Re: [editing] CommandEvent and contentEditable=minimal Explainer
  
 The discussion of which minimal default handling to include with 
 contenteditable=minimal makes me wonder if contentEditable=minimal is 
 necessary at all.  It quickly becomes a can of worms of *which* default 
 handling should be included, and it seems likely to not satisfy every use 
 case no matter which decisions are made.  However, minimal is proposed as a 
 building block because currently, disabling all default functionality of 
 contentEditable=true is difficult/impossible.  But with CommandEvents, 
 shouldn't contentEditable=minimal be equivalent to:
  
 // Let editRegion be div contentEditable id='editRegion'
  
 var editRegion = document.getElementById(editRegion);
 editRegion.addEventListener(command, handleCommand);
 function handleCommand(evt){
   evt.preventDefault();
 }
  
 No default actions would be taken, but selection events would still fire and 
 be handled.  There would be no ambiguity.  If implementing 
 contentEditable=minimal on top of CommandEvents could just be a few lines 
 of code, why complicate things by spec'ing another property?
  
 Then, if someone wants a region that just does basic text input, then they 
 simply allow it:
 function handleCommand(evt){
  switch (evt.commandType){
case 'insertText':
  // Let the browser do text insertion
  break;
default:
  // Prevent all other magic
  evt.preventDefault();
 }
  
 This hedges on the fact that CommandEvents would capture ALL the cases that 
 contentEditable currently handles, and that the event would fire BEFORE the 
 dom is modified, and that calling preventDefault would cancel the event, but 
 isn't that a goal of this design anyway?
  
 Julie
  
 -- Forwarded message --
 From: Ben Peters ben.pet...@microsoft.com
 Date: Thu, May 22, 2014 at 4:56 PM
 Subject: [editing] CommandEvent and contentEditable=minimal Explainer
 To: public-webapps@w3.org public-webapps@w3.org
 
 
 I have completed a first-draft explainer document [1], taking the generous 
 feedback of many of you into account. There are 6 open issues on the document 
 currently, and I'm sure there are others that I have missed. It would be 
 great to know if this is heading in in the right direction.
 
 My vision is to use this a non-normative Explainer, and create 2 normative 
 specs to go with it. The specs for contentEditable=minimal and CommandEvent 
 should have first-drafts next week.
 
 Thanks!
 Ben
 
 [1] http://benjamp.github.io/commands-explainer.htm

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

2014-05-30 Thread Anne van Kesteren

On Fri, May 30, 2014 at 12:50 AM, Julie Parent jpar...@gmail.com 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)

2014-05-29 Thread Julie Parent

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 ann...@annevk.nl wrote:

 On Mon, May 26, 2014 at 4:17 AM, Yoshifumi Inoue yo...@chromium.org
 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: contentEditable=minimal

2014-05-28 Thread Piotr Koszuliński

On Tue, May 27, 2014 at 11:01 AM, Robin Berjon ro...@w3.org wrote:

 On 25/05/2014 20:40 , Piotr Koszuliński wrote:

 Making some things unselectable might also be useful. IE has
 unselectable, there's also -moz-user-select and friends. But this is
 small fries for later I'd reckon.

 There are also nested non-editable islands. We built very important
 feature based on them - http://ckeditor.com/demo#widgets. Currently we
 block their selection by preventing mousedown and we handle left/right
 arrows. But cancelling selectionchange would allow us to control more
 cases in a cleaner way.


 I'd be curious to know what your take is on the best way to expose this.
 IE has an unselectable attribute, whereas Gecko and WebKit have a CSS
 property. In this thread we've been talking about using cancellable events
 for this (or if not cancellable, ones in which the selection can be
 modified on the fly).

 On instinct I would tend to think that this not a great usage of CSS, it's
 much more tied to behaviour at a lower level. But it sort of is one of
 those borderline things (as many of the properties that initially came from
 the CSS UI module).

 The scriptable option that we're consider is good in that it enables
 arbitrary cases, but it could be interesting to support a number of cases
 out of the box with a simpler (for developers) approach.

 Let's imagine the following DOM:

 div contenteditable=minimal
   pblah blah blah/p
   div class=widget unselectable.../div
   pblah blah blah/p
 /div

 If the cursor is at the beginning of the first p, you hold Shift, and
 click at the end of the second p, we could imagine that you'd get a
 Selection with two Ranges (one for each p) and not containing the
 unselectable widget. I *think* that's the most desirable default behaviour,
 and it's also one that can be pretty painful to control through script. In
 that sense an unselectable attribute would make sense. (I reckon that
 setting the widget to be cE=false would have the same effect, but it is
 nevertheless an orthogonal property.)

 WDYT?


My previous email might be confusing because I mentioned only that CKEditor
handles mousedown event. Actually, this is a tip of an iceberg :). I think
that it may be an interesting case, because we were forced to overwrite
most of browser behaviours when implementing the widget system. Also, this
case is so complex that it's easier to start from what we experienced
rather than saying that if X and Y will be possible, then our needs will be
satisfied. I hope you forgive me this laziness :)

The main requirements for the widget system were:

1. User must not be able to modify a non-editable part of widget.
2. Widget must be selectable as a whole (like an image).
 3. Widget may contain editable fragments (nested editables).
4. There are block and inline widgets (surprisingly important requirement).
5. Widget may contain other widgets in its nested editables. So widgets may
be nested multiple times.
6. Widget must be selectable by click, arrow keys, etc. It also has to be
deletable by backspace/delete and copyable by CTRL+C.

This is a structure that we used:

div contenteditable=true !-- editor's main editable --
   pfoo/p
  div contenteditable=false !-- widget wrapper --
p contenteditable=truenested editable/p
pnon-editable content/p
div contenteditable=true
   panother nested editable/p
/div
  /div
  pfoo2 span contenteditable=falseinline widget/span/p
/div

Why did we choose contenteditable=false? At the beginning it was simply
intuitive. We don't fully control the interaction methods (mouse, keyboard,
selection), so let browser do that. Then we overwrote most of the
interaction methods so currently the attribute is not so crucial. However,
there's one aspect of interaction which we cannot control and I'm not sure
if we'll ever be able - dynamically changing selection (its visual and
logical aspect) around block widgets, their nested editables and a special
case that complicates all this - blocks may be floated. Let's try to
imagine how we could handle selection without using contenteditable=false.

pfoo/p
div class=widgetwidget/div
pbar/p

TC1:
User clicks main editable's margin, on the side of the block widget. If he
clicks closer to the top of the widget, we would like to place caret at the
end of preceding editable block (foo^), and when closer to bottom, then in
the following block (^bar). Without checking dimensions, that would not be
doable, because browser would suggest a selection inside divwidget/div.
On the other hand, we could consider always selecting entire widget if
selection was proposed inside it. This seems to be a good option,
especially taking into account that we may have multiple block widgets one
after another, and then you cannot place selection between them anyway.

TC2:
Another aspect is selection normalisation. When we make a decision that
entire block widget should be selected we want to be able to anchor the
selection

RE: [editing] CommandEvent and contentEditable=minimal Explainer

2014-05-28 Thread Ben Peters

Great idea! If Intention Events (Clipboard, Selection, Command) cover all of 
the editing operations that a site would want to handle themselves, we don’t 
need CE Min as a feature, only a concept that can achieved with 
preventDefault().

From: Julie Parent [mailto:jpar...@gmail.com]
Sent: Tuesday, May 27, 2014 4:40 PM
To: Ben Peters
Cc: public-webapps@w3.org
Subject: Re: [editing] CommandEvent and contentEditable=minimal Explainer

The discussion of which minimal default handling to include with 
contenteditable=minimal makes me wonder if contentEditable=minimal is 
necessary at all.  It quickly becomes a can of worms of *which* default 
handling should be included, and it seems likely to not satisfy every use case 
no matter which decisions are made.  However, minimal is proposed as a 
building block because currently, disabling all default functionality of 
contentEditable=true is difficult/impossible.  But with CommandEvents, 
shouldn't contentEditable=minimal be equivalent to:

// Let editRegion be div contentEditable id='editRegion'

var editRegion = document.getElementById(editRegion);
editRegion.addEventListener(command, handleCommand);
function handleCommand(evt){
  evt.preventDefault();
}

No default actions would be taken, but selection events would still fire and be 
handled.  There would be no ambiguity.  If implementing 
contentEditable=minimal on top of CommandEvents could just be a few lines of 
code, why complicate things by spec'ing another property?

Then, if someone wants a region that just does basic text input, then they 
simply allow it:
function handleCommand(evt){
 switch (evt.commandType){
   case 'insertText':
 // Let the browser do text insertion
 break;
   default:
 // Prevent all other magic
 evt.preventDefault();
}

This hedges on the fact that CommandEvents would capture ALL the cases that 
contentEditable currently handles, and that the event would fire BEFORE the dom 
is modified, and that calling preventDefault would cancel the event, but isn't 
that a goal of this design anyway?

Julie

-- Forwarded message --
From: Ben Peters ben.pet...@microsoft.commailto:ben.pet...@microsoft.com
Date: Thu, May 22, 2014 at 4:56 PM
Subject: [editing] CommandEvent and contentEditable=minimal Explainer
To: public-webapps@w3.orgmailto:public-webapps@w3.org 
public-webapps@w3.orgmailto:public-webapps@w3.org

I have completed a first-draft explainer document [1], taking the generous 
feedback of many of you into account. There are 6 open issues on the document 
currently, and I'm sure there are others that I have missed. It would be great 
to know if this is heading in in the right direction.

My vision is to use this a non-normative Explainer, and create 2 normative 
specs to go with it. The specs for contentEditable=minimal and CommandEvent 
should have first-drafts next week.

Thanks!
Ben

[1] http://benjamp.github.io/commands-explainer.htm

RE: [editing] CommandEvent and contentEditable=minimal Explainer

2014-05-28 Thread Travis Leithead

Be careful with having events fire before the DOM is updated—at a minimum 
you’ll want to consider whether you will allow dangerous situations like the 
legacy MutationEvents could cause (start a change - pre-change notification - 
make another change - pre-change notification … unexpected things can happen 
(can be especially challenging to implement securely).

HTML5’s focus event model nicely prevents these recursions from looping. I’ve 
proposed a similar mitigation for the “beforeinput” event of DOM Level 3 
Events: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25683

Seems like the Intention Events, if firing before the change is committed, 
might want a similar mitigation strategy.

From: Ben Peters [mailto:ben.pet...@microsoft.com]
Sent: Wednesday, May 28, 2014 1:40 PM
To: Julie Parent
Cc: public-webapps@w3.org
Subject: RE: [editing] CommandEvent and contentEditable=minimal Explainer

Great idea! If Intention Events (Clipboard, Selection, Command) cover all of 
the editing operations that a site would want to handle themselves, we don’t 
need CE Min as a feature, only a concept that can achieved with 
preventDefault().

From: Julie Parent [mailto:jpar...@gmail.com]
Sent: Tuesday, May 27, 2014 4:40 PM
To: Ben Peters
Cc: public-webapps@w3.orgmailto:public-webapps@w3.org
Subject: Re: [editing] CommandEvent and contentEditable=minimal Explainer

The discussion of which minimal default handling to include with 
contenteditable=minimal makes me wonder if contentEditable=minimal is 
necessary at all.  It quickly becomes a can of worms of *which* default 
handling should be included, and it seems likely to not satisfy every use case 
no matter which decisions are made.  However, minimal is proposed as a 
building block because currently, disabling all default functionality of 
contentEditable=true is difficult/impossible.  But with CommandEvents, 
shouldn't contentEditable=minimal be equivalent to:

// Let editRegion be div contentEditable id='editRegion'

var editRegion = document.getElementById(editRegion);
editRegion.addEventListener(command, handleCommand);
function handleCommand(evt){
  evt.preventDefault();
}

No default actions would be taken, but selection events would still fire and be 
handled.  There would be no ambiguity.  If implementing 
contentEditable=minimal on top of CommandEvents could just be a few lines of 
code, why complicate things by spec'ing another property?

Then, if someone wants a region that just does basic text input, then they 
simply allow it:
function handleCommand(evt){
 switch (evt.commandType){
   case 'insertText':
 // Let the browser do text insertion
 break;
   default:
 // Prevent all other magic
 evt.preventDefault();
}

This hedges on the fact that CommandEvents would capture ALL the cases that 
contentEditable currently handles, and that the event would fire BEFORE the dom 
is modified, and that calling preventDefault would cancel the event, but isn't 
that a goal of this design anyway?

Julie

-- Forwarded message --
From: Ben Peters ben.pet...@microsoft.commailto:ben.pet...@microsoft.com
Date: Thu, May 22, 2014 at 4:56 PM
Subject: [editing] CommandEvent and contentEditable=minimal Explainer
To: public-webapps@w3.orgmailto:public-webapps@w3.org 
public-webapps@w3.orgmailto:public-webapps@w3.org


I have completed a first-draft explainer document [1], taking the generous 
feedback of many of you into account. There are 6 open issues on the document 
currently, and I'm sure there are others that I have missed. It would be great 
to know if this is heading in in the right direction.

My vision is to use this a non-normative Explainer, and create 2 normative 
specs to go with it. The specs for contentEditable=minimal and CommandEvent 
should have first-drafts next week.

Thanks!
Ben

[1] http://benjamp.github.io/commands-explainer.htm

Re: [editing] CommandEvent and contentEditable=minimal Explainer

2014-05-28 Thread Piotr Koszuliński

But what is the default behaviour then? What will we be preventing?
There's no accepted specification for current contentEditable=true AFAIK,
so I thought that the goal of contentEditable=minimal is to avoid the need
to write a specification for contentEditable=true. Otherwise, developers
may demand from browser vendors that they fix their contentEditable=true
implementations and I don't think that anyone wants that. Why not forget
about contentEditable=true, make it deprecated and create specification
only for algorithms needed by contentEditable=minimal and all required
command events?


On Wed, May 28, 2014 at 10:39 PM, Ben Peters ben.pet...@microsoft.comwrote:

  Great idea! If Intention Events (Clipboard, Selection, Command) cover
 all of the editing operations that a site would want to handle themselves,
 we don’t need CE Min as a feature, only a concept that can achieved with
 preventDefault().



 *From:* Julie Parent [mailto:jpar...@gmail.com]
 *Sent:* Tuesday, May 27, 2014 4:40 PM
 *To:* Ben Peters
 *Cc:* public-webapps@w3.org
 *Subject:* Re: [editing] CommandEvent and contentEditable=minimal
 Explainer



 The discussion of which minimal default handling to include with
 contenteditable=minimal makes me wonder if contentEditable=minimal is
 necessary at all.  It quickly becomes a can of worms of *which* default
 handling should be included, and it seems likely to not satisfy every use
 case no matter which decisions are made.  However, minimal is proposed as
 a building block because currently, disabling all default functionality of
 contentEditable=true is difficult/impossible.  But with CommandEvents,
 shouldn't contentEditable=minimal be equivalent to:



 // Let editRegion be div contentEditable id='editRegion'



 var editRegion = document.getElementById(editRegion);

 editRegion.addEventListener(command, handleCommand);

 function handleCommand(evt){

   evt.preventDefault();

 }



 No default actions would be taken, but selection events would still fire
 and be handled.  There would be no ambiguity.  If implementing
 contentEditable=minimal on top of CommandEvents could just be a few lines
 of code, why complicate things by spec'ing another property?



 Then, if someone wants a region that just does basic text input, then they
 simply allow it:

 function handleCommand(evt){

  switch (evt.commandType){

case 'insertText':

  // Let the browser do text insertion

  break;

default:

  // Prevent all other magic

  evt.preventDefault();

 }



 This hedges on the fact that CommandEvents would capture ALL the cases
 that contentEditable currently handles, and that the event would fire
 BEFORE the dom is modified, and that calling preventDefault would cancel
 the event, but isn't that a goal of this design anyway?



 Julie



 -- Forwarded message --
 From: *Ben Peters* ben.pet...@microsoft.com
 Date: Thu, May 22, 2014 at 4:56 PM
 Subject: [editing] CommandEvent and contentEditable=minimal Explainer
 To: public-webapps@w3.org public-webapps@w3.org


 I have completed a first-draft explainer document [1], taking the generous
 feedback of many of you into account. There are 6 open issues on the
 document currently, and I'm sure there are others that I have missed. It
 would be great to know if this is heading in in the right direction.

 My vision is to use this a non-normative Explainer, and create 2 normative
 specs to go with it. The specs for contentEditable=minimal and CommandEvent
 should have first-drafts next week.

 Thanks!
 Ben

 [1] http://benjamp.github.io/commands-explainer.htm






-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer

RE: [editing] CommandEvent and contentEditable=minimal Explainer

2014-05-28 Thread Ben Peters

I don’t think we need to specify the default behavior. We can instead just say 
that all editing behaviors must fire Intention events that are cancellable. Any 
events that are already defined (like Clipboard) will continue to work, and 
others should fire CommandEvents as necessary.

We will likely need to have a list of well-known Command Events (like bold, 
undo, etc) just so we can have a shape for the related CommandData object, but 
we don’t need to specify the default behavior of those events.

From: Piotr Koszuliński [mailto:p.koszulin...@cksource.com]
Sent: Wednesday, May 28, 2014 2:40 PM
To: Ben Peters
Cc: Julie Parent; public-webapps@w3.org
Subject: Re: [editing] CommandEvent and contentEditable=minimal Explainer

But what is the default behaviour then? What will we be preventing? There's 
no accepted specification for current contentEditable=true AFAIK, so I thought 
that the goal of contentEditable=minimal is to avoid the need to write a 
specification for contentEditable=true. Otherwise, developers may demand from 
browser vendors that they fix their contentEditable=true implementations and I 
don't think that anyone wants that. Why not forget about contentEditable=true, 
make it deprecated and create specification only for algorithms needed by 
contentEditable=minimal and all required command events?

On Wed, May 28, 2014 at 10:39 PM, Ben Peters 
ben.pet...@microsoft.commailto:ben.pet...@microsoft.com wrote:
Great idea! If Intention Events (Clipboard, Selection, Command) cover all of 
the editing operations that a site would want to handle themselves, we don’t 
need CE Min as a feature, only a concept that can achieved with 
preventDefault().

From: Julie Parent [mailto:jpar...@gmail.commailto:jpar...@gmail.com]
Sent: Tuesday, May 27, 2014 4:40 PM
To: Ben Peters
Cc: public-webapps@w3.orgmailto:public-webapps@w3.org
Subject: Re: [editing] CommandEvent and contentEditable=minimal Explainer

The discussion of which minimal default handling to include with 
contenteditable=minimal makes me wonder if contentEditable=minimal is 
necessary at all.  It quickly becomes a can of worms of *which* default 
handling should be included, and it seems likely to not satisfy every use case 
no matter which decisions are made.  However, minimal is proposed as a 
building block because currently, disabling all default functionality of 
contentEditable=true is difficult/impossible.  But with CommandEvents, 
shouldn't contentEditable=minimal be equivalent to:

// Let editRegion be div contentEditable id='editRegion'

var editRegion = document.getElementById(editRegion);
editRegion.addEventListener(command, handleCommand);
function handleCommand(evt){
  evt.preventDefault();
}

No default actions would be taken, but selection events would still fire and be 
handled.  There would be no ambiguity.  If implementing 
contentEditable=minimal on top of CommandEvents could just be a few lines of 
code, why complicate things by spec'ing another property?

Then, if someone wants a region that just does basic text input, then they 
simply allow it:
function handleCommand(evt){
 switch (evt.commandType){
   case 'insertText':
 // Let the browser do text insertion
 break;
   default:
 // Prevent all other magic
 evt.preventDefault();
}

This hedges on the fact that CommandEvents would capture ALL the cases that 
contentEditable currently handles, and that the event would fire BEFORE the dom 
is modified, and that calling preventDefault would cancel the event, but isn't 
that a goal of this design anyway?

Julie

-- Forwarded message --
From: Ben Peters ben.pet...@microsoft.commailto:ben.pet...@microsoft.com
Date: Thu, May 22, 2014 at 4:56 PM
Subject: [editing] CommandEvent and contentEditable=minimal Explainer
To: public-webapps@w3.orgmailto:public-webapps@w3.org 
public-webapps@w3.orgmailto:public-webapps@w3.org


I have completed a first-draft explainer document [1], taking the generous 
feedback of many of you into account. There are 6 open issues on the document 
currently, and I'm sure there are others that I have missed. It would be great 
to know if this is heading in in the right direction.

My vision is to use this a non-normative Explainer, and create 2 normative 
specs to go with it. The specs for contentEditable=minimal and CommandEvent 
should have first-drafts next week.

Thanks!
Ben

[1] http://benjamp.github.io/commands-explainer.htm




--
Piotrek Koszuliński
CKEditor JavaScript Lead Developer

Re: contentEditable=minimal

2014-05-27 Thread Piotr Koszuliński

On Tue, May 27, 2014 at 1:48 AM, Ben Peters ben.pet...@microsoft.comwrote:

  5. There should be no native toolbars in cE=minimal (and other native
 UI
  interfering) like the one Safari opens on iOS if you have non-empty
  selection.
 I haven't yet checked exactly what's in the iOS toolbar, but generally
 I don't think we should dictate UI. Clearly on mobile we don't want to
 forbid browsers to bring up the virutal keyboard, which is a form of
 native UI. And the spellcheck UI that safari displays also doesn't
 seem bad if spellchecking is enabled.
 
 And UI for cut/copy/past that android renders seems good to render
 *somewhere* when there's selection.
 
 On iOS the contextual toolbar not only contains copy/cut options which
 are of course ok, but it also contains bold, italic and lists buttons.
 That's unacceptable and I assume this kind of native UI will not be
 implemented for cE=minimal.

 The goal of Command Event is to make this a non-issue. If sites respond to
 bold/italic/list commands they can handle this UI just fine. Are you
 concerned that a site may not use bold so the button would have no effect?


Yes, it should be possible to disable whichever feature you don't need. In
some cases you don't need lists (because e.g. you're editing a text that
will become a content of a paragraph). And in some cases you don't want
bold/italic because your use case requires only structured HTML. So being
able to handle such commands is a one thing. But first of all there should
be no assumption that a user needs these buttons, because a browser just
don't know about that. If I think that users need toolbar, I can render a
custom one.

There's one more assumption that makes editing on mobile devices
(especially low-res devices) very hard. It's that if user focuses editable,
then he/she wants to type, so native keyboard should pop out. Very often
it's true, but in some cases user may want to select some text and using
toolbar apply styles or lists, etc. And when the keyboard is visible
there's very little space to do that. If there was any API to control
whether keyboard is visible, then we could achieve much better UX.


-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer

Re: contentEditable=minimal


On 27/05/2014 01:47 , Ben Peters wrote:

-Original Message- From: Robin Berjon
On 26/05/2014 05:43 , Norbert Lindenberg wrote:

Were any speakers of bidirectional languages in the room when
this was discussed?


I don't know what languages the others speak. That said, my
recollection was that this was presented along the lines of we've
had regular requests to support selecting text in geometric rather
than logical orders.


I have also heard these requests from the bi-directional experts here
at Microsoft. A single, unbroken selection is what we're told users
want, and multi-selection makes this possible.


Thinking about this a little bit more: I don't imagine that the 
Selection API should prescribe the UI that browsers choose to support in 
order to select bidi text, on the contrary they should be allowed to 
innovate, experiment, follow various platform conventions, etc. But if 
we don't support multi-range selection, then only one model is possible 
which precludes unbroken selections.


I think that this strongly pushes in the direction of supporting 
multiple ranges.


--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: contentEditable=minimal


Hi Ben,

On 27/05/2014 02:07 , Ben Peters wrote:

From: Robin Berjon [mailto:ro...@w3.org] 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).


Agree. One way to do this would be BeforeSelectionChange having a
commandType indicating select forward and select by word.


I think we agree at the high level but might disagree over smaller
details. You seem to want something that would roughly resemble the
following:

BeforeSelectionChange
{
  direction:  forward
, step:   word
}

whereas I would see something capturing information more along those lines:

BeforeSelectionChange
{
  oldRange:  [startNode, startOffset, endNode, endOffset]
, newRange:  [startNode, startOffset, endNode, endOffset]
}

I think that the latter is better because it gives the library the
computed range that matches the operation, which as far as I can imagine
is what you actually want to check (e.g. check that the newRange does
not contain something unselectable, isn't outside a given boundary, etc.).

The former requires getting a lot of details right in the spec, and
those would become hard to handle at the script level. On some platforms
a triple click (or some key binding) can select the whole line. This not
only means that you need direction: both but also that the script
needs a notion of line that it has no access to (unless the Selection
API grants it). What makes up a word as a step also varies a lot (e.g.
I tend to get confused by what Office apps think a word is as it doesn't
match the platform's idea) and there can be interesting interactions
with language (e.g. is passive-aggressive one word or two? What about
co-operation?).

But maybe you have a use case for providing the information in that way
that I am not thinking of?


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.


I agree, except that I don't know why we want paste to fire two
'intention' events (paste and input). Seems like we should make it
clear that the intention is insert text (type, voice, whatever),
remove text (delete, including what text to remove), or paste (so you
can clean it up).


I don't think we want to fire both paste and input, but if my reading is 
correct that is the case today (or expected to be — this isn't exactly 
an area of high interop).


--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: contentEditable=minimal


On 25/05/2014 20:40 , Piotr Koszuliński wrote:

Making some things unselectable might also be useful. IE has
unselectable, there's also -moz-user-select and friends. But this is
small fries for later I'd reckon.

There are also nested non-editable islands. We built very important
feature based on them - http://ckeditor.com/demo#widgets. Currently we
block their selection by preventing mousedown and we handle left/right
arrows. But cancelling selectionchange would allow us to control more
cases in a cleaner way.


I'd be curious to know what your take is on the best way to expose this. 
IE has an unselectable attribute, whereas Gecko and WebKit have a CSS 
property. In this thread we've been talking about using cancellable 
events for this (or if not cancellable, ones in which the selection can 
be modified on the fly).


On instinct I would tend to think that this not a great usage of CSS, 
it's much more tied to behaviour at a lower level. But it sort of is one 
of those borderline things (as many of the properties that initially 
came from the CSS UI module).


The scriptable option that we're consider is good in that it enables 
arbitrary cases, but it could be interesting to support a number of 
cases out of the box with a simpler (for developers) approach.


Let's imagine the following DOM:

div contenteditable=minimal
  pblah blah blah/p
  div class=widget unselectable.../div
  pblah blah blah/p
/div

If the cursor is at the beginning of the first p, you hold Shift, and 
click at the end of the second p, we could imagine that you'd get a 
Selection with two Ranges (one for each p) and not containing the 
unselectable widget. I *think* that's the most desirable default 
behaviour, and it's also one that can be pretty painful to control 
through script. In that sense an unselectable attribute would make 
sense. (I reckon that setting the widget to be cE=false would have the 
same effect, but it is nevertheless an orthogonal property.)


WDYT?

--
Robin Berjon - http://berjon.com/ - @robinberjon

Composition events (was: contentEditable=minimal)


On 27/05/2014 01:52 , Ben Peters wrote:

Composition Events for IMEs, CommandEvents with type insertText for
all text input (including after Composition Events for IMEs)


I think we should be careful not to mix up composition events and IMEs. 
They may happen together, but IMEs have their own specific issues (e.g. 
popping up a window) that inline composition does not necessarily have. 
Also, IMEs can happen without composition: you could arguably popup a 
handwriting IME that would just insert text on commit without any 
composition taking place.


To stick to what I think is the simplest case, diacritic composition, 
here is what I believe the current D3E specification says (not that it's 
really clear on the matter, but I'm assuming best case scenario). For ñ 
you basically get:


  compositionstart ˜
  compositionend ñ

From what you're saying above you'd like to replace that with:

  compositionstart ˜
  input ñ

I think we can make that work, it drops on event and moves the code 
around. If you look at the Twitter Box code:



https://gist.github.com/darobin/8a128f05106d0e02717b#file-twitter-html-L102

It basically would need to move what's in the compositionend handler 
inside the beforeinput handler, with a check to see if compoRange exists 
(or the event has isComposing=true).


(I'm assuming that compositionupdate stays as is since we need to update 
the rendering with it.)


Is that the sort of flow you had in mind?

PS: note I just noticed that the code in the Gist was not the latest I 
had and had a lot of TODO bits — I've udpated it to the latest.


--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: contentEditable=minimal


On 27/05/2014 01:52 , Ben Peters wrote:

From: Robin Berjon [mailto:ro...@w3.org] On 23/05/2014 01:23 , Ben
Peters wrote:

As I said I am unsure that the way in which composition events
are described in DOM 3 Events is perfect, but that's only
because I haven't used them in anger and they aren't supported
much.


My thought is that we can use CommandEvent with
type=insertText. This would be the corollary to
execComamnd(insertText), and the data would be the ñ that is
about to be inserted.


But if you only get one event you can't render the composition as
it is carrying out.


I believe Composition Events are very important for IME input, but we
should fire CommandEvent with Insert text for all text input,
including IME. Are you saying we should use Composition Events even
for non-IME input?


I am not using an IME, and yet I could not type in French on my keyboard 
without composition.


Obviously, if I switch to Kotoeri input, I'll get composition *and* an 
IME popup. But for regular French input (in a US keyboard) I need:


  é - Alt-E, E
  è - Alt-`, E
  à - Alt-`, A
  ô - Alt-I, O
  ü - Alt-U, U
  ñ - Alt-˜, N (for the occasional Spanish)
  (and a bunch more)

Some older apps (you pretty much can't find them anymore) used to not 
display the composition as it was ongoing and only show the text after 
composition had terminated. That was survivable but annoying, and it 
only worked because composition in Latin-script languages is pretty 
trivial (except perhaps for all you Livonian speakers out there!), but I 
don't think it would be viable for more complex compositions. And even 
in simple cases it would confuse users to be typing characters with no 
rendering feedback.


Without composition events you can't render the ongoing composition. See 
what's going on at:



https://gist.github.com/darobin/8a128f05106d0e02717b#file-twitter-html-L81

That is basically inserting text in a range that's decorated to be 
underlined to show composition in progress. Composition updates 
*replace* the text in the range. And at the end the range is removed and 
text is inserted.


The above is for Mac, but I have distant memories of using something 
similar on Windows called the US International Keyboard where you 
could have apostrophes compose as accents, etc.. I don't recall how it 
was rendered though.


--
Robin Berjon - http://berjon.com/ - @robinberjon

contentEditable and forms (was: contentEditable=minimal)


On 27/05/2014 09:19 , Piotr Koszuliński wrote:

Yes, it should be possible to disable whichever feature you don't need.
In some cases you don't need lists (because e.g. you're editing a text
that will become a content of a paragraph). And in some cases you don't
want bold/italic because your use case requires only structured HTML. So
being able to handle such commands is a one thing. But first of all
there should be no assumption that a user needs these buttons, because a
browser just don't know about that. If I think that users need toolbar,
I can render a custom one.


Much agreed. The browser should not show any markup/styling affordance 
for cE=minimal.



There's one more assumption that makes editing on mobile devices
(especially low-res devices) very hard. It's that if user focuses
editable, then he/she wants to type, so native keyboard should pop out.
Very often it's true, but in some cases user may want to select some
text and using toolbar apply styles or lists, etc. And when the keyboard
is visible there's very little space to do that. If there was any API to
control whether keyboard is visible, then we could achieve much better UX.


There are quite a few things from forms that I think could usefully 
become available in an editing context. We could benefit from having the 
inputmode attribute be allowed on any editable piece of text. For the 
specific use case you cite, an additional keyword of none might make 
sense too.


It possibly wouldn't hurt to have the placeholder attribute be available 
on all editable content, too. I'm less sure about the validation 
attributes (except perhaps required) but why not.


Obviously validation attributes only make sense if the editable content 
can contribute to forms. But it would make a lot of sense that it could. 
Today you have to resort to ugly hacks in which you somehow copy over 
the edited content into a textarea. That's pretty daft: in most use 
cases you're going to be submitting the content.


There are several ways in which we could handle this. One is to have any 
element with cE=minimal contribute to the form data set (when inside a 
form, or possibly when using the form attribute if someone remembers 
what the use case for that thing was). That's interesting, but I get a 
sense that it conflates two features. Another approach is to add a 
submittable attribute that can make the innerHTML of any element 
contribute to the form data set.


Thoughts?

--
Robin Berjon - http://berjon.com/ - @robinberjon

RE: contentEditable=minimal

2014-05-27 Thread Travis Leithead

+Gary and Masayuki

--This seems very related to the discussion we are having regarding when to 
fire beforeinput. beforeinput might be duplicating some of the use-cases 
that the insertText command event might be supporting.

-Original Message-
From: Robin Berjon [mailto:ro...@w3.org] 
Sent: Tuesday, May 27, 2014 2:39 AM
To: Ben Peters; Julie Parent
Cc: Johannes Wilm; public-webapps@w3.org
Subject: Re: contentEditable=minimal

On 27/05/2014 01:52 , Ben Peters wrote:
 From: Robin Berjon [mailto:ro...@w3.org] On 23/05/2014 01:23 , Ben
 Peters wrote:
 As I said I am unsure that the way in which composition events
 are described in DOM 3 Events is perfect, but that's only
 because I haven't used them in anger and they aren't supported
 much.

 My thought is that we can use CommandEvent with
 type=insertText. This would be the corollary to
 execComamnd(insertText), and the data would be the ñ that is
 about to be inserted.

 But if you only get one event you can't render the composition as
 it is carrying out.

 I believe Composition Events are very important for IME input, but we
 should fire CommandEvent with Insert text for all text input,
 including IME. Are you saying we should use Composition Events even
 for non-IME input?

I am not using an IME, and yet I could not type in French on my keyboard 
without composition.

Obviously, if I switch to Kotoeri input, I'll get composition *and* an 
IME popup. But for regular French input (in a US keyboard) I need:

   é - Alt-E, E
   è - Alt-`, E
   à - Alt-`, A
   ô - Alt-I, O
   ü - Alt-U, U
   ñ - Alt-˜, N (for the occasional Spanish)
   (and a bunch more)

Some older apps (you pretty much can't find them anymore) used to not 
display the composition as it was ongoing and only show the text after 
composition had terminated. That was survivable but annoying, and it 
only worked because composition in Latin-script languages is pretty 
trivial (except perhaps for all you Livonian speakers out there!), but I 
don't think it would be viable for more complex compositions. And even 
in simple cases it would confuse users to be typing characters with no 
rendering feedback.

Without composition events you can't render the ongoing composition. See 
what's going on at:

https://gist.github.com/darobin/8a128f05106d0e02717b#file-twitter-html-L81

That is basically inserting text in a range that's decorated to be 
underlined to show composition in progress. Composition updates 
*replace* the text in the range. And at the end the range is removed and 
text is inserted.

The above is for Mac, but I have distant memories of using something 
similar on Windows called the US International Keyboard where you 
could have apostrophes compose as accents, etc.. I don't recall how it 
was rendered though.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

RE: Composition events (was: contentEditable=minimal)

2014-05-27 Thread Travis Leithead

+Gary/Masayuki who can help with deciphering DOM L3 Events :-)

-Original Message-
From: Robin Berjon [mailto:ro...@w3.org] 
Sent: Tuesday, May 27, 2014 2:15 AM
To: Ben Peters; Jonas Sicking
Cc: public-webapps@w3.org
Subject: Composition events (was: contentEditable=minimal)

On 27/05/2014 01:52 , Ben Peters wrote:
 Composition Events for IMEs, CommandEvents with type insertText for
 all text input (including after Composition Events for IMEs)

I think we should be careful not to mix up composition events and IMEs. 
They may happen together, but IMEs have their own specific issues (e.g. 
popping up a window) that inline composition does not necessarily have. 
Also, IMEs can happen without composition: you could arguably popup a 
handwriting IME that would just insert text on commit without any 
composition taking place.

To stick to what I think is the simplest case, diacritic composition, 
here is what I believe the current D3E specification says (not that it's 
really clear on the matter, but I'm assuming best case scenario). For ñ 
you basically get:

   compositionstart ~
   compositionend ñ

 From what you're saying above you'd like to replace that with:

   compositionstart ~
   input ñ

I think we can make that work, it drops on event and moves the code 
around. If you look at the Twitter Box code:

https://gist.github.com/darobin/8a128f05106d0e02717b#file-twitter-html-L102

It basically would need to move what's in the compositionend handler 
inside the beforeinput handler, with a check to see if compoRange exists 
(or the event has isComposing=true).

(I'm assuming that compositionupdate stays as is since we need to update 
the rendering with it.)

Is that the sort of flow you had in mind?

PS: note I just noticed that the code in the Gist was not the latest I 
had and had a lot of TODO bits - I've udpated it to the latest.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

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

2014-05-26 Thread Anne van Kesteren

On Mon, May 26, 2014 at 4:17 AM, Yoshifumi Inoue yo...@chromium.org 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: contentEditable=minimal

2014-05-26 Thread Robin Berjon


On 26/05/2014 05:43 , Norbert Lindenberg wrote:

On May 23, 2014, at 5:19 , Robin Berjon ro...@w3.org wrote:

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).


Were any speakers of bidirectional languages in the room when this
was discussed?


I don't know what languages the others speak. That said, my recollection 
was that this was presented along the lines of we've had regular 
requests to support selecting text in geometric rather than logical orders.


If that turns out not to be the case and we can stick to single-range 
selections, it would certainly make the Selection API simpler.


--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: contentEditable=minimal

2014-05-26 Thread Norbert Lindenberg

On May 23, 2014, at 5:19 , Robin Berjon ro...@w3.org wrote:

 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).

Were any speakers of bidirectional languages in the room when this was 
discussed?

Norbert

RE: contentEditable=minimal

 5. There should be no native toolbars in cE=minimal (and other native UI
 interfering) like the one Safari opens on iOS if you have non-empty
 selection.
I haven't yet checked exactly what's in the iOS toolbar, but generally
I don't think we should dictate UI. Clearly on mobile we don't want to
forbid browsers to bring up the virutal keyboard, which is a form of
native UI. And the spellcheck UI that safari displays also doesn't
seem bad if spellchecking is enabled.

And UI for cut/copy/past that android renders seems good to render
*somewhere* when there's selection.

On iOS the contextual toolbar not only contains copy/cut options which are of 
course ok, but it also contains bold, italic and lists buttons. That's 
unacceptable and I assume this kind of native UI will not be implemented for 
cE=minimal.

The goal of Command Event is to make this a non-issue. If sites respond to 
bold/italic/list commands they can handle this UI just fine. Are you concerned 
that a site may not use bold so the button would have no effect?

RE: contentEditable=minimal

 -Original Message-
 From: Robin Berjon [mailto:ro...@w3.org]
 Sent: Monday, May 26, 2014 1:41 AM
 To: Norbert Lindenberg
 Cc: Jonas Sicking; Piotr Koszuliński; Ben Peters; public-webapps
 Subject: Re: contentEditable=minimal

 On 26/05/2014 05:43 , Norbert Lindenberg wrote:
  On May 23, 2014, at 5:19 , Robin Berjon ro...@w3.org wrote:
  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).

  Were any speakers of bidirectional languages in the room when this was
  discussed?

 I don't know what languages the others speak. That said, my recollection was
 that this was presented along the lines of we've had regular requests to
 support selecting text in geometric rather than logical orders.

 If that turns out not to be the case and we can stick to single-range 
 selections,
 it would certainly make the Selection API simpler.

I have also heard these requests from the bi-directional experts here at 
Microsoft. A single, unbroken selection is what we're told users want, and 
multi-selection makes this possible.

RE: contentEditable=minimal

 -Original Message-
 From: Robin Berjon [mailto:ro...@w3.org]
 
 On 23/05/2014 01:23 , Ben Peters wrote:
  As I said I am unsure that the way in which composition events are
  described in DOM 3 Events is perfect, but that's only because I
  haven't used them in anger and they aren't supported much.
 
  My thought is that we can use CommandEvent with type=insertText.
  This would be the corollary to execComamnd(insertText), and the data
  would be the ñ that is about to be inserted.
 
 But if you only get one event you can't render the composition as it is
 carrying out.
 

I believe Composition Events are very important for IME input, but we should 
fire CommandEvent with Insert text for all text input, including IME. Are you 
saying we should use Composition Events even for non-IME input?

RE: contentEditable=minimal

 From: Robin Berjon [mailto:ro...@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).
 

Agree. One way to do this would be BeforeSelectionChange having a commandType 
indicating select forward and select by word.

  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).

Yes please:) Cursor and selection are the same thing.
 
  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.

I agree, except that I don't know why we want paste to fire two 'intention' 
events (paste and input). Seems like we should make it clear that the intention 
is insert text (type, voice, whatever), remove text (delete, including what 
text to remove), or paste (so you can clean it up). 
 
-Ben

Re: contentEditable=minimal

2014-05-25 Thread Piotr Koszuliński

 native UI
  interfering) like the one Safari opens on iOS if you have non-empty
  selection.

 I haven't yet checked exactly what's in the iOS toolbar, but generally
 I don't think we should dictate UI. Clearly on mobile we don't want to
 forbid browsers to bring up the virutal keyboard, which is a form of
 native UI. And the spellcheck UI that safari displays also doesn't
 seem bad if spellchecking is enabled.

 And UI for cut/copy/past that android renders seems good to render
 *somewhere* when there's selection.


 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?

 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? What about the beforeinput event?

 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.

 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 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'd also be interested trying out having the browser perform
 plain-text DOM mutations but make sure to keep the rules very simple.
 So if you select a stretch of text and press delete, we would not do
 any DOM mutation (or possibly we could delete just any text content,
 possibly leaving elements empty). Then see how much of a pain it would
 be to allow the page to apply its own rules like ensure all
 characters are lowercase or insert thousand separators in numbers
 or do syntax highlighting of JS code.


 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.

 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.

 / Jonas




-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer
--
CKSource - http://cksource.com
--
Follow CKEditor on: Twitter http://twitter.com/ckeditor |
Facebookhttp://www.facebook.com/ckeditor|
Google+ https://plus.google.com/107736718646302128806 |
LinkedInhttp://www.linkedin.com/company/cksource

6. Spell check. When you want a native spell check you cannot override
context menu. When you want custom context menu, you need custom spell
check
(which is extremely hard). And context menu is very important for many
users
because they used to look there for contextual options, so most editors
override it. Therefore, a way control at least one of them (I guess it
won't
be a context menu, though that would be awesome) will be great.

There's already a contextmenu feature in HTML, though I don't know if
any other browser than Firefox implements it. And the spec has seen so
much changes that I don't know how closely Firefox conforms to the
spec. Anyhow, I think the ability to extend/replace the existing
context menu is the way to go if that's what people need.

Do you mean:
http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus
?

I didn't know about it. It doesn't seem to work on any browser yet, but it
should be able to solve our problems. I hope it will be implemented soon.

5. There should be no native toolbars in cE=minimal (and other native UI
interfering) like the one Safari opens on iOS if you have non-empty
selection.

I haven't yet checked exactly what's in the iOS toolbar, but generally
I don't think we should dictate UI. Clearly on mobile we don't want to
forbid browsers to bring up the virutal keyboard, which is a form of
native UI. And the spellcheck UI that safari displays also doesn't
seem bad if spellchecking is enabled.

And UI for cut/copy/past that android renders seems good to render
*somewhere* when there's selection.

On iOS the contextual toolbar not only contains copy/cut options which are
of course ok, but it also contains bold, italic and lists buttons. That's
unacceptable and I assume this kind of native UI will not be implemented
for cE=minimal.

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.

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.

Wow! Such feature would be awesome. This reminds me about an idea mentioned
in https://medium.com/medium-eng/122d8a40e480 that cE could be
reimplemented with shadow DOM. It would be extremely powerful if caret and
selection and styled ranges were real, accessible elements.

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) {...}).

Uh... multi-range selections. I find myself and my colleagues ignoring
them. They add so much complexity to already complex tasks that we simply
handle first range and ignore other. And I don't remember complains about
that. They make some sense when selecting table columns but this is not a
necessary feature and may be also handled by an editor by fake selection.
Multiple carets are useful in code editors, but not a single text editor's
end user know about them (and I believe they were removed from Firefox). I
don't know the bidi case though. But if it could be handled without
multi-range selections I would gladly forget about them.

--
Piotrek Koszuliński
CKEditor JavaScript Lead Developer

Re: contentEditable=minimal

2014-05-25 Thread Piotr Koszuliński




  * Cursor navigation, including reacting to touch events, mouse clicks
 and keyboard events. Cursor navigation would likely also fire
 cancelable events.


 Yes. Cursor navigation can be represented through selections (that may be
 collapsed). In general it is important that selection changes can be
 cancelled so that developers can carry out selection validation before
 accepting it.

 Making some things unselectable might also be useful. IE has unselectable,
 there's also -moz-user-select and friends. But this is small fries for
 later I'd reckon.


There are also nested non-editable islands. We built very important feature
based on them - http://ckeditor.com/demo#widgets. Currently we block their
selection by preventing mousedown and we handle left/right arrows. But
cancelling selectionchange would allow us to control more cases in a
cleaner way.


-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer

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

2014-05-25 Thread Yoshifumi Inoue

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 ro...@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

Re: contentEditable=minimal

2014-05-23 Thread Jonas Sicking

On Thu, May 22, 2014 at 3:59 AM, Piotr Koszuliński
p.koszulin...@cksource.com wrote:
 ## What should cE=minimal handle?

Awesome feedback!

 ## What should cE=minimal handle?

 1. Selection and caret drawing.
 2. Selection API

Agreed on both!

 3. Typing characters.
 4. Delete, backspace.

I think these are the hard ones. More below.

 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.

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.

 6. Spell check. When you want a native spell check you cannot override
 context menu. When you want custom context menu, you need custom spell check
 (which is extremely hard). And context menu is very important for many users
 because they used to look there for contextual options, so most editors
 override it. Therefore, a way control at least one of them (I guess it won't
 be a context menu, though that would be awesome) will be great.

There's already a contextmenu feature in HTML, though I don't know if
any other browser than Firefox implements it. And the spec has seen so
much changes that I don't know how closely Firefox conforms to the
spec. Anyhow, I think the ability to extend/replace the existing
context menu is the way to go if that's what people need.

Adding spellchecking primitivies, and forcing webpages to implement
their own spellcheck, seems like the wrong way to go about enabling
pages to do their own context menus.

 ## What should not be handled by cE=minimal?

 1. Bold, italic, list, link, blockquote and other commands creating content.
 2. Enter key support.
 3. Tables and images resizing.
 4. Another thing that browser engines cannot do is trying to be... too
 smart?

Strongly agree with all of these.

 5. There should be no native toolbars in cE=minimal (and other native UI
 interfering) like the one Safari opens on iOS if you have non-empty
 selection.

I haven't yet checked exactly what's in the iOS toolbar, but generally
I don't think we should dictate UI. Clearly on mobile we don't want to
forbid browsers to bring up the virutal keyboard, which is a form of
native UI. And the spellcheck UI that safari displays also doesn't
seem bad if spellchecking is enabled.

And UI for cut/copy/past that android renders seems good to render
*somewhere* when there's selection.


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?

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? What about the beforeinput event?

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.

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 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'd also be interested trying out having the browser perform
plain-text DOM mutations but make sure to keep the rules very simple.
So if you select a stretch of text and press delete, we would not do
any DOM mutation (or possibly we could delete just any text content,
possibly leaving elements empty). Then see how much of a pain it would
be to allow the page to apply its own rules like ensure all
characters are lowercase or insert

Re: contentEditable=minimal


On 23/05/2014 01:23 , Ben Peters wrote:

As I said I am unsure that the way in which composition events are
described in DOM 3 Events is perfect, but that's only because I
haven't used them in anger and they aren't supported much.


My thought is that we can use CommandEvent with type=insertText.
This would be the corollary to execComamnd(insertText), and the
data would be the ñ that is about to be inserted.


But if you only get one event you can't render the composition as it is 
carrying out.


--
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

Re: contentEditable=minimal


On 23/05/2014 12:28 , Jonas Sicking wrote:

And on mobile autocorrect of misspelled words is common, though that
can probably be handled by moving the selection to the misspelled word
and then writing the fixed word.


Autocorrect should be handled like composition. Composition is pretty 
much what happens whenever you type some stuff and some other stuff 
comes out. (Technical definition.)



Though one interesting edge case there is what happens if the page
adjusts the selection as it's being moved to the word autocorrect
wants to fix?


I'm sorry, I don't understand the case you're thinking of?

--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: contentEditable=minimal