Re: [editing] Leading with ContentEditable=Minimal
On 30/06/2014 07:22 , Johannes Wilm wrote: Another use case: Create a track changes function within an editor (like https://github.com/NYTimes/ice ) that really should be run MVC in order to keep the code somewhat readable. Currently ICE breaks whenever any of the browser makers decide to change anything about contenteditable. Oh yeah, anything involving tracking, OT, or whatever temporal really, really can't use the markup as its model. I'm surprised ICE went that way, it must be terribly painful. -- Robin Berjon - http://berjon.com/ - @robinberjon
usecases Re: [editing] Leading with ContentEditable=Minimal
On Mon, 30 Jun 2014 10:54:36 +0300, Robin Berjon ro...@w3.org wrote: On 30/06/2014 07:22 , Johannes Wilm wrote: Another use case: Create a track changes function within an editor (like https://github.com/NYTimes/ice ) that really should be run MVC in order to keep the code somewhat readable. Currently ICE breaks whenever any of the browser makers decide to change anything about contenteditable. Oh yeah, anything involving tracking, OT, or whatever temporal really, really can't use the markup as its model. I'm surprised ICE went that way, it must be terribly painful. Create an extension that substitutes an editor adapted to the user's needs for a default editing setup in an application. -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [editing] Leading with ContentEditable=Minimal
On Jun 29, 2014, at 10:22 PM, Johannes Wilm johan...@fiduswriter.org wrote: Another use case: Create a track changes function within an editor (like https://github.com/NYTimes/ice ) that really should be run MVC in order to keep the code somewhat readable. Currently ICE breaks whenever any of the browser makers decide to change anything about contenteditable. This is a great concrete use case. On Jun 26, 2014, at 3:24 PM, Olivier F teleclim...@gmail.com wrote: On Thu, Jun 26, 2014 at 3:51 AM, Robin Berjon ro...@w3.org wrote: On 24/06/2014 20:09 , Ben Peters wrote: Problems: * ContentEditable is too complex and buggy to be usable as-is * ContentEditable does not easily enable the wide range of editing scenarios Complex and buggy aren't necessarily show-stoppers. With hard work it should be possible to take the current Editing APIs draft and progressively iron out most of the kinks. It's difficult, but difficult things have been done before. The main problem here is that even if we did that we still wouldn't have a usable system. And I would say that the issue isn't so much that it doesn't enable scenarios more than that it works actively hard to make them hard to implement :) Maybe this can be captured as Does not support http://extensiblewebmanifesto.org/;. I agree with this. The problem is not complexity. I don't expect implementing a well-appointed custom content editor will be anything but complex. The problem is that contenteditable=true is a high-level API which by definition has to assume a lot and do a lot. This prevents custom behavior from being implemented without clashing with the helpful high level behavior that the UA is expected to do. Our goal should be to provide a set of low-level building blocks for text/content editing. I think that with cursor=true, and commandEvents, and improved Selection API we're headed in the right direction. I don't think we can set a goal without first enumerating use cases and the problem we're trying to solve. Use Cases: * Create a js framework that enables a WYSIWYG editor and works the same in all browsers with little browser-specific code This one is a bit vague as a use case. Are you thinking of a WYSIWYG editor you see on CMS or a blog editor? Or does it include something like EitherPad? I think we need to be much more concrete. * Use a js framework to insert a customized editor into an email client * Use a js framework to insert a customized editor into a blog * Use a js framework to insert a customized editor into a wiki Aren't those the same as the previous one? I agree these all seem the same. Here are a few other use cases I can think of: * Create a web-based structured content editor, where the allowable DOM elements and/or classes in the content are pre-defined. Could you elaborate on the use case of making such an editor? e.g. allowing only certain types of styling in comments. * A complete book/whatever editor, which can contain areas of non-editable content, nested editable content, etc... See fiduswriter.org, and what CKEditor are doing with widgets. Could you elaborate on how non-editable content appears/used inside an editable content? * Browser-based code editor. Currently CodeMirror and others go through amazing lengths to provide something that looks and behaves like a desktop code editor. * Browser based word art generator where end-user types some text and it renders in 3D along a curve and in rainbow colors on a canvas. These are great use cases. I'd throw in two more: Web-based DTP application: The app can creates a document that contains pagination, columns, and a complex illustrations. It needs to let users edit any text that appears in the document. Each editable text needs to be accessible, and styles applied to text need to be backed by the application's internal model of the document. Semantic HTML WYSIWYG editor for a blogging platform: The editor needs to able to add both semantic and visual annotation to the document as it will be published as a blog. Headings are to be marked up with h1. h2, etc... and each acronyms, abbreviations, and so forth are marked up with respective HTML elements. However, the editor also supports visual annotations such as bolding, italicizing, and enlarging text, each of which will be interpreted by the editor to respective underlying semantics in HTML. I picked these examples because they illustrate why separate building blocks are the right way to go. I would expect the developer of the structured content editor to leverage cursor=true, commandEvents and Selections API, and if it's available some sort of text insert mechanism. In contrast the word art developer would only leverage commandEvents and will have to draw their own cursor and selections along with their fancy curved 3D text. Thanks for a great list of use cases. Now we need a required set of
Re: [editing] Leading with ContentEditable=Minimal
On Mon, Jun 30, 2014 at 10:01 PM, Ryosuke Niwa rn...@apple.com wrote: snip On Jun 26, 2014, at 3:24 PM, Olivier F teleclim...@gmail.com wrote: snip I agree these all seem the same. Here are a few other use cases I can think of: * Create a web-based structured content editor, where the allowable DOM elements and/or classes in the content are pre-defined. Could you elaborate on the use case of making such an editor? e.g. allowing only certain types of styling in comments. We do that in Fidus Writer. Part of the point is to keep the structure of the document semantically defined. Users can't change font sizes of individual words, etc. . This is because one of the main tasks of scientific journal editors who currently receive drafts in Word or Libreoffice format have to undo all the manual styling the writers have added in order to get everything to look in a similar way. we simply take those styling possibilities away so that we can define the entire design through one stylesheet as well as easily convert to other formats, such as LaTex or an Epub, and be sure that we cover all formatting tags that were used. * A complete book/whatever editor, which can contain areas of non-editable content, nested editable content, etc... See fiduswriter.org, and what CKEditor are doing with widgets. Could you elaborate on how non-editable content appears/used inside an editable content? We also do that - for example in the case of formulas. Generally the text is editable near-Wysiwyg style. But when it comes to formulas, we let the user enter them in Latex format and display the result using mathjax. Each formula object within the text is a noneditable island. If the user clicks on it with the mouse, he can change the formula. Another example are figures: We want them to always be block elements and to have exactly one caption without styling. They are therefore non-editable isalnds and if the user clicks on them he can change the figure's display and the caption text. * Browser-based code editor. Currently CodeMirror and others go through amazing lengths to provide something that looks and behaves like a desktop code editor. * Browser based word art generator where end-user types some text and it renders in 3D along a curve and in rainbow colors on a canvas. These are great use cases. I'd throw in two more: - Web-based DTP application: The app can creates a document that contains pagination, columns, and a complex illustrations. It needs to let users edit any text that appears in the document. Each editable text needs to be accessible, and styles applied to text need to be backed by the application's internal model of the document. Yes, but wouldn't this require some fragmentation logic? To create something like what Quark Xpress was in the 1990s, I think you'd need CSS Regions or equivalent. It seems as if that would be a little outside of the scope of the caret moving logic, or how do you mean? I would find it great if this ever happens, but as I understand it the whole fragmentation debate was left aside for a while. - Semantic HTML WYSIWYG editor for a blogging platform: The editor needs to able to add both semantic and visual annotation to the document as it will be published as a blog. Headings are to be marked up with h1. h2, etc... and each acronyms, abbreviations, and so forth are marked up with respective HTML elements. However, the editor also supports visual annotations such as bolding, italicizing, and enlarging text, each of which will be interpreted by the editor to respective underlying semantics in HTML. Yes, and in order to keep things consistent he may want to disallow certain types of styling. A few years ago it was common to see people with Joomla sites who just pasted the text into the editor after copying it from a word processor. Each blog post therefore ended up having very different styling. I picked these examples because they illustrate why separate building blocks are the right way to go. I would expect the developer of the structured content editor to leverage cursor=true, commandEvents and Selections API, and if it's available some sort of text insert mechanism. In contrast the word art developer would only leverage commandEvents and will have to draw their own cursor and selections along with their fancy curved 3D text. Thanks for a great list of use cases. Now we need a required set of features/API for each use case. We can then evaluate whether what has been discussed thus far satisfy enough use cases or not. - R. Niwa -- Johannes Wilm Fidus Writer http://www.fiduswriter.o http://www.fiduswriter.com/rg
Re: [editing] Leading with ContentEditable=Minimal
On Jun 30, 2014, at 1:43 PM, Johannes Wilm johan...@fiduswriter.org wrote: On Mon, Jun 30, 2014 at 10:01 PM, Ryosuke Niwa rn...@apple.com wrote: snip On Jun 26, 2014, at 3:24 PM, Olivier F teleclim...@gmail.com wrote: snip I agree these all seem the same. Here are a few other use cases I can think of: * Create a web-based structured content editor, where the allowable DOM elements and/or classes in the content are pre-defined. Could you elaborate on the use case of making such an editor? e.g. allowing only certain types of styling in comments. We do that in Fidus Writer. Part of the point is to keep the structure of the document semantically defined. Users can't change font sizes of individual words, etc. . This is because one of the main tasks of scientific journal editors who currently receive drafts in Word or Libreoffice format have to undo all the manual styling the writers have added in order to get everything to look in a similar way. we simply take those styling possibilities away so that we can define the entire design through one stylesheet as well as easily convert to other formats, such as LaTex or an Epub, and be sure that we cover all formatting tags that were used. Interesting. That's a very good use case indeed. * A complete book/whatever editor, which can contain areas of non-editable content, nested editable content, etc... See fiduswriter.org, and what CKEditor are doing with widgets. Could you elaborate on how non-editable content appears/used inside an editable content? We also do that - for example in the case of formulas. Generally the text is editable near-Wysiwyg style. But when it comes to formulas, we let the user enter them in Latex format and display the result using mathjax. Each formula object within the text is a noneditable island. If the user clicks on it with the mouse, he can change the formula. Another example are figures: We want them to always be block elements and to have exactly one caption without styling. They are therefore non-editable islands and if the user clicks on them he can change the figure's display and the caption text. Ditto. * Browser-based code editor. Currently CodeMirror and others go through amazing lengths to provide something that looks and behaves like a desktop code editor. * Browser based word art generator where end-user types some text and it renders in 3D along a curve and in rainbow colors on a canvas. These are great use cases. I'd throw in two more: Web-based DTP application: The app can creates a document that contains pagination, columns, and a complex illustrations. It needs to let users edit any text that appears in the document. Each editable text needs to be accessible, and styles applied to text need to be backed by the application's internal model of the document. Yes, but wouldn't this require some fragmentation logic? To create something like what Quark Xpress was in the 1990s, I think you'd need CSS Regions or equivalent. It seems as if that would be a little outside of the scope of the caret moving logic, or how do you mean? I would find it great if this ever happens, but as I understand it the whole fragmentation debate was left aside for a while. CSS regions is still shipped in iOS/OS X Safari, and I don't expect it to go away anytime soon. CSS columns support is still in Blink as well. Furthermore, I don't think CSS WG is halting the work on fragmentations either. We should still keep it as a use case for the new editing API. In addition, I would suggest that you go talk with people in CSS WG and add your use case. Semantic HTML WYSIWYG editor for a blogging platform: The editor needs to able to add both semantic and visual annotation to the document as it will be published as a blog. Headings are to be marked up with h1. h2, etc... and each acronyms, abbreviations, and so forth are marked up with respective HTML elements. However, the editor also supports visual annotations such as bolding, italicizing, and enlarging text, each of which will be interpreted by the editor to respective underlying semantics in HTML. Yes, and in order to keep things consistent he may want to disallow certain types of styling. A few years ago it was common to see people with Joomla sites who just pasted the text into the editor after copying it from a word processor. Each blog post therefore ended up having very different styling. Could you elaborate more on what kind of inline styling you're thinking of? And how and why you want to allow/restrict certain styles? You're providing us of really important information here, and I really appreciate if you could give us more information here :) - R. Niwa
Re: [editing] Leading with ContentEditable=Minimal
On Tue, Jul 1, 2014 at 4:39 AM, Ryosuke Niwa rn...@apple.com wrote: On Jun 30, 2014, at 1:43 PM, Johannes Wilm johan...@fiduswriter.org wrote: On Mon, Jun 30, 2014 at 10:01 PM, Ryosuke Niwa rn...@apple.com wrote: snip - Web-based DTP application: The app can creates a document that contains pagination, columns, and a complex illustrations. It needs to let users edit any text that appears in the document. Each editable text needs to be accessible, and styles applied to text need to be backed by the application's internal model of the document. Yes, but wouldn't this require some fragmentation logic? To create something like what Quark Xpress was in the 1990s, I think you'd need CSS Regions or equivalent. It seems as if that would be a little outside of the scope of the caret moving logic, or how do you mean? I would find it great if this ever happens, but as I understand it the whole fragmentation debate was left aside for a while. CSS regions is still shipped in iOS/OS X Safari, and I don't expect it to go away anytime soon. CSS columns support is still in Blink as well. Furthermore, I don't think CSS WG is halting the work on fragmentations either. We should still keep it as a use case for the new editing API. In addition, I would suggest that you go talk with people in CSS WG and add your use case. Yes, I am aware of that. I spent a year creating a CSS Regions based book layout engine ( http://fiduswriter.github.io/pagination.js/ ) , so I am absolutely interested in fragmentation coming back one day. In the meantime I have created an ad-hoc solution using CSS columns ( http://fiduswriter.github.io/simplePagination.js/simplePagination.html ) The main difference is that the CSS fragmentation based version allows to combine it with contenteditable (text flowing from page to page while editing/writing it). Using Javascript/CSS multicolumns to create the same design means cutting up the DOM, so it has to be done after the text is written. We switched to this second approach when it became clear that CSS Regions would be removed from Chrome. The way we handle it is to let the user write the text in one large page with the footnotes off to the right. When the user hits CTRL+P, the current contents of the edited doc are copied, the original contents is hidden and the copied version is cut up into individual pages. By the time the user gets to the print preview, page numbers, headers, table of contents, footnotes, etc. have all been put in place. Fragmentation would be great to have, but for now I would already sleep much better if we would have a more solid selection/caret-moving base to build upon. - Semantic HTML WYSIWYG editor for a blogging platform: The editor needs to able to add both semantic and visual annotation to the document as it will be published as a blog. Headings are to be marked up with h1. h2, etc... and each acronyms, abbreviations, and so forth are marked up with respective HTML elements. However, the editor also supports visual annotations such as bolding, italicizing, and enlarging text, each of which will be interpreted by the editor to respective underlying semantics in HTML. Yes, and in order to keep things consistent he may want to disallow certain types of styling. A few years ago it was common to see people with Joomla sites who just pasted the text into the editor after copying it from a word processor. Each blog post therefore ended up having very different styling. Could you elaborate more on what kind of inline styling you're thinking of? And how and why you want to allow/restrict certain styles? You're providing us of really important information here, and I really appreciate if you could give us more information here :) For example a blog may decide not to allow any inline-css styling. And to emphasize words they may only want to allow bold and italics, but not underline and not a combination of italics and bold on the same word. Of course visually this may be achievable using a lot of !important statements in a general css file for the page. But the contents will turn messy and if users copy from a social media site to a word processor to a blog, and from there to another blog and then into their html-based email and then into another blog... things will end in disaster for certain at some point. -- Johannes Wilm Fidus Writer http://www.fiduswriter.org
Re: [editing] Leading with ContentEditable=Minimal
Another use case: Create a track changes function within an editor (like https://github.com/NYTimes/ice ) that really should be run MVC in order to keep the code somewhat readable. Currently ICE breaks whenever any of the browser makers decide to change anything about contenteditable. On Fri, Jun 27, 2014 at 12:24 AM, Olivier F teleclim...@gmail.com wrote: On Thu, Jun 26, 2014 at 3:51 AM, Robin Berjon ro...@w3.org wrote: On 24/06/2014 20:09 , Ben Peters wrote: Problems: * ContentEditable is too complex and buggy to be usable as-is * ContentEditable does not easily enable the wide range of editing scenarios Complex and buggy aren't necessarily show-stoppers. With hard work it should be possible to take the current Editing APIs draft and progressively iron out most of the kinks. It's difficult, but difficult things have been done before. The main problem here is that even if we did that we still wouldn't have a usable system. And I would say that the issue isn't so much that it doesn't enable scenarios more than that it works actively hard to make them hard to implement :) Maybe this can be captured as Does not support http://extensiblewebmanifesto.org/;. I agree with this. The problem is not complexity. I don't expect implementing a well-appointed custom content editor will be anything but complex. The problem is that contenteditable=true is a high-level API which by definition has to assume a lot and do a lot. This prevents custom behavior from being implemented without clashing with the helpful high level behavior that the UA is expected to do. Our goal should be to provide a set of low-level building blocks for text/content editing. I think that with cursor=true, and commandEvents, and improved Selection API we're headed in the right direction. Use Cases: * Create a js framework that enables a WYSIWYG editor and works the same in all browsers with little browser-specific code s/little/no/ ;-) * Use a js framework to insert a customized editor into an email client * Use a js framework to insert a customized editor into a blog * Use a js framework to insert a customized editor into a wiki Aren't those the same as the previous one? I agree these all seem the same. Here are a few other use cases I can think of: * Create a web-based structured content editor, where the allowable DOM elements and/or classes in the content are pre-defined. * A complete book/whatever editor, which can contain areas of non-editable content, nested editable content, etc... See fiduswriter.org, and what CKEditor are doing with widgets. * Browser-based code editor. Currently CodeMirror and others go through amazing lengths to provide something that looks and behaves like a desktop code editor. * Browser based word art generator where end-user types some text and it renders in 3D along a curve and in rainbow colors on a canvas. I picked these examples because they illustrate why separate building blocks are the right way to go. I would expect the developer of the structured content editor to leverage cursor=true, commandEvents and Selections API, and if it's available some sort of text insert mechanism. In contrast the word art developer would only leverage commandEvents and will have to draw their own cursor and selections along with their fancy curved 3D text. -- Johannes Wilm Fidus Writer http://www.fiduswriter.com
Re: [editing] Leading with ContentEditable=Minimal
On 24/06/2014 20:09 , Ben Peters wrote: Works for me. Should I just scare up a draft? It is likely to be a pretty short spec :) I'm really looking forward to getting things sorted out! But I think we may want to take a step back and make sure we all agree on the problem, goals, and use cases, as Ryosuke has been pushing for. We have several different proposed solutions. Does it make sense to very clearly state all of this before we press on too quickly? Sure, but this is just one of the moving parts we need, and I think it is well established that it is required. The existing contentEditable has many built-in behaviours that cannot be removed by browser vendors without breaking existing deployed code. This includes both native UI and default actions for many events. It's a small spec, it's just what is needed in order to enable the baseline behaviour. The meat is elsewhere :) I was proposing to start putting it together not because it's hard but to get a bit of momentum going. Problems: * ContentEditable is too complex and buggy to be usable as-is * ContentEditable does not easily enable the wide range of editing scenarios Complex and buggy aren't necessarily show-stoppers. With hard work it should be possible to take the current Editing APIs draft and progressively iron out most of the kinks. It's difficult, but difficult things have been done before. The main problem here is that even if we did that we still wouldn't have a usable system. And I would say that the issue isn't so much that it doesn't enable scenarios more than that it works actively hard to make them hard to implement :) Maybe this can be captured as Does not support http://extensiblewebmanifesto.org/;. Goals: * Make it easy to disable browser behavior in editing scenarios I don't think that we should make it easy to disable behaviour; behaviour should be minimal and well-contained by default. Put differently, maybe this should be Editing behaviour should be opt-in rather than opt-out? * Enumerate available actions in a given context before and after javascript adds/modifies behavior I'm not sure I understand what that is? Use Cases: * Create a js framework that enables a WYSIWYG editor and works the same in all browsers with little browser-specific code s/little/no/ ;-) * Use a js framework to insert a customized editor into an email client * Use a js framework to insert a customized editor into a blog * Use a js framework to insert a customized editor into a wiki Aren't those the same as the previous one? * Create a document editor that uses an HTML editor as a frontend but a different document model as a backend I don't know if we want to mention MVC and other such things? Perhaps just the general sanity of not using your rendering view as your model :) -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [editing] Leading with ContentEditable=Minimal
On Thu, Jun 26, 2014 at 3:51 AM, Robin Berjon ro...@w3.org wrote: On 24/06/2014 20:09 , Ben Peters wrote: Problems: * ContentEditable is too complex and buggy to be usable as-is * ContentEditable does not easily enable the wide range of editing scenarios Complex and buggy aren't necessarily show-stoppers. With hard work it should be possible to take the current Editing APIs draft and progressively iron out most of the kinks. It's difficult, but difficult things have been done before. The main problem here is that even if we did that we still wouldn't have a usable system. And I would say that the issue isn't so much that it doesn't enable scenarios more than that it works actively hard to make them hard to implement :) Maybe this can be captured as Does not support http://extensiblewebmanifesto.org/;. I agree with this. The problem is not complexity. I don't expect implementing a well-appointed custom content editor will be anything but complex. The problem is that contenteditable=true is a high-level API which by definition has to assume a lot and do a lot. This prevents custom behavior from being implemented without clashing with the helpful high level behavior that the UA is expected to do. Our goal should be to provide a set of low-level building blocks for text/content editing. I think that with cursor=true, and commandEvents, and improved Selection API we're headed in the right direction. Use Cases: * Create a js framework that enables a WYSIWYG editor and works the same in all browsers with little browser-specific code s/little/no/ ;-) * Use a js framework to insert a customized editor into an email client * Use a js framework to insert a customized editor into a blog * Use a js framework to insert a customized editor into a wiki Aren't those the same as the previous one? I agree these all seem the same. Here are a few other use cases I can think of: * Create a web-based structured content editor, where the allowable DOM elements and/or classes in the content are pre-defined. * A complete book/whatever editor, which can contain areas of non-editable content, nested editable content, etc... See fiduswriter.org, and what CKEditor are doing with widgets. * Browser-based code editor. Currently CodeMirror and others go through amazing lengths to provide something that looks and behaves like a desktop code editor. * Browser based word art generator where end-user types some text and it renders in 3D along a curve and in rainbow colors on a canvas. I picked these examples because they illustrate why separate building blocks are the right way to go. I would expect the developer of the structured content editor to leverage cursor=true, commandEvents and Selections API, and if it's available some sort of text insert mechanism. In contrast the word art developer would only leverage commandEvents and will have to draw their own cursor and selections along with their fancy curved 3D text.
Re: [editing] Leading with ContentEditable=Minimal
On 23/06/2014 18:25 , Julie Parent wrote: Well stated. I like contentEditable=cursor. Works for me. Should I just scare up a draft? It is likely to be a pretty short spec :) -- Robin Berjon - http://berjon.com/ - @robinberjon
RE: [editing] Leading with ContentEditable=Minimal
-Original Message- On 23/06/2014 18:25 , Julie Parent wrote: Well stated. I like contentEditable=cursor. Works for me. Should I just scare up a draft? It is likely to be a pretty short spec :) I'm really looking forward to getting things sorted out! But I think we may want to take a step back and make sure we all agree on the problem, goals, and use cases, as Ryosuke has been pushing for. We have several different proposed solutions. Does it make sense to very clearly state all of this before we press on too quickly? I'm working on a draft now, and would like input. The list below takes a stab at it, but I'm sure there are others we should add and maybe some we don't need? Problems: * ContentEditable is too complex and buggy to be usable as-is * ContentEditable does not easily enable the wide range of editing scenarios * There are many ways to indicate user intentions and no clean way to understand them all * Accessibility tools have difficulty understanding what actions are available * Frameworks and sites may have difficulty understanding what is implemented, what should show up on toolbars and menus, and what needs to be polyfilled in editing scenarios Goals: * Make it easy to disable browser behavior in editing scenarios * Make it easy to implement custom behavior with appropriate APIs * Allow overwrite of behavior for a user intention from all actions that indicate that intention * Enumerate available actions in a given context before and after javascript adds/modifies behavior Use Cases: * Create a js framework that enables a WYSIWYG editor and works the same in all browsers with little browser-specific code * Use a js framework to insert a customized editor into an email client * Use a js framework to insert a customized editor into a blog * Use a js framework to insert a customized editor into a wiki * Create a document editor that uses an HTML editor as a frontend but a different document model as a backend * Empower complex editors to be accessible by enabling users to understand available behaviors with little accessibility-specific work from the framework or site
Re: [editing] Leading with ContentEditable=Minimal
On 17/06/2014 02:12 , Julie Parent wrote: If Intention events are (temporarily) moved out of scope, I think this leads us back to the question of what would contentEditable='minimal' do exactly? Enable collapsed selections and default handling of cursor movement ... anything else? If this is all it would do, then perhaps what we really want is an explicit API to enable cursors? The way I see it, that is indeed *all* it would do (and serve as a sanity flag so that browsers know how to handle this cleanly). It *is* an explicit API to enable cursors. It has the advantage of reusing an existing name so that we don't have to worry about what happens when you specify both; and it's declarative because that's what you want for such a case (notably so that CSS can style what's editable cleanly). We could rename it contentEditable=cursor if that's cleaner — the idea is the same (and I certainly won't argue bikeshedding :). -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [editing] Leading with ContentEditable=Minimal
Well stated. I like contentEditable=cursor. On Mon, Jun 23, 2014 at 9:21 AM, Robin Berjon ro...@w3.org wrote: On 17/06/2014 02:12 , Julie Parent wrote: If Intention events are (temporarily) moved out of scope, I think this leads us back to the question of what would contentEditable='minimal' do exactly? Enable collapsed selections and default handling of cursor movement ... anything else? If this is all it would do, then perhaps what we really want is an explicit API to enable cursors? The way I see it, that is indeed *all* it would do (and serve as a sanity flag so that browsers know how to handle this cleanly). It *is* an explicit API to enable cursors. It has the advantage of reusing an existing name so that we don't have to worry about what happens when you specify both; and it's declarative because that's what you want for such a case (notably so that CSS can style what's editable cleanly). We could rename it contentEditable=cursor if that's cleaner — the idea is the same (and I certainly won't argue bikeshedding :). -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [editing] Leading with ContentEditable=Minimal
On Jun 22, 2014, at 9:19 PM, Julie Parent jpar...@google.com wrote: On Fri, Jun 20, 2014 at 8:47 PM, Ryosuke Niwa rn...@apple.com wrote: On Jun 17, 2014, at 1:44 PM, Julie Parent jpar...@google.com wrote: On Tue, Jun 17, 2014 at 12:22 PM, Olivier F teleclim...@gmail.com wrote: On Mon, Jun 16, 2014 at 5:48 PM, Julie Parent jpar...@google.com wrote: On Mon, Jun 16, 2014 at 5:23 PM, Ben Peters ben.pet...@microsoft.com wrote: On Mon, Jun 16, 2014 at 5:12 PM, Julie Parent jpar...@google.com wrote: If Intention events are (temporarily) moved out of scope, I don’t think I’d say they’re out of scope, just that they will likely not be ready as quickly as we could do contentEditable=’minimal’. Do you agree with that? Agreed in general, but it would depend on how contentEditable='min' is actually defined. I think this leads us back to the question of what would contentEditable='minimal' do exactly? Enable collapsed selections and default handling of cursor movement ... anything else? Yes we need to define this default functionality. What does everyone think about this? If this is all it would do, then perhaps what we really want is an explicit API to enable cursors? I think we should still think of this as a path to a full story that includes Intention events. Are you saying that ultimately we would have something like this? div cursor=”true” commandEvents=”true”minimally editable content/div Like all other content, this would also get drag/drop, clipboard, and selection events. We would need 3 specs for this- Selection API, minimal editing (cursor-only editing?), and CommandEvent. Yes. I really like the idea of explicitly enabling what you want and of separating the concepts. Being able to turn on commandEvents independent of a cursor seems useful. An API like this leaves far fewer questions of what does it do? than contentEditable=minimal. What does cursor=true do? It turns on the ability for the user or developer to place a cursor, and default movement. It has nothing to do with dom modification. What does commandEvents=true do? It enables dispatching commandEvents. No ambiguity. However, this does make me think again about using beforeinput/input events rather than adding new CommandEvents, since those would include drag/drop and clipboard as well? I really like cursor=true. I'm more confused about commandEvents=true as a separate attribute. - Do CommandEvents make any sense without a cursor? In particular, how does end-user focus an area that has commandEvents=true if there is no cursor? An app can have a cursor that isn't a native browser cursor. For example, Google Docs does not use native browser cursors and draws their own, so that they can show multiple cursors for collaborators and control selections entirely the way they want. They have to use a hidden focused contentEditable region in order to get all the events they need now, but it would be a much nicer solution for them to simply enable the events. How does that work in mobile? iOS for example shows lollipops at the end of selections to trigger editing actions such as copy, paste, etc... if a web content was drawing its own cursor, then these UIs can't be shown for the user. It seems to me that what they want is to use the native cursor and do every editing operation themselves. The sad answer, at least for the Docs case I was referring to, is that they aren't using web content on mobile, they are writing native apps. Your point is still valid, but I think the selection API would need to be significantly extended in order for them to make use of it, rather than doing their own thing. In particular, they want to be able to draw multiple cursors (the primary user selection and those of collaborators) I don't think cursors for collaborators need to be drawn by the UA since users won't be interacting with those directly. and to control the granularity of selection movement throughout different types of rich content, in a better way than you get by just using ce='false' regions inside an editable regions. Could you elaborate on what kind of granularity they need? It would be great to evolve to selection API to encompass these use cases as well, but I think that is outside the scope of this discussion. While we may not immediately satisfy all of their needs, we should still take their use cases into our consideration so that new API will be forward compatible with their use cases if any. - R. Niwa
Re: [editing] Leading with ContentEditable=Minimal
On Fri, Jun 20, 2014 at 8:47 PM, Ryosuke Niwa rn...@apple.com wrote: On Jun 17, 2014, at 1:44 PM, Julie Parent jpar...@google.com wrote: On Tue, Jun 17, 2014 at 12:22 PM, Olivier F teleclim...@gmail.com wrote: On Mon, Jun 16, 2014 at 5:48 PM, Julie Parent jpar...@google.com wrote: On Mon, Jun 16, 2014 at 5:23 PM, Ben Peters ben.pet...@microsoft.com wrote: On Mon, Jun 16, 2014 at 5:12 PM, Julie Parent jpar...@google.com wrote: If Intention events are (temporarily) moved out of scope, I don’t think I’d say they’re out of scope, just that they will likely not be ready as quickly as we could do contentEditable=’minimal’. Do you agree with that? Agreed in general, but it would depend on how contentEditable='min' is actually defined. I think this leads us back to the question of what would contentEditable='minimal' do exactly? Enable collapsed selections and default handling of cursor movement ... anything else? Yes we need to define this default functionality. What does everyone think about this? If this is all it would do, then perhaps what we really want is an explicit API to enable cursors? I think we should still think of this as a path to a full story that includes Intention events. Are you saying that ultimately we would have something like this? div cursor=”true” commandEvents=”true”minimally editable content/div Like all other content, this would also get drag/drop, clipboard, and selection events. We would need 3 specs for this- Selection API, minimal editing (cursor-only editing?), and CommandEvent. Yes. I really like the idea of explicitly enabling what you want and of separating the concepts. Being able to turn on commandEvents independent of a cursor seems useful. An API like this leaves far fewer questions of what does it do? than contentEditable=minimal. What does cursor=true do? It turns on the ability for the user or developer to place a cursor, and default movement. It has nothing to do with dom modification. What does commandEvents=true do? It enables dispatching commandEvents. No ambiguity. However, this does make me think again about using beforeinput/input events rather than adding new CommandEvents, since those would include drag/drop and clipboard as well? I really like cursor=true. I'm more confused about commandEvents=true as a separate attribute. - Do CommandEvents make any sense without a cursor? In particular, how does end-user focus an area that has commandEvents=true if there is no cursor? An app can have a cursor that isn't a native browser cursor. For example, Google Docs does not use native browser cursors and draws their own, so that they can show multiple cursors for collaborators and control selections entirely the way they want. They have to use a hidden focused contentEditable region in order to get all the events they need now, but it would be a much nicer solution for them to simply enable the events. How does that work in mobile? iOS for example shows lollipops at the end of selections to trigger editing actions such as copy, paste, etc... if a web content was drawing its own cursor, then these UIs can't be shown for the user. It seems to me that what they want is to use the native cursor and do every editing operation themselves. The sad answer, at least for the Docs case I was referring to, is that they aren't using web content on mobile, they are writing native apps. Your point is still valid, but I think the selection API would need to be significantly extended in order for them to make use of it, rather than doing their own thing. In particular, they want to be able to draw multiple cursors (the primary user selection and those of collaborators) and to control the granularity of selection movement throughout different types of rich content, in a better way than you get by just using ce='false' regions inside an editable regions. It would be great to evolve to selection API to encompass these use cases as well, but I think that is outside the scope of this discussion. I'm also not certain how we're going to expose an element with cursor=true but commandEvent=false or cursor=false but commandEvent=true to an assistive technology. - R. Niwa
Re: [editing] Leading with ContentEditable=Minimal
On Jun 17, 2014, at 1:44 PM, Julie Parent jpar...@google.com wrote: On Tue, Jun 17, 2014 at 12:22 PM, Olivier F teleclim...@gmail.com wrote: On Mon, Jun 16, 2014 at 5:48 PM, Julie Parent jpar...@google.com wrote: On Mon, Jun 16, 2014 at 5:23 PM, Ben Peters ben.pet...@microsoft.com wrote: On Mon, Jun 16, 2014 at 5:12 PM, Julie Parent jpar...@google.com wrote: If Intention events are (temporarily) moved out of scope, I don’t think I’d say they’re out of scope, just that they will likely not be ready as quickly as we could do contentEditable=’minimal’. Do you agree with that? Agreed in general, but it would depend on how contentEditable='min' is actually defined. I think this leads us back to the question of what would contentEditable='minimal' do exactly? Enable collapsed selections and default handling of cursor movement ... anything else? Yes we need to define this default functionality. What does everyone think about this? If this is all it would do, then perhaps what we really want is an explicit API to enable cursors? I think we should still think of this as a path to a full story that includes Intention events. Are you saying that ultimately we would have something like this? div cursor=”true” commandEvents=”true”minimally editable content/div Like all other content, this would also get drag/drop, clipboard, and selection events. We would need 3 specs for this- Selection API, minimal editing (cursor-only editing?), and CommandEvent. Yes. I really like the idea of explicitly enabling what you want and of separating the concepts. Being able to turn on commandEvents independent of a cursor seems useful. An API like this leaves far fewer questions of what does it do? than contentEditable=minimal. What does cursor=true do? It turns on the ability for the user or developer to place a cursor, and default movement. It has nothing to do with dom modification. What does commandEvents=true do? It enables dispatching commandEvents. No ambiguity. However, this does make me think again about using beforeinput/input events rather than adding new CommandEvents, since those would include drag/drop and clipboard as well? I really like cursor=true. I'm more confused about commandEvents=true as a separate attribute. - Do CommandEvents make any sense without a cursor? In particular, how does end-user focus an area that has commandEvents=true if there is no cursor? An app can have a cursor that isn't a native browser cursor. For example, Google Docs does not use native browser cursors and draws their own, so that they can show multiple cursors for collaborators and control selections entirely the way they want. They have to use a hidden focused contentEditable region in order to get all the events they need now, but it would be a much nicer solution for them to simply enable the events. How does that work in mobile? iOS for example shows lollipops at the end of selections to trigger editing actions such as copy, paste, etc... if a web content was drawing its own cursor, then these UIs can't be shown for the user. It seems to me that what they want is to use the native cursor and do every editing operation themselves. I'm also not certain how we're going to expose an element with cursor=true but commandEvent=false or cursor=false but commandEvent=true to an assistive technology. - R. Niwa
Re: [editing] Leading with ContentEditable=Minimal
I think that first we need to clarify how we understand some terms/concepts, because I was confused many times and I'm afraid that I also haven't been understood correctly. 1. Separation of basic user intent events and rich command events. Examples: * user intent events - insert character (typing), move caret left, delete a letter, delete a word, insert paragraph break (enter/return), insert line break (shift+enter/return), etc. Additionally there are clipboard, undo and drag and drop events separated already, but they fall into this category. * rich command events - bold, indent, make numbered list, link, enable objects resizing, enable automatic quotes. At some point there were all included in the command events and in my opinion this started the confusion. User intent events are crucial for contentEditable=minimal, when rich command events may be useful for some better internationalization, but are not crucial (if browser does not try to do too much), because they usually are triggered by keystrokes. 2. Commands versus command events. These are separate things again for me - cE=minimal needs events, but does not need commands and entire execCommand/queryCommandState/Value/etc combo. A link command event may be fired when browser thinks that user wants to make a link even if there's no default action bound to that event. 3. Native UI. Again we have UI for basic interaction like the paste option in context menu and UI for rich options like bold or enabling/disabling auto quotes (see [1]). CE=minimal does not need rich options in any form - commands or UI. I'm not sure yet what about basic interaction like copy, cut, paste, spell checking, undo, redo, select all, but they definitely belong to a separate group and may be considered independently of the rich options. Do we agree about these three topics? At least from the separation POV, not necessarily about what cE=minimal needs. [1] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0867.html On Mon, Jun 16, 2014 at 8:12 PM, Ben Peters ben.pet...@microsoft.com wrote: There’s been a good deal of discussion about the value of contentEditable=minimal. Some of us think that being able to cancel all browser actions with preventDefault on all Intention events is enough, while others believe that having a single way to stop browsers from taking action makes sense. I lean in the direction of the former, but there is another consideration- it will take more time to design and build Intention events in all cases, so why not work toward making contentEditable=minimal available, and then ship Intention events once we have a more complete story ready? -- Piotrek Koszuliński CKEditor JavaScript Lead Developer -- CKSource - http://cksource.com -- Follow CKEditor on: Twitter http://twitter.com/ckeditor | Facebook http://www.facebook.com/ckeditor | Google+ https://plus.google.com/107736718646302128806 | LinkedIn http://www.linkedin.com/company/cksource
Re: [editing] Leading with ContentEditable=Minimal
On Tue, Jun 17, 2014 at 12:22 PM, Olivier F teleclim...@gmail.com wrote: On Mon, Jun 16, 2014 at 5:48 PM, Julie Parent jpar...@google.com wrote: On Mon, Jun 16, 2014 at 5:23 PM, Ben Peters ben.pet...@microsoft.com wrote: On Mon, Jun 16, 2014 at 5:12 PM, Julie Parent jpar...@google.com wrote: If Intention events are (temporarily) moved out of scope, I don’t think I’d say they’re out of scope, just that they will likely not be ready as quickly as we could do contentEditable=’minimal’. Do you agree with that? Agreed in general, but it would depend on how contentEditable='min' is actually defined. I think this leads us back to the question of what would contentEditable='minimal' do exactly? Enable collapsed selections and default handling of cursor movement ... anything else? Yes we need to define this default functionality. What does everyone think about this? If this is all it would do, then perhaps what we really want is an explicit API to enable cursors? I think we should still think of this as a path to a full story that includes Intention events. Are you saying that ultimately we would have something like this? div cursor=”true” commandEvents=”true”minimally editable content/div Like all other content, this would also get drag/drop, clipboard, and selection events. We would need 3 specs for this- Selection API, minimal editing (cursor-only editing?), and CommandEvent. Yes. I really like the idea of explicitly enabling what you want and of separating the concepts. Being able to turn on commandEvents independent of a cursor seems useful. An API like this leaves far fewer questions of what does it do? than contentEditable=minimal. What does cursor=true do? It turns on the ability for the user or developer to place a cursor, and default movement. It has nothing to do with dom modification. What does commandEvents=true do? It enables dispatching commandEvents. No ambiguity. However, this does make me think again about using beforeinput/input events rather than adding new CommandEvents, since those would include drag/drop and clipboard as well? I really like cursor=true. I'm more confused about commandEvents=true as a separate attribute. - Do CommandEvents make any sense without a cursor? In particular, how does end-user focus an area that has commandEvents=true if there is no cursor? An app can have a cursor that isn't a native browser cursor. For example, Google Docs does not use native browser cursors and draws their own, so that they can show multiple cursors for collaborators and control selections entirely the way they want. They have to use a hidden focused contentEditable region in order to get all the events they need now, but it would be a much nicer solution for them to simply enable the events. - If commandEvents are just events with no default action, can they not fire safely wherever cursor=true? If the page code does not listen for the event and react, nothing happens. If the page wants to do anything with a command event, it just needs to observe said event. True, and perhaps that could simply things. Events aren't free for the browser though, so there is a cost of having them fire needlessly. I'm assuming here that text insert is a commandEvent and that the page dev takes care of updating the DOM with inserted text (including partial edits with composition events). I guess that part is still up for debate :) I am further assuming CommandEvents refers to low level intent events like deleteToBeginningOfLine (although they could also eventually refer to boldSelection). I want to clarify that in my opinion cursor=true (or commandEvents=true) should in no way imply that the UA should show a WYSIWIG editing UI (bold buttons and context menu entries, etc...). My editor may be a code editor where a bold command makes no sense whatsoever and having bold button looks silly and confusing. I can imagine we would eventually create an API that allows page devs to tell the UA that certain WYSIWYG controls should be shown, and control their state, and they should fire commandEvents. This could be a nice additional building block for editor devs in the future. However the default should be don't show any UA-native WYSIWYG or text editing controls.
Re: [editing] Leading with ContentEditable=Minimal
On Tue, Jun 17, 2014 at 1:44 PM, Julie Parent jpar...@google.com wrote: On Tue, Jun 17, 2014 at 12:22 PM, Olivier F teleclim...@gmail.com wrote: On Mon, Jun 16, 2014 at 5:48 PM, Julie Parent jpar...@google.com wrote: On Mon, Jun 16, 2014 at 5:23 PM, Ben Peters ben.pet...@microsoft.com wrote: On Mon, Jun 16, 2014 at 5:12 PM, Julie Parent jpar...@google.com wrote: If Intention events are (temporarily) moved out of scope, I don’t think I’d say they’re out of scope, just that they will likely not be ready as quickly as we could do contentEditable=’minimal’. Do you agree with that? Agreed in general, but it would depend on how contentEditable='min' is actually defined. I think this leads us back to the question of what would contentEditable='minimal' do exactly? Enable collapsed selections and default handling of cursor movement ... anything else? Yes we need to define this default functionality. What does everyone think about this? If this is all it would do, then perhaps what we really want is an explicit API to enable cursors? I think we should still think of this as a path to a full story that includes Intention events. Are you saying that ultimately we would have something like this? div cursor=”true” commandEvents=”true”minimally editable content/div Like all other content, this would also get drag/drop, clipboard, and selection events. We would need 3 specs for this- Selection API, minimal editing (cursor-only editing?), and CommandEvent. Yes. I really like the idea of explicitly enabling what you want and of separating the concepts. Being able to turn on commandEvents independent of a cursor seems useful. An API like this leaves far fewer questions of what does it do? than contentEditable=minimal. What does cursor=true do? It turns on the ability for the user or developer to place a cursor, and default movement. It has nothing to do with dom modification. What does commandEvents=true do? It enables dispatching commandEvents. No ambiguity. However, this does make me think again about using beforeinput/input events rather than adding new CommandEvents, since those would include drag/drop and clipboard as well? I really like cursor=true. I'm more confused about commandEvents=true as a separate attribute. - Do CommandEvents make any sense without a cursor? In particular, how does end-user focus an area that has commandEvents=true if there is no cursor? An app can have a cursor that isn't a native browser cursor. For example, Google Docs does not use native browser cursors and draws their own, so that they can show multiple cursors for collaborators and control selections entirely the way they want. OK, I can see that. Would commandEvents=true fire cursor movement intents? Or is that strictly a byproduct of setting cursor=true? I can imagine pages that use commandEvents=true would want those events too. Maybe setting cursor=true only draws the cursor when the Element is focused and moves it around according to default behavior without firing events. But if the page wants to control that behavior they set commandEvents=true and cursor=true to intercept and prevent default cursor movements? They have to use a hidden focused contentEditable region in order to get all the events they need now, but it would be a much nicer solution for them to simply enable the events. I'm hopeful that these kind of machinations will be a thing of the past if we can create a good spec here... - If commandEvents are just events with no default action, can they not fire safely wherever cursor=true? If the page code does not listen for the event and react, nothing happens. If the page wants to do anything with a command event, it just needs to observe said event. True, and perhaps that could simply things. Events aren't free for the browser though, so there is a cost of having them fire needlessly. I'm assuming here that text insert is a commandEvent and that the page dev takes care of updating the DOM with inserted text (including partial edits with composition events). I guess that part is still up for debate :) I am further assuming CommandEvents refers to low level intent events like deleteToBeginningOfLine (although they could also eventually refer to boldSelection). I want to clarify that in my opinion cursor=true (or commandEvents=true) should in no way imply that the UA should show a WYSIWIG editing UI (bold buttons and context menu entries, etc...). My editor may be a code editor where a bold command makes no sense whatsoever and having bold button looks silly and confusing. I can imagine we would eventually create an API that allows page devs to tell the UA that certain WYSIWYG controls should be shown, and control their state, and they should fire commandEvents. This could be a nice additional building block for editor devs in the future. However the default should be don't show any UA-native
RE: [editing] Leading with ContentEditable=Minimal
On Tue, Jun 17, 2014 at 8:47 AM, Piotr Koszuliński p.koszulin...@cksource.com wrote: I think that first we need to clarify how we understand some terms/concepts, because I was confused many times and I'm afraid that I also haven't been understood correctly. 1. Separation of basic user intent events and rich command events. Examples: * user intent events - insert character (typing), move caret left, delete a letter, delete a word, insert paragraph break (enter/return), insert line break (shift+enter/return), etc. Additionally there are clipboard, undo and drag and drop events separated already, but they fall into this category. * rich command events - bold, indent, make numbered list, link, enable objects resizing, enable automatic quotes. At some point there were all included in the command events and in my opinion this started the confusion. User intent events are crucial for contentEditable=minimal, when rich command events may be useful for some better internationalization, but are not crucial (if browser does not try to do too much), because they usually are triggered by keystrokes. Why does it matter if there are 'basic' events like typing and 'rich' events like bold? If you only care about the 'basic' ones, you can just respond to those and ignore the rest. 2. Commands versus command events. These are separate things again for me - cE=minimal needs events, but does not need commands and entire execCommand/queryCommandState/Value/etc combo. A link command event may be fired when browser thinks that user wants to make a link even if there's no default action bound to that event. I agree that CE min would only have the events, not the default actions. I updated the explainer below with a more complete table in section 3.1. CE=true would have default actions. http://w3c.github.io/editing-explainer/commands-explainer.html
RE: [editing] Leading with ContentEditable=Minimal
On Tue, Jun 17, 2014 at 4:50 PM, Olivier F teleclim...@gmail.com wrote: On Tue, Jun 17, 2014 at 1:44 PM, Julie Parent jpar...@google.com wrote: An app can have a cursor that isn't a native browser cursor. For example, Google Docs does not use native browser cursors and draws their own, so that they can show multiple cursors for collaborators and control selections entirely the way they want. OK, I can see that. Would commandEvents=true fire cursor movement intents? Or is that strictly a byproduct of setting cursor=true? I can imagine pages that use commandEvents=true would want those events too. Maybe setting cursor=true only draws the cursor when the Element is focused and moves it around according to default behavior without firing events. But if the page wants to control that behavior they set commandEvents=true and cursor=true to intercept and prevent default cursor movements? A cursor is just a type of selection. It happens to not show up in non-editable content, but if it's there, it will fire Selection events just like any other selection. So commandEvents=true is not needed here.
Re: [editing] Leading with ContentEditable=Minimal
Oh right, of course. Thank-you. On Tue, Jun 17, 2014 at 5:00 PM, Ben Peters ben.pet...@microsoft.com wrote: On Tue, Jun 17, 2014 at 4:50 PM, Olivier F teleclim...@gmail.com wrote: On Tue, Jun 17, 2014 at 1:44 PM, Julie Parent jpar...@google.com wrote: An app can have a cursor that isn't a native browser cursor. For example, Google Docs does not use native browser cursors and draws their own, so that they can show multiple cursors for collaborators and control selections entirely the way they want. OK, I can see that. Would commandEvents=true fire cursor movement intents? Or is that strictly a byproduct of setting cursor=true? I can imagine pages that use commandEvents=true would want those events too. Maybe setting cursor=true only draws the cursor when the Element is focused and moves it around according to default behavior without firing events. But if the page wants to control that behavior they set commandEvents=true and cursor=true to intercept and prevent default cursor movements? A cursor is just a type of selection. It happens to not show up in non-editable content, but if it's there, it will fire Selection events just like any other selection. So commandEvents=true is not needed here.
Re: [editing] Leading with ContentEditable=Minimal
If Intention events are (temporarily) moved out of scope, I think this leads us back to the question of what would contentEditable='minimal' do exactly? Enable collapsed selections and default handling of cursor movement ... anything else? If this is all it would do, then perhaps what we really want is an explicit API to enable cursors? On Mon, Jun 16, 2014 at 11:12 AM, Ben Peters ben.pet...@microsoft.com wrote: There’s been a good deal of discussion about the value of contentEditable=minimal. Some of us think that being able to cancel all browser actions with preventDefault on all Intention events is enough, while others believe that having a single way to stop browsers from taking action makes sense. I lean in the direction of the former, but there is another consideration- it will take more time to design and build Intention events in all cases, so why not work toward making contentEditable=minimal available, and then ship Intention events once we have a more complete story ready?
RE: [editing] Leading with ContentEditable=Minimal
On Mon, Jun 16, 2014 at 5:12 PM, Julie Parent jpar...@google.com wrote: If Intention events are (temporarily) moved out of scope, I don’t think I’d say they’re out of scope, just that they will likely not be ready as quickly as we could do contentEditable=’minimal’. Do you agree with that? I think this leads us back to the question of what would contentEditable='minimal' do exactly? Enable collapsed selections and default handling of cursor movement ... anything else? Yes we need to define this default functionality. What does everyone think about this? If this is all it would do, then perhaps what we really want is an explicit API to enable cursors? I think we should still think of this as a path to a full story that includes Intention events. Are you saying that ultimately we would have something like this? div cursor=”true” commandEvents=”true”minimally editable content/div Like all other content, this would also get drag/drop, clipboard, and selection events. We would need 3 specs for this- Selection API, minimal editing (cursor-only editing?), and CommandEvent.
Re: [editing] Leading with ContentEditable=Minimal
On Mon, Jun 16, 2014 at 5:23 PM, Ben Peters ben.pet...@microsoft.com wrote: On Mon, Jun 16, 2014 at 5:12 PM, Julie Parent jpar...@google.com wrote: If Intention events are (temporarily) moved out of scope, I don’t think I’d say they’re out of scope, just that they will likely not be ready as quickly as we could do contentEditable=’minimal’. Do you agree with that? Agreed in general, but it would depend on how contentEditable='min' is actually defined. I think this leads us back to the question of what would contentEditable='minimal' do exactly? Enable collapsed selections and default handling of cursor movement ... anything else? Yes we need to define this default functionality. What does everyone think about this? If this is all it would do, then perhaps what we really want is an explicit API to enable cursors? I think we should still think of this as a path to a full story that includes Intention events. Are you saying that ultimately we would have something like this? div cursor=”true” commandEvents=”true”minimally editable content/div Like all other content, this would also get drag/drop, clipboard, and selection events. We would need 3 specs for this- Selection API, minimal editing (cursor-only editing?), and CommandEvent. Yes. I really like the idea of explicitly enabling what you want and of separating the concepts. Being able to turn on commandEvents independent of a cursor seems useful. An API like this leaves far fewer questions of what does it do? than contentEditable=minimal. What does cursor=true do? It turns on the ability for the user or developer to place a cursor, and default movement. It has nothing to do with dom modification. What does commandEvents=true do? It enables dispatching commandEvents. No ambiguity. However, this does make me think again about using beforeinput/input events rather than adding new CommandEvents, since those would include drag/drop and clipboard as well?
RE: [editing] Leading with ContentEditable=Minimal
On Mon, Jun 16, 2014 at 5:48 PM, Julie Parent jpar...@google.com wrote: Yes. I really like the idea of explicitly enabling what you want and of separating the concepts. Being able to turn on commandEvents independent of a cursor seems useful. An API like this leaves far fewer questions of what does it do? than contentEditable=minimal. What does cursor=true do? It turns on the ability for the user or developer to place a cursor, and default movement. It has nothing to do with dom modification. What does commandEvents=true do? It enables dispatching commandEvents. No ambiguity. However, this does make me think again about using beforeinput/input events rather than adding new CommandEvents, since those would include drag/drop and clipboard as well? The way I see it is that divnot editable at all/div would get clipboard and drag/drop events, like it does today. div commandEvents=truebuild an editor here/div would also get CommandEvents.
