Re: Spec'ing innerText (Was Re: [Editing] Splitting Selection API Into a Separate Specification)
On Apr 13, 2014, at 5:21 AM, Aryeh Gregor a...@aryeh.name wrote: On Fri, Apr 11, 2014 at 9:05 PM, Ryosuke Niwa rn...@apple.com wrote: Thanks for the pointer. Unfortunately, we might need to take a slightly different approach more based on the CSS box tree because whitespace collapsing, etc... are defined in CSS2.1 and CSS level 3 specifications. As far as I know, CSS does not define the box tree with nearly enough precision to allow basing a precise innerText spec on it. From black-box testing at the time I wrote the spec, it seemed to me that WebKit's implementation was built on some sort of internal CSS representation that does not match anything that currently exists in spec-land. So I'm skeptical of the feasibility of this approach until someone rewrites CSS in a more precise fashion. I also don't know if all implementations could support such an approach at all -- IIRC, I was told that for Gecko to even support display:none in Selection.toString was difficult. Right, but the reason WebKit's implementation doesn't match any spec is because there is no spec! With a sufficiently precise spec, we should be able to converge at least on innerText. Having said that, I do agree we need to consult with CSS WG to have a more precise spec. for text layout in order to spec innerText. - R. Niwa
Re: [Editing] Splitting Selection API Into a Separate Specification
On Apr 11, 2014, at 9:29 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/11/14 10:09 AM, Domenic Denicola wrote: - https://www.w3.org/Bugs/Public/show_bug.cgi?id=13145 - https://web.archive.org/web/20121127212525/http://aryeh.name/spec/innertext/innertext.html The outcome of that was basically that the WebKit folks wanted innerText to be some sort of complicated prettyprinting thing (which is nothing like the spec linked above) while Gecko was not all that interested in implementing a complicated prettyprinting thing that wouldn't even be compatible with other browsers' complicated prettyprinting things. Thanks for the pointer. I wasn't aware that there was a disagreement as to what innerText should do. From clipboard/selection API perspective, we need to serialize based on CSS box tree (e.g. generated contents should be included) for copy paste. If we don't want innerText to do the same, we probably need to spec. something entirely different for innerText and copy paste. The work already done on this might make including innerText-dependent features more feasible. innerText is not particularly interoperable even across UAs that implement it, last I checked Definitely not interoperable. But we can probably come up with some sensible spec. for it since websites don't tend to depend on each non-interoperable implementation of innerText unlike execCommand. - R. Niwa
Re: [Editing] Splitting Selection API Into a Separate Specification
I've uploaded the first cut the selection API specification unofficial draft at https://github.com/rniwa/selection-api I've modernized and rephrased the text; e.g. the spec refers to browsing context instead of defaultView, and defines selection's range being null as being empty. Finally, I've turned all Aryeh's comments and notes into notes that are visible. We can remove those comments as we solidify the spec. and get implementation reports. As mentioned in the spec (thanks to Aryeh), there are 11 serious open issues in the current draft. The most serious one is that stringification of selection is completely undefined due to its dependency on innerText, which in turn is also undefined. Given defining innerText is completely outside the scope of the selection API specification, we might need to defer this part to a level 2 specification since the only alternative is to wait for someone to write a innerText spec. While I completely forgot to mention at F2F today, I'm looking for a test facilitator. Aryeh has already written some tests in https://dvcs.w3.org/hg/editing/raw-file/tip/selecttest/ so he/she just needs to import those into web-platfrom-tests repository on github, and modernize them as needed. - R. Niwa On Mar 13, 2014, at 4:43 PM, Ryosuke Niwa rn...@apple.com wrote: Hi, It appears that there is a lot of new features such as CSS regions and shadow DOM that have significant implications on selection API, and we really need a spec. for selection API these specifications can refer to. Thankfully, Aryeh has done a great work writing the spec. for selection API as a part of HTML Editing APIs specification [1] but no browser vendor has been able to give meaningful feedback or has implemented the spec due to the inherent complexity in HTML editing. As a result, the specification hasn't made much progress towards reaching Last Call or CR. Given the situation, I think it's valuable to extract the parts of the spec that defines selection API into its own specification and move it forward in the standards process so that we can make it more interoperable between browsers, and let CSS regions, shadow DOM, and other specifications refer to the specification. Any thoughts and opinions? [1] https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html - R. Niwa
RE: [Editing] Splitting Selection API Into a Separate Specification
From: Ryosuke Niwa [mailto:rn...@apple.com] Given defining innerText is completely outside the scope of the selection API specification, we might need to defer this part to a level 2 specification since the only alternative is to wait for someone to write a innerText spec. I don't know all the history here, but this bug and proto-spec seems relevant: - https://www.w3.org/Bugs/Public/show_bug.cgi?id=13145 - https://web.archive.org/web/20121127212525/http://aryeh.name/spec/innertext/innertext.html The work already done on this might make including innerText-dependent features more feasible.
Re: [Editing] Splitting Selection API Into a Separate Specification
On 4/10/14 11:41 PM, ext Ryosuke Niwa wrote: I've uploaded the first cut the selection API specification unofficial draft at https://github.com/rniwa/selection-api Wow, that was quick; thanks! To facilitate review, I think it would be helpful if you would please create a `directly readable` version (f.ex. use GH pages to create something like http://rniwa.github.io/selection-api.html). WDYT? -Thanks, AB
Re: [Editing] Splitting Selection API Into a Separate Specification
Done: http://rniwa.github.io/selection-api.html On Apr 11, 2014, at 7:35 AM, Arthur Barstow art.bars...@nokia.com wrote: On 4/10/14 11:41 PM, ext Ryosuke Niwa wrote: I've uploaded the first cut the selection API specification unofficial draft at https://github.com/rniwa/selection-api Wow, that was quick; thanks! To facilitate review, I think it would be helpful if you would please create a `directly readable` version (f.ex. use GH pages to create something like http://rniwa.github.io/selection-api.html). WDYT? -Thanks, AB
Spec'ing innerText (Was Re: [Editing] Splitting Selection API Into a Separate Specification)
On Apr 11, 2014, at 7:09 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Ryosuke Niwa [mailto:rn...@apple.com] Given defining innerText is completely outside the scope of the selection API specification, we might need to defer this part to a level 2 specification since the only alternative is to wait for someone to write a innerText spec. I don't know all the history here, but this bug and proto-spec seems relevant: - https://www.w3.org/Bugs/Public/show_bug.cgi?id=13145 - https://web.archive.org/web/20121127212525/http://aryeh.name/spec/innertext/innertext.html The work already done on this might make including innerText-dependent features more feasible. Thanks for the pointer. Unfortunately, we might need to take a slightly different approach more based on the CSS box tree because whitespace collapsing, etc... are defined in CSS2.1 and CSS level 3 specifications. - R. Niwa
Re: [Editing] Splitting Selection API Into a Separate Specification
On 4/11/14 10:09 AM, Domenic Denicola wrote: - https://www.w3.org/Bugs/Public/show_bug.cgi?id=13145 - https://web.archive.org/web/20121127212525/http://aryeh.name/spec/innertext/innertext.html The outcome of that was basically that the WebKit folks wanted innerText to be some sort of complicated prettyprinting thing (which is nothing like the spec linked above) while Gecko was not all that interested in implementing a complicated prettyprinting thing that wouldn't even be compatible with other browsers' complicated prettyprinting things. The work already done on this might make including innerText-dependent features more feasible. innerText is not particularly interoperable even across UAs that implement it, last I checked -Boris
RE: [Editing] Splitting Selection API Into a Separate Specification
Looking into selection in this brave new world (Shadow DOM for sure, but there are issues as well with flexbox if I'm not mistaken), is definitely something we are interested in. I also agree with moving selection to its own spec. Solving selection first opens the door to solving editing.
Re: [Editing] Splitting Selection API Into a Separate Specification
I would think that would be a great idea. We would need to contact the different editor development teams and see if that works for them. On Fri, Mar 21, 2014 at 2:12 PM, Ryosuke Niwa rn...@apple.com wrote: On Mar 18, 2014, at 2:22 PM, Johannes Wilm johan...@fiduswriter.com wrote: On Mon, Mar 17, 2014 at 4:59 AM, Robin Berjon ro...@w3.org wrote: On 15/03/2014 18:44 , Johannes Wilm wrote: yes btw -- where should one go to lobby in favor of the editing spec? I have been communicating with several other browser-based editor projects, and there seems to be a general interest of more communication with the browser creators and spec writers. Currently the situation is that it's so broken in all the browsers, that one needs to use a 100% javascript approach, painting the caret manually and creating a separate system for selections, to circumvent the main problems of contenteditable (for example: https://bugzilla.mozilla.org/show_bug.cgi?id=873883 ). Codemirror is a good example of that. My understanding from talking to various people is that at least part of the problem comes from the type of code that is currently deployed in the wild. An awful lot of it works around browser inconsistencies not through feature testing but through user agent switching. This means that when a given browser fixes a bug in order to become more in line with others (and presumably the spec), it actually breaks deployed code (some of which is deployed an awful lot). That is interesting. I had not heard that before, but it certainly makes sense in many cases. Some other issues, such as when joining two paragraphs by hitting backspace at the beginning of the second one leading to the two paragraphs not being merged the way one would assume by joining the contents of the two paragraphs, but instead by a number of font elements and similar being inserted, don't seem like they would be used by any current editor. It is my understanding that the reasoning behind this is just that A. there is no full and good spec on doing this, so B. everybody waits until there is one with fixing this. I've been talking with some editor developers and have heard some interesting ideas, notably from the Substance.io people. They are also some of those I have spoken to. We share a lot of the same problems as they have, but it is my understanding that they have not yet had to deal with noneditable islands or noneditable islands with editable lakes and similar items. The CKEditor on the other hand does have to deal with this, as do we. One suggestion has been to make at least the selection API interoperable, which seems achievable. So I'm very glad to see Ryosuke propose it here, I was about to suggest the same. Another that I've been mulling over is to have something like contenteditable=minimal (bikeshed syntax at will). This would give you a caret with attendant keyboard motion and selection, but no ability to actually edit the content. Editing would happen by having a script listen to key events and act directly on the content itself. The hope is that not only is this a saner architecture for an editor, but it can also bypass most (possibly all, if the selection API is improved somewhat) browser bugs to do with editing. This would certainly be an improvement. As it is now, we for example do not use contenteditable for anything else than the caret movement, so if that could be done right in all cases, that would mean a lot. Creating a javascript/contenteditable editor is not that hard, if one only has to deal with the various text formatting and adding functions. The problems starts if one has to get around bugs related to the cursor not moving correctly or not moving at all to certain places (for example between two inline non-editable objects in Firefox). Then one needs to create a fake-cursor, etc. which is a much bigger task and only has been achieved by a very few projects so far. I reckon a spec for that could be put together relatively easily. I'm still digging through Web editors' code to get a feel for how much it would actually help. If it would help, I could help organize a meeting with the various editor creators (Aloha, TinyMCE, CKEditor, Substance.io, Fidus writer, HalloJS, etc.) to discuss this. In my experience, these developers are very interested in getting in contact with the browser makers about this, and haven't always been successful in this. Understanding the real needs of editor developers would be great. Would it be possible to have this meeting at this year's TPAC? - R. Niwa -- Johannes Wilm Fidus Writer http://www.fiduswriter.com
Re: [Editing] Splitting Selection API Into a Separate Specification
Web Applications Working Group, With a Selections API in its own specification, discussion topics include: Document Object Model Range Selection HTMLRange : Range HTMLSelection : Selection Interfaces such as HTMLRange and HTMLSelection can extend Range and Selection to provide UI features, e.g. context menus and HTMLMenuElement. Selections API topics include: Attributes on ranges, selections. Styling of ranges, selections. Tooltips on ranges, selections. Context menus on ranges, selections. Scrolling to ranges, selections. Navigating between ranges in a selection and between selections (e.g. tabIndex) Hyperlinks to ranges, selections. Canonical URI fragments for ranges, selections; extending default context menus on selections to clipboard hyperlinks which include the canonical URI fragment. Hypertext content can utilize hyperlinks to ranges and selections to discuss relationships between selected content; see also: http://inference-web.org/ , http://www.w3.org/TR/prov-o/ , http://lurchmath.org/ . Informative content can provide users with information about related ranges or selections with hyperlinks which scroll to ranges or selections and with effects on mouseover. Other topics include visual indicators on scrollbars based on styled ranges and selections. Kind regards, Adam Sobieski From: Ryosuke Niwa Sent: Thursday, March 13, 2014 7:45 PM To: public-webapps@w3.org Cc: Jonas Sicking, Ted O'Connor, Ehsan Akhgari, Aryeh Gregor, Yoshifumi Inoue Hi, It appears that there is a lot of new features such as CSS regions and shadow DOM that have significant implications on selection API, and we really need a spec. for selection API these specifications can refer to. Thankfully, Aryeh has done a great work writing the spec. for selection API as a part of HTML Editing APIs specification [1] but no browser vendor has been able to give meaningful feedback or has implemented the spec due to the inherent complexity in HTML editing. As a result, the specification hasn't made much progress towards reaching Last Call or CR. Given the situation, I think it's valuable to extract the parts of the spec that defines selection API into its own specification and move it forward in the standards process so that we can make it more interoperable between browsers, and let CSS regions, shadow DOM, and other specifications refer to the specification. Any thoughts and opinions? [1] https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html - R. Niwa
Re: [Editing] Splitting Selection API Into a Separate Specification
On Mar 18, 2014, at 2:22 PM, Johannes Wilm johan...@fiduswriter.com wrote: On Mon, Mar 17, 2014 at 4:59 AM, Robin Berjon ro...@w3.org wrote: On 15/03/2014 18:44 , Johannes Wilm wrote: yes btw -- where should one go to lobby in favor of the editing spec? I have been communicating with several other browser-based editor projects, and there seems to be a general interest of more communication with the browser creators and spec writers. Currently the situation is that it's so broken in all the browsers, that one needs to use a 100% javascript approach, painting the caret manually and creating a separate system for selections, to circumvent the main problems of contenteditable (for example: https://bugzilla.mozilla.org/show_bug.cgi?id=873883 ). Codemirror is a good example of that. My understanding from talking to various people is that at least part of the problem comes from the type of code that is currently deployed in the wild. An awful lot of it works around browser inconsistencies not through feature testing but through user agent switching. This means that when a given browser fixes a bug in order to become more in line with others (and presumably the spec), it actually breaks deployed code (some of which is deployed an awful lot). That is interesting. I had not heard that before, but it certainly makes sense in many cases. Some other issues, such as when joining two paragraphs by hitting backspace at the beginning of the second one leading to the two paragraphs not being merged the way one would assume by joining the contents of the two paragraphs, but instead by a number of font elements and similar being inserted, don't seem like they would be used by any current editor. It is my understanding that the reasoning behind this is just that A. there is no full and good spec on doing this, so B. everybody waits until there is one with fixing this. I've been talking with some editor developers and have heard some interesting ideas, notably from the Substance.io people. They are also some of those I have spoken to. We share a lot of the same problems as they have, but it is my understanding that they have not yet had to deal with noneditable islands or noneditable islands with editable lakes and similar items. The CKEditor on the other hand does have to deal with this, as do we. One suggestion has been to make at least the selection API interoperable, which seems achievable. So I'm very glad to see Ryosuke propose it here, I was about to suggest the same. Another that I've been mulling over is to have something like contenteditable=minimal (bikeshed syntax at will). This would give you a caret with attendant keyboard motion and selection, but no ability to actually edit the content. Editing would happen by having a script listen to key events and act directly on the content itself. The hope is that not only is this a saner architecture for an editor, but it can also bypass most (possibly all, if the selection API is improved somewhat) browser bugs to do with editing. This would certainly be an improvement. As it is now, we for example do not use contenteditable for anything else than the caret movement, so if that could be done right in all cases, that would mean a lot. Creating a javascript/contenteditable editor is not that hard, if one only has to deal with the various text formatting and adding functions. The problems starts if one has to get around bugs related to the cursor not moving correctly or not moving at all to certain places (for example between two inline non-editable objects in Firefox). Then one needs to create a fake-cursor, etc. which is a much bigger task and only has been achieved by a very few projects so far. I reckon a spec for that could be put together relatively easily. I'm still digging through Web editors' code to get a feel for how much it would actually help. If it would help, I could help organize a meeting with the various editor creators (Aloha, TinyMCE, CKEditor, Substance.io, Fidus writer, HalloJS, etc.) to discuss this. In my experience, these developers are very interested in getting in contact with the browser makers about this, and haven't always been successful in this. Understanding the real needs of editor developers would be great. Would it be possible to have this meeting at this year's TPAC? - R. Niwa
Re: [Editing] Splitting Selection API Into a Separate Specification
On Mon, Mar 17, 2014 at 1:59 PM, Robin Berjon ro...@w3.org wrote: My understanding from talking to various people is that at least part of the problem comes from the type of code that is currently deployed in the wild. An awful lot of it works around browser inconsistencies not through feature testing but through user agent switching. This means that when a given browser fixes a bug in order to become more in line with others (and presumably the spec), it actually breaks deployed code (some of which is deployed an awful lot). I don't think this is the primary issue. Most of the users of execCommand I've seen don't depend very much on specific behaviors, and only browser-switch on a few things, and this is a problem whenever browsers converge on common behavior. Generally browsers work around this by someone taking the hit and changing their behavior and dealing with a bit of interop fallout by evangelism, or in IE's case mode-switching. The major issue is that the feature is extremely complex, so it would require tons of resources invested by all the browsers to get interoperable, and this would introduce zillions of clear-cut bugs that would have to be fixed at the cost of even more resources. There just aren't enough consumers to be worth it. Sites that make non-trivial use of editing features mostly have given up and use JS libraries anyway. One suggestion has been to make at least the selection API interoperable, which seems achievable. So I'm very glad to see Ryosuke propose it here, I was about to suggest the same. Yes, this should mostly not be difficult, with a couple of exceptions (.modify and stringification come to mind). Another that I've been mulling over is to have something like contenteditable=minimal (bikeshed syntax at will). This would give you a caret with attendant keyboard motion and selection, but no ability to actually edit the content. Editing would happen by having a script listen to key events and act directly on the content itself. The hope is that not only is this a saner architecture for an editor, but it can also bypass most (possibly all, if the selection API is improved somewhat) browser bugs to do with editing. This would be possible using the beforeinput/input events that are already specced. Per spec, various standard actions like delete next character could be intercepted at a high level -- watch the beforeinput event, and if you see .command == delete cancel it and do your own thing. I don't think browsers actually implement the necessary bits for this, though. Also, it's not so hard to do this yourself with key handlers, although it might require a bit of work to get it to not be error-prone. On Mon, Mar 17, 2014 at 10:58 PM, Ryosuke Niwa rn...@apple.com wrote: I'm very pessimistic about the prospect of fixing execCommand. I think we have a much better chance of coming up with some lower-level API that JS libraries could use to build editors. Yes, especially the bits that are very hard to get right -- like wrap this list of consecutive nodes in tag X https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#wrapping-a-list-of-nodes and such. I've tried to spec some such algorithms separately in the spec (without speccing APIs for authors), but they're likely to still be buggy. Browsers mess this sort of basic operation up a lot, which is a good reason to expect authors won't get it right! We still should have execCommand specced well enough that a new browser could theoretically write a web-compatible implementation based only on the spec, but it's probably not worth the effort relative to other things. The biggest piece we're missing on the web platform today is mapping of key events to intended editing actions. e.g. how do you know that Shift+Enter should insert line break as opposed to start a new paragraph, or that Shift+Control+Left should extend selection to the beginning of the line. Relative to the difficulty of writing a full editing implementation, a JS editor implementation should be able to do this pretty easily, shouldn't it?
Re: [Editing] Splitting Selection API Into a Separate Specification
On Mon, Mar 17, 2014 at 4:59 AM, Robin Berjon ro...@w3.org wrote: On 15/03/2014 18:44 , Johannes Wilm wrote: yes btw -- where should one go to lobby in favor of the editing spec? I have been communicating with several other browser-based editor projects, and there seems to be a general interest of more communication with the browser creators and spec writers. Currently the situation is that it's so broken in all the browsers, that one needs to use a 100% javascript approach, painting the caret manually and creating a separate system for selections, to circumvent the main problems of contenteditable (for example: https://bugzilla.mozilla.org/show_bug.cgi?id=873883 ). Codemirror is a good example of that. My understanding from talking to various people is that at least part of the problem comes from the type of code that is currently deployed in the wild. An awful lot of it works around browser inconsistencies not through feature testing but through user agent switching. This means that when a given browser fixes a bug in order to become more in line with others (and presumably the spec), it actually breaks deployed code (some of which is deployed an awful lot). That is interesting. I had not heard that before, but it certainly makes sense in many cases. Some other issues, such as when joining two paragraphs by hitting backspace at the beginning of the second one leading to the two paragraphs not being merged the way one would assume by joining the contents of the two paragraphs, but instead by a number of font elements and similar being inserted, don't seem like they would be used by any current editor. It is my understanding that the reasoning behind this is just that A. there is no full and good spec on doing this, so B. everybody waits until there is one with fixing this. I've been talking with some editor developers and have heard some interesting ideas, notably from the Substance.io people. They are also some of those I have spoken to. We share a lot of the same problems as they have, but it is my understanding that they have not yet had to deal with noneditable islands or noneditable islands with editable lakes and similar items. The CKEditor on the other hand does have to deal with this, as do we. One suggestion has been to make at least the selection API interoperable, which seems achievable. So I'm very glad to see Ryosuke propose it here, I was about to suggest the same. Another that I've been mulling over is to have something like contenteditable=minimal (bikeshed syntax at will). This would give you a caret with attendant keyboard motion and selection, but no ability to actually edit the content. Editing would happen by having a script listen to key events and act directly on the content itself. The hope is that not only is this a saner architecture for an editor, but it can also bypass most (possibly all, if the selection API is improved somewhat) browser bugs to do with editing. This would certainly be an improvement. As it is now, we for example do not use contenteditable for anything else than the caret movement, so if that could be done right in all cases, that would mean a lot. Creating a javascript/contenteditable editor is not that hard, if one only has to deal with the various text formatting and adding functions. The problems starts if one has to get around bugs related to the cursor not moving correctly or not moving at all to certain places (for example between two inline non-editable objects in Firefox). Then one needs to create a fake-cursor, etc. which is a much bigger task and only has been achieved by a very few projects so far. I reckon a spec for that could be put together relatively easily. I'm still digging through Web editors' code to get a feel for how much it would actually help. If it would help, I could help organize a meeting with the various editor creators (Aloha, TinyMCE, CKEditor, Substance.io, Fidus writer, HalloJS, etc.) to discuss this. In my experience, these developers are very interested in getting in contact with the browser makers about this, and haven't always been successful in this. -- Robin Berjon - http://berjon.com/ - @robinberjon -- Johannes Wilm Fidus Writer http://www.fiduswriter.com
Re: [Editing] Splitting Selection API Into a Separate Specification
On 15/03/2014 18:44 , Johannes Wilm wrote: yes btw -- where should one go to lobby in favor of the editing spec? I have been communicating with several other browser-based editor projects, and there seems to be a general interest of more communication with the browser creators and spec writers. Currently the situation is that it's so broken in all the browsers, that one needs to use a 100% javascript approach, painting the caret manually and creating a separate system for selections, to circumvent the main problems of contenteditable (for example: https://bugzilla.mozilla.org/show_bug.cgi?id=873883 ). Codemirror is a good example of that. My understanding from talking to various people is that at least part of the problem comes from the type of code that is currently deployed in the wild. An awful lot of it works around browser inconsistencies not through feature testing but through user agent switching. This means that when a given browser fixes a bug in order to become more in line with others (and presumably the spec), it actually breaks deployed code (some of which is deployed an awful lot). I've been talking with some editor developers and have heard some interesting ideas, notably from the Substance.io people. One suggestion has been to make at least the selection API interoperable, which seems achievable. So I'm very glad to see Ryosuke propose it here, I was about to suggest the same. Another that I've been mulling over is to have something like contenteditable=minimal (bikeshed syntax at will). This would give you a caret with attendant keyboard motion and selection, but no ability to actually edit the content. Editing would happen by having a script listen to key events and act directly on the content itself. The hope is that not only is this a saner architecture for an editor, but it can also bypass most (possibly all, if the selection API is improved somewhat) browser bugs to do with editing. I reckon a spec for that could be put together relatively easily. I'm still digging through Web editors' code to get a feel for how much it would actually help. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [Editing] Splitting Selection API Into a Separate Specification
On Mar 17, 2014, at 4:59 AM, Robin Berjon ro...@w3.org wrote: On 15/03/2014 18:44 , Johannes Wilm wrote: yes btw -- where should one go to lobby in favor of the editing spec? I have been communicating with several other browser-based editor projects, and there seems to be a general interest of more communication with the browser creators and spec writers. Currently the situation is that it's so broken in all the browsers, that one needs to use a 100% javascript approach, painting the caret manually and creating a separate system for selections, to circumvent the main problems of contenteditable (for example: https://bugzilla.mozilla.org/show_bug.cgi?id=873883 ). Codemirror is a good example of that. My understanding from talking to various people is that at least part of the problem comes from the type of code that is currently deployed in the wild. An awful lot of it works around browser inconsistencies not through feature testing but through user agent switching. This means that when a given browser fixes a bug in order to become more in line with others (and presumably the spec), it actually breaks deployed code (some of which is deployed an awful lot). I've been talking with some editor developers and have heard some interesting ideas, notably from the Substance.io people. I think one big problem with contenteditable and execCommand is that it's a very high-level API and that there are two very distinct use cases: WYSIWYG editor - Some CMS, Mail clients, etc... Semantic editor - Some CMS, word processors, etc... And there are also two distinct desires as to what kind of markup UAs should generate: Minimal output - Mail clients want to minimize the size of emails Preserving all elements - CMS editors, etc... want to mark parts of documents via span with id, class, etc... I'm very pessimistic about the prospect of fixing execCommand. I think we have a much better chance of coming up with some lower-level API that JS libraries could use to build editors. One suggestion has been to make at least the selection API interoperable, which seems achievable. So I'm very glad to see Ryosuke propose it here, I was about to suggest the same. Glad to hear that. Another that I've been mulling over is to have something like contenteditable=minimal (bikeshed syntax at will). This would give you a caret with attendant keyboard motion and selection, but no ability to actually edit the content. Editing would happen by having a script listen to key events and act directly on the content itself. The hope is that not only is this a saner architecture for an editor, but it can also bypass most (possibly all, if the selection API is improved somewhat) browser bugs to do with editing. That sounds more like a selection-mode API than contenteditable to me. I reckon a spec for that could be put together relatively easily. I'm still digging through Web editors' code to get a feel for how much it would actually help. The biggest piece we're missing on the web platform today is mapping of key events to intended editing actions. e.g. how do you know that Shift+Enter should insert line break as opposed to start a new paragraph, or that Shift+Control+Left should extend selection to the beginning of the line. Another big piece is undo. We currently don't have any ways to hook things up with browser's native UI for undo/redo, and as a result, most of websites implement their own undo manager which is incompatible with undo/redo menu items. I tried to solve this problem a few years ago with UndoManager API when I was still at Google but that turned into an incomprehensible monstrosity once we introduced undo scopes and other advanced APIs. We might need to introduce something simpler first like the one introduced in IE11 that uses execCommand to start and end an undo unit [1]. [1] http://blogs.msdn.com/b/ie/archive/2013/10/24/enhanced-rich-editing-experiences-in-ie11.aspx - R. Niwa
Re: [Editing] Splitting Selection API Into a Separate Specification
On Fri, Mar 14, 2014 at 1:43 AM, Ryosuke Niwa rn...@apple.com wrote: It appears that there is a lot of new features such as CSS regions and shadow DOM that have significant implications on selection API, and we really need a spec. for selection API these specifications can refer to. Thankfully, Aryeh has done a great work writing the spec. for selection API as a part of HTML Editing APIs specification [1] but no browser vendor has been able to give meaningful feedback or has implemented the spec due to the inherent complexity in HTML editing. As a result, the specification hasn't made much progress towards reaching Last Call or CR. Given the situation, I think it's valuable to extract the parts of the spec that defines selection API into its own specification and move it forward in the standards process so that we can make it more interoperable between browsers, and let CSS regions, shadow DOM, and other specifications refer to the specification. Any thoughts and opinions? If someone wants to work on part or all of the spec, I'm all in favor of them taking it over in whatever form they find useful. I don't have time to own a spec and don't expect to for the foreseeable future, so the entire spec is up for grabs from my perspective. The important thing is someone has to be willing to take it over. If you're volunteering, please feel free! I'm also available to answer any questions you have, albeit not always promptly. On Fri, Mar 14, 2014 at 3:36 AM, Ryosuke Niwa rn...@apple.com wrote: The separation helps move the selection API forward in the standards process. The problem here is that reviewing and agreeing on exact details of execCommand and other parts of the existing HTML Editing APIs specification is significantly harder than just reviewing and agreeing on the part of the spec that defines the selection API. FWIW, when I edited the spec, it was never in a standards process anyway, so this was historically moot. I wrote it Living Standard-style. If someone else wants to take over part or all of it, they could write it either in the W3C Process or not, as they/their employer chose. I do agree that if someone wants to get the spec through the W3C Recommendation track, all the details of execCommand() implementation would have to be dropped, while almost all the selection stuff could be gotten through. IIRC, selection isn't so far from having two interoperable implementations, although there are doubtless a couple of nontrivial blockers. There are fairly reasonable tests as well, although probably lots more could be usefully written (mine mostly just test lots of permutations of a limited set of things). On Sat, Mar 15, 2014 at 7:44 PM, Johannes Wilm johan...@fiduswriter.com wrote: Hey, yes btw -- where should one go to lobby in favor of the editing spec? I have been communicating with several other browser-based editor projects, and there seems to be a general interest of more communication with the browser creators and spec writers. Currently the situation is that it's so broken in all the browsers, that one needs to use a 100% javascript approach, painting the caret manually and creating a separate system for selections, to circumvent the main problems of contenteditable (for example: https://bugzilla.mozilla.org/show_bug.cgi?id=873883 ). Codemirror is a good example of that. I think it would be a good idea to hear everyone's (and especially the browser maker's) thoughts on what should happen to contenteditable and the rest of it -- are there any plans to fix the main issues? Will it just never be fixed and eventually just be removed from browsers? If this is the case, a clear message concerning this will help all us editor-makers make more informed decisions on whether to hope for browsers being fixed or just forgetting about this option. As far as I know, none of the major browser implementers are expending significant resources on contenteditable right now, and JavaScript-based editing is likely to be the way to do things for a long time to come. Ryosuke could probably tell you more about WebKit.
Re: [Editing] Splitting Selection API Into a Separate Specification
On 3/14/14 3:21 PM, ext Ryosuke Niwa wrote: On Mar 14, 2014, at 5:58 AM, Arthur Barstow art.bars...@nokia.com wrote: I think the selection API is ready for recommendation track work. It's mostly interoperable between non-Gecko browsers. One factor to consider re WebApps formally working on this spec is whether there we have sufficient resource commitment(s) re editing, testing, etc. Do we have such commitment(s)? For testing, Aryeh has written a very comprehensive test suite for the entire editing Excellent. , so we should be able to extract the parts for selection API. And I'm more than happy to volunteer as an editor for the spec. Given this and Aryeh's reply, please go ahead and create an ED. This spec should be explicitly added to WebApps' charter [Draft] so please ping me when an ED is available so I can add it. -Thanks, ArtB [Draft] http://www.w3.org/2012/webapps/charter/Overview.html#deliverables
Re: [Editing] Splitting Selection API Into a Separate Specification
On 3/16/14 9:57 AM, ext Arthur Barstow wrote: [Draft] http://www.w3.org/2012/webapps/charter/Overview.html#deliverables That should be: [Draft] http://afbarstow.github.io/WebApps/charter.html#deliverables
Re: [Editing] Splitting Selection API Into a Separate Specification
Hey, yes btw -- where should one go to lobby in favor of the editing spec? I have been communicating with several other browser-based editor projects, and there seems to be a general interest of more communication with the browser creators and spec writers. Currently the situation is that it's so broken in all the browsers, that one needs to use a 100% javascript approach, painting the caret manually and creating a separate system for selections, to circumvent the main problems of contenteditable (for example: https://bugzilla.mozilla.org/show_bug.cgi?id=873883 ). Codemirror is a good example of that. I think it would be a good idea to hear everyone's (and especially the browser maker's) thoughts on what should happen to contenteditable and the rest of it -- are there any plans to fix the main issues? Will it just never be fixed and eventually just be removed from browsers? If this is the case, a clear message concerning this will help all us editor-makers make more informed decisions on whether to hope for browsers being fixed or just forgetting about this option. On Fri, Mar 14, 2014 at 12:21 PM, Ryosuke Niwa rn...@apple.com wrote: On Mar 14, 2014, at 5:58 AM, Arthur Barstow art.bars...@nokia.com wrote: On 3/13/14 7:43 PM, ext Ryosuke Niwa wrote: Hi, It appears that there is a lot of new features such as CSS regions and shadow DOM that have significant implications on selection API, and we really need a spec. for selection API these specifications can refer to. Thankfully, Aryeh has done a great work writing the spec. for selection API as a part of HTML Editing APIs specification [1] but no browser vendor has been able to give meaningful feedback or has implemented the spec due to the inherent complexity in HTML editing. As a result, the specification hasn't made much progress towards reaching Last Call or CR. Given the situation, I think it's valuable to extract the parts of the spec that defines selection API into its own specification and move it forward in the standards process so that we can make it more interoperable between browsers, and let CSS regions, shadow DOM, and other specifications refer to the specification. Any thoughts and opinions? When we last discussed this spec vis-à-vis the Editing CG and WebApps [1], the CG's position was the spec was not ready for Recommendation track work. As such, I would like to hear from Aryeh and/or the Editing CG re Ryosuke's proposal. I think the selection API is ready for recommendation track work. It's mostly interoperable between non-Gecko browsers. One factor to consider re WebApps formally working on this spec is whether there we have sufficient resource commitment(s) re editing, testing, etc. Do we have such commitment(s)? For testing, Aryeh has written a very comprehensive test suite for the entire editing, so we should be able to extract the parts for selection API. And I'm more than happy to volunteer as an editor for the spec. - R. Niwa -- Johannes Wilm Fidus Writer http://www.fiduswriter.com
Re: [Editing] Splitting Selection API Into a Separate Specification
On 3/13/14 7:43 PM, ext Ryosuke Niwa wrote: Hi, It appears that there is a lot of new features such as CSS regions and shadow DOM that have significant implications on selection API, and we really need a spec. for selection API these specifications can refer to. Thankfully, Aryeh has done a great work writing the spec. for selection API as a part of HTML Editing APIs specification [1] but no browser vendor has been able to give meaningful feedback or has implemented the spec due to the inherent complexity in HTML editing. As a result, the specification hasn't made much progress towards reaching Last Call or CR. Given the situation, I think it's valuable to extract the parts of the spec that defines selection API into its own specification and move it forward in the standards process so that we can make it more interoperable between browsers, and let CSS regions, shadow DOM, and other specifications refer to the specification. Any thoughts and opinions? When we last discussed this spec vis-à-vis the Editing CG and WebApps [1], the CG's position was the spec was not ready for Recommendation track work. As such, I would like to hear from Aryeh and/or the Editing CG re Ryosuke's proposal. One factor to consider re WebApps formally working on this spec is whether there we have sufficient resource commitment(s) re editing, testing, etc. Do we have such commitment(s)? -Thanks, AB [1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1617.html [1] https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html - R. Niwa
Re: [Editing] Splitting Selection API Into a Separate Specification
On Mar 14, 2014, at 5:58 AM, Arthur Barstow art.bars...@nokia.com wrote: On 3/13/14 7:43 PM, ext Ryosuke Niwa wrote: Hi, It appears that there is a lot of new features such as CSS regions and shadow DOM that have significant implications on selection API, and we really need a spec. for selection API these specifications can refer to. Thankfully, Aryeh has done a great work writing the spec. for selection API as a part of HTML Editing APIs specification [1] but no browser vendor has been able to give meaningful feedback or has implemented the spec due to the inherent complexity in HTML editing. As a result, the specification hasn't made much progress towards reaching Last Call or CR. Given the situation, I think it's valuable to extract the parts of the spec that defines selection API into its own specification and move it forward in the standards process so that we can make it more interoperable between browsers, and let CSS regions, shadow DOM, and other specifications refer to the specification. Any thoughts and opinions? When we last discussed this spec vis-à-vis the Editing CG and WebApps [1], the CG's position was the spec was not ready for Recommendation track work. As such, I would like to hear from Aryeh and/or the Editing CG re Ryosuke's proposal. I think the selection API is ready for recommendation track work. It's mostly interoperable between non-Gecko browsers. One factor to consider re WebApps formally working on this spec is whether there we have sufficient resource commitment(s) re editing, testing, etc. Do we have such commitment(s)? For testing, Aryeh has written a very comprehensive test suite for the entire editing, so we should be able to extract the parts for selection API. And I'm more than happy to volunteer as an editor for the spec. - R. Niwa
RE: [Editing] Splitting Selection API Into a Separate Specification
From: Ryosuke Niwa [mailto:rn...@apple.com] Any thoughts and opinions? Have there been indications from vendors that they would have more resources to devote to implementing or critiquing the selection API if it were isolated into a smaller document? Is the idea that the surrounding text makes it harder to read the selection portion? I am curious how this separation would help the situation.
Re: [Editing] Splitting Selection API Into a Separate Specification
Looking into selection in this brave new world (Shadow DOM for sure, but there are issues as well with flexbox if I'm not mistaken), is definitely something we are interested in. We haven't gotten around it yet which I believe explain our lack of feedback so far. 2014-03-14 8:43 GMT+09:00 Ryosuke Niwa rn...@apple.com: Hi, It appears that there is a lot of new features such as CSS regions and shadow DOM that have significant implications on selection API, and we really need a spec. for selection API these specifications can refer to. Thankfully, Aryeh has done a great work writing the spec. for selection API as a part of HTML Editing APIs specification [1] but no browser vendor has been able to give meaningful feedback or has implemented the spec due to the inherent complexity in HTML editing. As a result, the specification hasn't made much progress towards reaching Last Call or CR. Given the situation, I think it's valuable to extract the parts of the spec that defines selection API into its own specification and move it forward in the standards process so that we can make it more interoperable between browsers, and let CSS regions, shadow DOM, and other specifications refer to the specification. Any thoughts and opinions? [1] https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html - R. Niwa
Re: [Editing] Splitting Selection API Into a Separate Specification
On Mar 13, 2014, at 5:08 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Ryosuke Niwa [mailto:rn...@apple.com] Any thoughts and opinions? Have there been indications from vendors that they would have more resources to devote to implementing or critiquing the selection API if it were isolated into a smaller document? Is the idea that the surrounding text makes it harder to read the selection portion? I am curious how this separation would help the situation. The separation helps move the selection API forward in the standards process. The problem here is that reviewing and agreeing on exact details of execCommand and other parts of the existing HTML Editing APIs specification is significantly harder than just reviewing and agreeing on the part of the spec that defines the selection API. - R. Niwa
