- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Fri, 06 Jun 2014 09:47:16 -0700
- To: Robin Berjon <robin@w3.org>
- Cc: Julie Parent <jparent@gmail.com>, Ben Peters <Ben.Peters@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On Jun 6, 2014, at 6:27 AM, Robin Berjon <robin@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
Received on Friday, 6 June 2014 16:47:45 UTC