Re: [editing] CommandQuery Object and Event
On Jun 9, 2014, at 4:21 PM, Piotr Koszuliński p.koszulin...@cksource.com wrote: Responding to browser UI is one thing and I totally agree with the need for user intent events. If user shakes iPhone editor should be notified that user wanted to undo. But I does not tie this to commands at this point at all. Events exist to notify app that something is going to happen. The default behaviour of what happens may be hidden behind a command, method or engine internals, but that's a separate topic. As for CommandQuery Event, I commented it in [2] and indirectly in my previous email. In my opinion it tries to hide symptoms of contenteditable's sickness rather than cure it. Existing commands break my app or are useless for it, so let me allow to disable them. 1. Most editors will disable as much of them as possible (I wonder what about paste/cut/copy) to hide native UI which may conflict with custom UI (e.g. overlap it) or simply to block undesired, unclear feature. 2. If developer is forced to leave any of commands enabled (e.g. to not lose clipboard support), he/she risks that native UI will be displayed and will break his app. 3. If developer wants to enable some option (e.g. smart quotes) he/she risks that native UI will break his app or that user will be able to disable such option when should not be able to do that. 4. Some of these issues may be solved by special commands blocking native UI without disabling specific commands. 5. In many scenarios native UI is useless, because it cannot be extended and redesigned (new buttons, new types of UI elements), so it only satisfies small subset of use cases. 6. Even if e.g. mobile Safari displays all buttons necessary for developer's use case, if any other browser does not do that, then developer has to override everything anyway. Without interoperability 7. A11y is not a reason to make browser handle all the UI. If ARIA's roles are not sufficient or some API is missing, then they should be added, not native UI extended. As I said, most of (advanced) editors will need to hide native UI, so if providing a11y using HTML and JavaScript is not possible on some platform (mobile?), then this problem will need to be solved anyway. 8. What if some command should have configurable behaviour? For example quote characters used by smart quotes feature might be configurable (language dependent?). What API allows this? Assuming that we've got two commands - disableSmartQuotes and enableSmartQuotes, which of them I have to disable to get rid of them from the UI? Sure there's a solution for all that, but extending commands APIs indefinitely will lead to even bigger mess than now. And having bazillion options in tight high-level API, without providing any primitives is a bad design choice. None of these points is a deal breaker when considered separately. But all of them (plus many we don't yet see) combined together makes the situation look terrible. Commands, related APIs, native UI are useless or problematic for editors (meaning real editors, not these adding contenteditable=true to a div) and still will be useless. Commands API might look extensible, because it uses strings as commands identifiers, but that's a very high-level native API, so if any feature is not included (like setting characters used by smart quotes), everything has to be implemented in JS from scratch. Native UI is inextensible and uncontrollable and still will be (command events cover only execution logic). Someone said that contenteditable=true tries to be an entire WYSIWYG editor (a poor one actually) at once and that that's bad. I couldn't agree more. Is adding new options to tame the contenteditable=true going to fix this? No. It will make the situation slightly more acceptable, but contenteditable=true is still terminally ill, because it still pretends to be an editor I think you're presuming that we're going to keep all the features enabled by default, and let authors disable them later. That would indeed cause a problem for editors such as code editor or semantic editor that need to have a more fine control over what goes into the editor. On the other hand, features such as smart quotes, autocorrections, spellchecking are platform-wide features (on OS X and iOS). Not having such features inside an editable region in a browser would only confuse users. So editors that don't need to have full control over the content should be able to get these features for free, and editors that need more granular control should be able to opt-in. For the latter case, we could come up with a set of categories for common editing features new platforms and browsers tend to introduce/support, and provide an API for each category of editing operations so that authors could intercept them as needed (e.g. a pair of replacement events for smart quotes) without having to explicitly support each and
Re: [editing] CommandQuery Object and Event
On Fri, Jun 6, 2014 at 6:39 PM, Ryosuke Niwa rn...@apple.com wrote: On Jun 6, 2014, at 4:29 AM, Piotr Koszuliński p.koszulin...@cksource.com wrote: 1. That we need any native UI related to cE at all. We don't. We can display our own toolbars, with our own buttons, with our own icons and implementing our own logic. So the easiest solution to the problem with irrelevant native UI is to not display it at all. You may not need native UI working at all in your app, but that doesn't mean all other developers don't want it at all. Furthermore, enabled-ness of items in desktop browser's edit menu should reflect the current state of the editor; otherwise, it would degrade the user experience. Furthermore, we shouldn't design our API only for existing platforms. We need to make it so that new, completely different paradigm of UIs and devices could be built using new API we design. Another important use case for browsers to know the state of the editor is for accessibility. AT may, for example, want to enumerate the list of commands available on the page for the user. 2. That we need any native architecture for commands. We don't. What a command is? It's a name, function and a state+value refreshed on selection change. A command repository can be implemented in JavaScript in few lines of code. CKEditor has one (and I guess that all advanced editors have), because it is a necessary component on which we must have full control. What it does, when it does, how a command is executed, what arguments it accepts, which commands are available for specific editor instance, etc. Providing default editing behavior may not be desirable for that reason. However, it would be still of connivence to provide some helper functions to do the work automatically when the author opts-in so that he/she doesn't have to write every single editing logic himself/herself. I am sorry for the dramatic tone of this message, but I am honestly shocked by my today's discovery. Namely, I checked what Safari displays in contenteditable's context menu. For those who don't have access to Safari: * Substitutions (set of options like smart copy/paste, smart quotes, smart dashes, smart links, etc. plus show substitutions option displaying a native popup). * Transformations (make upper/lower case, capitalize). * Fonts (two options that do not work (show fonts and show colors) plus bold, italic, etc.). * Paragraph direction (ltr, rtl). So what I saw on a mobile Safari (the floating toolbar) was only a tip of an iceberg. 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
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.koszulin...@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
Re: [editing] CommandQuery Object and Event
Responding to browser UI is one thing and I totally agree with the need for user intent events. If user shakes iPhone editor should be notified that user wanted to undo. But I does not tie this to commands at this point at all. Events exist to notify app that something is going to happen. The default behaviour of what happens may be hidden behind a command, method or engine internals, but that's a separate topic. As for CommandQuery Event, I commented it in [2] and indirectly in my previous email. In my opinion it tries to hide symptoms of contenteditable's sickness rather than cure it. Existing commands break my app or are useless for it, so let me allow to disable them. 1. Most editors will disable as much of them as possible (I wonder what about paste/cut/copy) to hide native UI which may conflict with custom UI (e.g. overlap it) or simply to block undesired, unclear feature. 2. If developer is forced to leave any of commands enabled (e.g. to not lose clipboard support), he/she risks that native UI will be displayed and will break his app. 3. If developer wants to enable some option (e.g. smart quotes) he/she risks that native UI will break his app or that user will be able to disable such option when should not be able to do that. 4. Some of these issues may be solved by special commands blocking native UI without disabling specific commands. 5. In many scenarios native UI is useless, because it cannot be extended and redesigned (new buttons, new types of UI elements), so it only satisfies small subset of use cases. 6. Even if e.g. mobile Safari displays all buttons necessary for developer's use case, if any other browser does not do that, then developer has to override everything anyway. Without interoperability 7. A11y is not a reason to make browser handle all the UI. If ARIA's roles are not sufficient or some API is missing, then they should be added, not native UI extended. As I said, most of (advanced) editors will need to hide native UI, so if providing a11y using HTML and JavaScript is not possible on some platform (mobile?), then this problem will need to be solved anyway. 8. What if some command should have configurable behaviour? For example quote characters used by smart quotes feature might be configurable (language dependent?). What API allows this? Assuming that we've got two commands - disableSmartQuotes and enableSmartQuotes, which of them I have to disable to get rid of them from the UI? Sure there's a solution for all that, but extending commands APIs indefinitely will lead to even bigger mess than now. And having bazillion options in tight high-level API, without providing any primitives is a bad design choice. None of these points is a deal breaker when considered separately. But all of them (plus many we don't yet see) combined together makes the situation look terrible. Commands, related APIs, native UI are useless or problematic for editors (meaning real editors, not these adding contenteditable=true to a div) and still will be useless. Commands API might look extensible, because it uses strings as commands identifiers, but that's a very high-level native API, so if any feature is not included (like setting characters used by smart quotes), everything has to be implemented in JS from scratch. Native UI is inextensible and uncontrollable and still will be (command events cover only execution logic). Someone said that contenteditable=true tries to be an entire WYSIWYG editor (a poor one actually) at once and that that's bad. I couldn't agree more. Is adding new options to tame the contenteditable=true going to fix this? No. It will make the situation slightly more acceptable, but contenteditable=true is still terminally ill, because it still pretends to be an editor. [2] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0826.html On Mon, Jun 9, 2014 at 10:28 PM, Ben Peters ben.pet...@microsoft.com wrote: 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 -- Piotrek Koszuliński CKEditor JavaScript Lead Developer
Re: [editing] CommandQuery Object and Event
On Wed, Jun 4, 2014 at 8:31 PM, Ben Peters ben.pet...@microsoft.com wrote: There has been some conversation about browser UI for Commands with ContentEdtiable=minimal. Some people seem to believe that UI should not be displayed because it may not be relevant. I think that it was me talking about mobile Safari displaying its native toolbar over contenteditable field. But this is not a solution I had in mind. Few weeks ago we started discussing about contentEditable=minimal. It was a great relief for me, because I consider contentEditable=true being already ideologically dead for a long time and I see no point in resurrecting it. There was a common agreement that contentEditable=true is wrong because it tries to be an entire application rather than just a base, a necessary architecture for frameworks and applications built in JavaScript on top of it. Why I mention this now? Because I think that two wrong assumptions have been made. 1. That we need any native UI related to cE at all. We don't. We can display our own toolbars, with our own buttons, with our own icons and implementing our own logic. So the easiest solution to the problem with irrelevant native UI is to not display it at all. 2. That we need any native architecture for commands. We don't. What a command is? It's a name, function and a state+value refreshed on selection change. A command repository can be implemented in JavaScript in few lines of code. CKEditor has one (and I guess that all advanced editors have), because it is a necessary component on which we must have full control. What it does, when it does, how a command is executed, what arguments it accepts, which commands are available for specific editor instance, etc. In a simple case, when I want my FontName command to apply span class=font[[Name]] to selected text instead of the default... font family=[[Name]], I need to: a) Totally override the way how command is applied. I need to remove other spans with classes starting with font class, and wrap content with my new span. b) Totally override command's state and value handling. It has to discover correct span tags (only these with proper classes), read the font family name from class name and handle it accordingly. Additionally, I don't have to do that on every selectionchange event - I care only about selectionchange events fired when an element in which selection starts changes. This is a big performance improvement. So what's left from a native command? Nothing. I can't even reuse algorithm applying inline elements to selection. That actually would be useful, but such algorithm also needs to be customisable, so it's better if it's implemented in JavaScript. TL;DR 1. Let's drop execCommand and queryCommandState. They have no real value for developers and clearly conflict with cE=minimal. JavaScript frameworks will be created which will allow implementing totally custom and customisable commands. 2. Expose necessary APIs and architecture so all necessary commands can be implemented in JavaScript. Currently I can think only about copy, cut, paste which someone may want to disabled in some conditions. Maybe also undo and redo, because I can imagine that advanced editor's logic may be too complex to use native undo manager (but maybe I'm wrong - I haven't read undo manager's spec). Basically, it would be nice if we were able to control state of commands that should appear in browser menu bar or context menu, but that does not have to be based on currently existing commands API. -- Piotrek Koszuliński CKEditor JavaScript Lead Developer
Re: [editing] CommandQuery Object and Event
On Fri, Jun 6, 2014 at 1:29 PM, Piotr Koszuliński p.koszulin...@cksource.com wrote: TL;DR 1. Let's drop execCommand and queryCommandState. They have no real value for developers and clearly conflict with cE=minimal. JavaScript frameworks will be created which will allow implementing totally custom and customisable commands. 2. Expose necessary APIs and architecture so all necessary commands can be implemented in JavaScript. Currently I can think only about copy, cut, paste which someone may want to disabled in some conditions. Maybe also undo and redo, because I can imagine that advanced editor's logic may be too complex to use native undo manager (but maybe I'm wrong - I haven't read undo manager's spec). Basically, it would be nice if we were able to control state of commands that should appear in browser menu bar or context menu, but that does not have to be based on currently existing commands API. To give an example. 1. User presses down key. 2. A command event with commandType == 'moveSelectionDown' is fired. 3 a. If app does not execute preventDefault(), then the default action is executed by browser. The default action means executing e.g. selection.move( DIRECTION_DOWN ) or any other more complex code but using exposed APIs. 3 b. If app executes preventDefault(), then it can call selection.move( DIRECTION_DOWN ) and the result should be identical. Or it can preventDefault() and e.g. execute selection.move( DIRECTION_END_OF_DOCUMENT ) The idea is to expose necessary functions in form of selection/element/whatever methods and use these methods. The same may be achieved by execCommand() and related methods, but: a) backward compatibility, b) not standardised, c) too high-level in some cases, d) not the best API design ever, e) problem with extensibility. -- Piotrek Koszuliński CKEditor JavaScript Lead Developer
Re: [editing] CommandQuery Object and Event
On 06/06/2014 13:29 , Piotr Koszuliński wrote: 1. That we need any native UI related to cE at all. We don't. We can display our own toolbars, with our own buttons, with our own icons and implementing our own logic. So the easiest solution to the problem with irrelevant native UI is to not display it at all. 2. That we need any native architecture for commands. We don't. What a command is? It's a name, function and a state+value refreshed on selection change. A command repository can be implemented in JavaScript in few lines of code. CKEditor has one (and I guess that all advanced editors have), because it is a necessary component on which we must have full control. What it does, when it does, how a command is executed, what arguments it accepts, which commands are available for specific editor instance, etc. FWIW I completely agree with Piotr. We need to be thinking about primitives that are as low-level as possible. We don't need to have any built-in support for things like bolding. If it somehow turns out that farther down the line there is a common set of commands that might somehow benefit from getting the native treatment we should cross that bridge then, but the v1 of this project should IMHO really, really not do more than what's needed for a script to cleanly implement an arbitrary text editor. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [editing] CommandQuery Object and Event
On Jun 6, 2014, at 7:30 AM, Robin Berjon ro...@w3.org wrote: On 06/06/2014 13:29 , Piotr Koszuliński wrote: 1. That we need any native UI related to cE at all. We don't. We can display our own toolbars, with our own buttons, with our own icons and implementing our own logic. So the easiest solution to the problem with irrelevant native UI is to not display it at all. 2. That we need any native architecture for commands. We don't. What a command is? It's a name, function and a state+value refreshed on selection change. A command repository can be implemented in JavaScript in few lines of code. CKEditor has one (and I guess that all advanced editors have), because it is a necessary component on which we must have full control. What it does, when it does, how a command is executed, what arguments it accepts, which commands are available for specific editor instance, etc. FWIW I completely agree with Piotr. We need to be thinking about primitives that are as low-level as possible. We don't need to have any built-in support for things like bolding. It's not a question of whether we need it or not. Browsers already DO have menu items to do it, and many users rely on that menu item working. If it somehow turns out that farther down the line there is a common set of commands that might somehow benefit from getting the native treatment we should cross that bridge then, but the v1 of this project should IMHO really, really not do more than what's needed for a script to cleanly implement an arbitrary text editor. Things like undo, redo, paste, delete, select all, and add link in desktop Safari's edit menu, for example, need to work with whatever web app being developed. It's not sufficient to provide UI within the web page. - R. Niwa
Re: [editing] CommandQuery Object and Event
On Jun 6, 2014, at 4:29 AM, Piotr Koszuliński p.koszulin...@cksource.com wrote: 1. That we need any native UI related to cE at all. We don't. We can display our own toolbars, with our own buttons, with our own icons and implementing our own logic. So the easiest solution to the problem with irrelevant native UI is to not display it at all. You may not need native UI working at all in your app, but that doesn't mean all other developers don't want it at all. Furthermore, enabled-ness of items in desktop browser's edit menu should reflect the current state of the editor; otherwise, it would degrade the user experience. Furthermore, we shouldn't design our API only for existing platforms. We need to make it so that new, completely different paradigm of UIs and devices could be built using new API we design. Another important use case for browsers to know the state of the editor is for accessibility. AT may, for example, want to enumerate the list of commands available on the page for the user. 2. That we need any native architecture for commands. We don't. What a command is? It's a name, function and a state+value refreshed on selection change. A command repository can be implemented in JavaScript in few lines of code. CKEditor has one (and I guess that all advanced editors have), because it is a necessary component on which we must have full control. What it does, when it does, how a command is executed, what arguments it accepts, which commands are available for specific editor instance, etc. Providing default editing behavior may not be desirable for that reason. However, it would be still of connivence to provide some helper functions to do the work automatically when the author opts-in so that he/she doesn't have to write every single editing logic himself/herself. - R. Niwa
Re: [editing] CommandQuery Object and Event
Can this be an attribute on elements instead? Otherwise, browsers would have
to repeatedly call these functions to update edit menu, etc...
Also, we should talk with people working on Indie UI
(http://www.w3.org/WAI/IndieUI/). The problem we're solving here is very
similar to the one they're trying to solve.
On Jun 4, 2014, at 11:31 AM, Ben Peters ben.pet...@microsoft.com wrote:
There has been some conversation about browser UI for Commands with
ContentEdtiable=minimal. Some people seem to believe that UI should not be
displayed because it may not be relevant. One way to solve this is to have an
event that would allow script to tell the browser what is relevant. Today,
there are several ways to ask the browser if a given command is
enabled/relevant. This includes queryCommandEnabled, queryCommandSupported,
and QueryCommandValue. However, the site is not able to influence the return
value of these events. In order to give more power to browsers, frameworks,
and sites, it seems to make sense to allow these values to be modified.
Therefore I propose a new method:
document.queryCommand(commandName)
which returns a new read-only object (called CommandQuery for now):
CommandQuery
{
Boolean isSupportedByUA;
Boolean isSupported;
Boolean isEnabled;
Object currentValue;
}
By default, this object will match the browser's support for this command in
the current context. However, before it returns, a CommandQuery event will
fire with a read/write CommandQuery object. If a framework or site wishes to
indicate different values for the command state, it can do so in that event.
CommandQueryEvent: Event {
{
CommandQuery commandQuery;
}
In this way, a framework can enable commands that a browser does not natively
support. Further, a browser could fire CommandQueryEvents to determine the
correct toolbar buttons to display. Thoughts?
Ben
RE: [editing] CommandQuery Object and Event
From: Ryosuke Niwa [mailto:rn...@apple.com]
Can this be an attribute on elements instead? Otherwise, browsers would
have to repeatedly call these functions to update edit menu, etc...
This may be an issue, I agree. But since it's dynamic and changes every time
the selection/caret moves, would an attribute really help us save computation?
Maybe we should be able to get the status of several commands at once with the
event? Something like this (just thinking out loud here)?
Document.queryCommands('bold', 'italic', 'underline', 'undo')
Also, we should talk with people working on Indie UI
(http://www.w3.org/WAI/IndieUI/). The problem we're solving here is very
similar to the one they're trying to solve.
Absolutely! This has been in the back of my mind for a while. Do you know what
would be the best way to involve them? Are some of them in both working groups?
Re: [editing] CommandQuery Object and Event
On 6/5/14 1:42 PM, Ben Peters wrote:
From: Ryosuke Niwa [mailto:rn...@apple.com]
Can this be an attribute on elements instead? Otherwise, browsers would
have to repeatedly call these functions to update edit menu, etc...
This may be an issue, I agree. But since it's dynamic and changes every time
the selection/caret moves, would an attribute really help us save computation?
Maybe we should be able to get the status of several commands at once with the
event? Something like this (just thinking out loud here)?
Document.queryCommands('bold', 'italic', 'underline', 'undo')
Also, we should talk with people working on Indie UI
(http://www.w3.org/WAI/IndieUI/). The problem we're solving here is very
similar to the one they're trying to solve.
Absolutely! This has been in the back of my mind for a while. Do you know what
would be the best way to involve them? Are some of them in both working groups?
Based on a quick scan of the IndieUI WG participant list ([IndieUI]), it
appears Ted and James Craig would be the best suspects. That group's
mail list is http://lists.w3.org/Archives/Public/public-indie-ui/
(FYI, WebApps did a little bit of informal joint work with James in the
TPAC 2013 timeframe.)
-AB
[IndieUI] https://www.w3.org/2000/09/dbwg/details?group=54953
Re: [editing] CommandQuery Object and Event
On Jun 5, 2014, at 10:42 AM, Ben Peters ben.pet...@microsoft.com wrote: From: Ryosuke Niwa [mailto:rn...@apple.com] Can this be an attribute on elements instead? Otherwise, browsers would have to repeatedly call these functions to update edit menu, etc... This may be an issue, I agree. But since it's dynamic and changes every time the selection/caret moves, would an attribute really help us save computation? Maybe we should be able to get the status of several commands at once with the event? Something like this (just thinking out loud here)? We should avoid running JS to update the browser UI since that will make the timing of events dispatch dependent on specific implementations. I'm fine with adding some interface objects that needs to be called upon selection change, etc... If keep updating the states is a concern, we can expose a list of states that UA care about somewhere so that the scripts can avoid updating other states - R. Niwa
