RE: [editing] CommandQuery Object and Event

Is it just browser UI that leads you to want to start over? The goal of CommandEvents is to allow sites/frameworks to work with browser UI, whether toolbars like Safari or gestures or speech or accessibility tools or whatever else in the future. I understand that browser UI can be a problem today since you can't respond to it, but once you have CommandEvents you'll be able to treat a bold button just like control+b by listening for a bold event. We are also working on coming up with a way (currently called CommandQuery Event [1]) to enable browsers to determine which commands are available, which would help browser UI display correctly and would also help accessibility tools tell users what they can do. Simply removing browser toolbars doesn't mean there are no other ways to interact with a page that users expect to work- take shake-to-undo in iOS for example.

[1] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0791.html


On Mon, Jun 9, 2014 at 6:50 AM, Piotr Koszuliński <p.koszulinski@cksource.com> wrote:
> I don't want to say that these options should never be added. I don't also
> want to say that they should be first standardised, then implemented (though
> that would be perfect of course) or that they should be now dropped
> (backward compatibility is a requirement I understand very well). My point
> is that we would need to take all this into account when thinking about
> fixing contenteditable=true. It must stop be surprising and unpredictable
> for developers. That I think should be our goal - to make it predictable and
> controllable.
>
> There are two paths to achieve this goal:
>
> 1. Make all what's already implemented controllable, or at least possible to
> disable.
> 2. Start from scratch (meaning contenteditable=minimal as an option, not as
> a concept).
>
> When the first option seems to be tempting I still believe it's not the
> right way. It will force us to think about all the crazy stuff like native
> toolbars, fonts, transformations, text direction, automatic substitutions,
> ability to add new options, setting icons, a11y, localisable labels for new
> options etc. All these things are complicated just by themselves and besides
> them we still need to fit input or intent events, commands, their states,
> etc. Even if we'll focus only on making all these controllable (without
> defining expected behaviour) then we'll have to solve problems like - should
> a command be executable if I disabled it? No? What if I want to remove that
> option from native context menu/toolbar but reuse the implementation?
>
> That's why I think that the second option is better. Contenteditable=minimal
> should not only be a concept - we need an option. Option which will allow
> us, while creating a spec, to forget about legacy features and not care
> about backward compatibility (which will be left in form of
> contenteditable=true). In a shorter period we'll be able to come out with a
> solution to at least part of the current problems and the solution should
> also be cleaner. Otherwise, I'm afraid that the new spec will end like the
> old one did.
>
> Simultaneously, contenteditable=true will still be usable. In use cases not
> satisfied by contenteditable=minimal developers will be able to use
> contenteditable=true. Moreover, there will be a possibility to "backport"
> features (like APIs and maybe command events) to contenteditable=true. But
> the primary goal should be to make contenteditable=minimal useful, not to
> enrich contenteditable=true.
>  
>
> --
> Piotrek Koszuliński
> CKEditor JavaScript Lead Developer

Received on Monday, 9 June 2014 20:29:15 UTC