Re: Editing with native UI
On Tue, Jul 1, 2014 at 1:19 AM, Ryosuke Niwa rn...@apple.com wrote: On Jun 24, 2014, at 3:44 AM, Robin Berjon ro...@w3.org wrote: Second, it doesn't address the point made below about native UI exposing a likely non-natural subset of the commands I wish to support. That presumes an opt-out mechanism to enable native UI. If we had used opt-in instead, then we wouldn't have this issue. I think that it may happen in both cases. Developer won't know if on platform X there's native UI for all commands that he/she wants to enable. Mobile Safari displays numbered and bulleted lists buttons, but browser Y may support only bold, italic and underline and in such case content created on Safari will not be fully editable on browser Y. That's why I can't imagine using native UI for more than a really simplest use cases (e.g. comments on blog). But if native UI will stay, opt-in mechanism is definitely the way to go. There is a list of problems with the current editing API: - Undo/redo menu doesn't get enabled/disabled in accordance with the app's intrernal undo stack. Yes. It would be great if native undo/redo options were controllable. I'm also hesitating whether cut and paste options should not be controllable. That would give us similar control as we have over drag and drop. BTW. It struck me recently that we're writing here about disabling commands in order to remove them from native UI. But enabling/disabling command is something different than removing (hiding/showing) option from native toolbar or context menu. For example - I may decide that inline styling (i.e. bold, italic) should not be available in my editor. There's no point in having them in the toolbar, so I want to remove them. On the other hand, my app has an internal undo stack, so if it's empty I want to disable undo and redo buttons. I don't want to hide them. I just want to change their state. Similarly, different rules regarding what content is allowed may apply in editable areas within one editor (having one toolbar). This is a very popular scenario in CKEditor (see e.g. how toolbar behaves when moving selection from main editing area to image's caption in [1]). In such case I want to be able to disable some commands without hiding them, because that's less confusing for users. Therefore, I believe that we need two methods - one to control commands' states and one to enable/disable features (meaning - showing/hiding). Also, a feature isn't necessarily the same as command. We may have different set of features that can be enabled and commands which states are controllable. [1] http://cdn.ckeditor.com/4.4.2/standard-all/samples/plugins/image2/image2.html -- Piotrek Koszuliński CKEditor JavaScript Lead Developer
Re: Editing with native UI
On Jun 24, 2014, at 3:44 AM, Robin Berjon ro...@w3.org wrote: On 24/06/2014 00:38 , Ben Peters wrote: Also, if the browser includes a bold command by default and I don't support bolding and therefore cancel the event, the user who has been relying on the native UI is getting the worst possible experience: native controls that do nothing at all. This doesn't seem like an insurmountable problem. We can provide a way for sites to indicate that they support certain commands and not others, similar to queryCommandEnabled(), which has a return value that could be modified by javascript (perhaps by an event, say QueryCommandEvent). Then the browser could choose not to show buttons for commands that are disabled. Yes, this is possible, but I see problems with it. First, it has to be white-list based. An option to just disable things would not be resilient in the face of browser vendors adding stuff. Second, it doesn't address the point made below about native UI exposing a likely non-natural subset of the commands I wish to support. That presumes an opt-out mechanism to enable native UI. If we had used opt-in instead, then we wouldn't have this issue. Third, I sense the sort of list that tends to acquire proprietary extensions over time (apple-touch-your-nose, ms-insert-clippy-wisdom, etc.) that leads developers to have to keep adding new values if they want a half-sane native UI that matches their usage (for reference, see the current favicon mess). On the contrary, white-listing a list of editing command that an editor supports UA to disable menu items corresponding for those supported editing actions. This is crural for not confusing end users. Finally, it feels an architecturally bad idea to require developers to specify the same information more than once. If my own toolbar has bold and italic, and I tell the browser that I want its native UI to expose bold and italic, then go ahead and add underlining to my toolbar I can easily forget to also tell the UA (granted, libraries can paper over that, but it becomes a tools-will-save-us situation). Building on top of the infrastructure that HTML is providing to define menus and commands, we can get something that is: • White-list based; • Has the exact set of commands I wish to expose; • Does not lend itself to proprietary drift; • Is specified once. Note that if what HTML 5.1 is currently doing in this area isn't good enough, we can (and should) definitely improve it. Right now it's not, to the best of my knowledge, implemented broadly enough that we can't change it. There is a list of problems with the current editing API: Undo/redo menu doesn't get enabled/disabled in accordance with the app's intrernal undo stack. - R. Niwa
Re: Editing with native UI
On Jun 30, 2014, at 4:19 PM, Ryosuke Niwa rn...@apple.com wrote: On Jun 24, 2014, at 3:44 AM, Robin Berjon ro...@w3.org wrote: On 24/06/2014 00:38 , Ben Peters wrote: Also, if the browser includes a bold command by default and I don't support bolding and therefore cancel the event, the user who has been relying on the native UI is getting the worst possible experience: native controls that do nothing at all. This doesn't seem like an insurmountable problem. We can provide a way for sites to indicate that they support certain commands and not others, similar to queryCommandEnabled(), which has a return value that could be modified by javascript (perhaps by an event, say QueryCommandEvent). Then the browser could choose not to show buttons for commands that are disabled. Yes, this is possible, but I see problems with it. First, it has to be white-list based. An option to just disable things would not be resilient in the face of browser vendors adding stuff. Second, it doesn't address the point made below about native UI exposing a likely non-natural subset of the commands I wish to support. That presumes an opt-out mechanism to enable native UI. If we had used opt-in instead, then we wouldn't have this issue. Third, I sense the sort of list that tends to acquire proprietary extensions over time (apple-touch-your-nose, ms-insert-clippy-wisdom, etc.) that leads developers to have to keep adding new values if they want a half-sane native UI that matches their usage (for reference, see the current favicon mess). On the contrary, white-listing a list of editing command that an editor supports allowss UA to disable menu items corresponding for those supported editing actions. This is crural for not confusing end users. Finally, it feels an architecturally bad idea to require developers to specify the same information more than once. If my own toolbar has bold and italic, and I tell the browser that I want its native UI to expose bold and italic, then go ahead and add underlining to my toolbar I can easily forget to also tell the UA (granted, libraries can paper over that, but it becomes a tools-will-save-us situation). Building on top of the infrastructure that HTML is providing to define menus and commands, we can get something that is: • White-list based; • Has the exact set of commands I wish to expose; • Does not lend itself to proprietary drift; • Is specified once. Note that if what HTML 5.1 is currently doing in this area isn't good enough, we can (and should) definitely improve it. Right now it's not, to the best of my knowledge, implemented broadly enough that we can't change it. There is a list of problems with the current editing API: Undo/redo menu doesn't get enabled/disabled in accordance with the app's intrernal undo stack. - R. Niwa
Re: Editing with native UI
On 24/06/2014 00:38 , Ben Peters wrote: Also, if the browser includes a bold command by default and I don't support bolding and therefore cancel the event, the user who has been relying on the native UI is getting the worst possible experience: native controls that do nothing at all. This doesn't seem like an insurmountable problem. We can provide a way for sites to indicate that they support certain commands and not others, similar to queryCommandEnabled(), which has a return value that could be modified by javascript (perhaps by an event, say QueryCommandEvent). Then the browser could choose not to show buttons for commands that are disabled. Yes, this is possible, but I see problems with it. First, it has to be white-list based. An option to just disable things would not be resilient in the face of browser vendors adding stuff. Second, it doesn't address the point made below about native UI exposing a likely non-natural subset of the commands I wish to support. Third, I sense the sort of list that tends to acquire proprietary extensions over time (apple-touch-your-nose, ms-insert-clippy-wisdom, etc.) that leads developers to have to keep adding new values if they want a half-sane native UI that matches their usage (for reference, see the current favicon mess). Finally, it feels an architecturally bad idea to require developers to specify the same information more than once. If my own toolbar has bold and italic, and I tell the browser that I want its native UI to expose bold and italic, then go ahead and add underlining to my toolbar I can easily forget to also tell the UA (granted, libraries can paper over that, but it becomes a tools-will-save-us situation). Building on top of the infrastructure that HTML is providing to define menus and commands, we can get something that is: • White-list based; • Has the exact set of commands I wish to expose; • Does not lend itself to proprietary drift; • Is specified once. Note that if what HTML 5.1 is currently doing in this area isn't good enough, we can (and should) definitely improve it. Right now it's not, to the best of my knowledge, implemented broadly enough that we can't change it. Conversely, if I support something that the native UI does not expose (say, superscripting) it makes for a weird UI in which some things are exposed and others aren't. Good point. -- Robin Berjon - http://berjon.com/ - @robinberjon
Editing with native UI (was: [editing] CommandQuery Object and Event)
On 06/06/2014 18:39 , Ryosuke Niwa 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. All of these are good points, but the fact remains that if a browser unilaterally decides to exposes a new editing behaviour that I as author don't know about, it could very easily break my script. Also, if the browser includes a bold command by default and I don't support bolding and therefore cancel the event, the user who has been relying on the native UI is getting the worst possible experience: native controls that do nothing at all. Conversely, if I support something that the native UI does not expose (say, superscripting) it makes for a weird UI in which some things are exposed and others aren't. There is an option that: • Can be styled in the page according to author wishes. • Can interact with native controls. • Can integrate with accessibility. It relies on using all bits of new stuff in HTML: commands, contextMenu, and friends. I would *strongly* suggest that contentEditable=minimal would *only* have native UI based on things specified with this and not anything else by default. Native UI atop custom editing is really a solution for breakage. We can also make it smart and able to tap into higher-level intention events such as knowing the platform's localised shortcut for a given action. -- Robin Berjon - http://berjon.com/ - @robinberjon
RE: Editing with native UI (was: [editing] CommandQuery Object and Event)
From: Robin Berjon [mailto:ro...@w3.org] On 06/06/2014 18:39 , Ryosuke Niwa 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. All of these are good points, but the fact remains that if a browser unilaterally decides to exposes a new editing behaviour that I as author don't know about, it could very easily break my script. Also, if the browser includes a bold command by default and I don't support bolding and therefore cancel the event, the user who has been relying on the native UI is getting the worst possible experience: native controls that do nothing at all. This doesn't seem like an insurmountable problem. We can provide a way for sites to indicate that they support certain commands and not others, similar to queryCommandEnabled(), which has a return value that could be modified by javascript (perhaps by an event, say QueryCommandEvent). Then the browser could choose not to show buttons for commands that are disabled. Conversely, if I support something that the native UI does not expose (say, superscripting) it makes for a weird UI in which some things are exposed and others aren't. Good point. There is an option that: • Can be styled in the page according to author wishes. • Can interact with native controls. • Can integrate with accessibility. It relies on using all bits of new stuff in HTML: commands, contextMenu, and friends. I would *strongly* suggest that contentEditable=minimal would *only* have native UI based on things specified with this and not anything else by default. Native UI atop custom editing is really a solution for breakage. We can also make it smart and able to tap into higher-level intention events such as knowing the platform's localised shortcut for a given action. -- Robin Berjon - http://berjon.com/ - @robinberjon
