Re: Spec'ing innerText (Was Re: [Editing] Splitting Selection API Into a Separate Specification)

[Ryosuke Niwa]

> On Apr 13, 2014, at 5:21 AM, Aryeh Gregor  wrote:
> 
>> On Fri, Apr 11, 2014 at 9:05 PM, Ryosuke Niwa  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

[Aryeh Gregor]

On Sat, Apr 12, 2014 at 7:29 AM, Boris Zbarsky  wrote:
> 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.

Selection.toString already needs to be a complicated prettyprinting
thing anyway, right?  So I don't see any particular downside in
reusing the algorithm for innerText.  IIRC, innerText always did
prettyprinting in all major engines that implemented it (i.e., IE and
WebKit), and some sites depend on some prettyprinting features (at
least converting  and block endings to a newline character).  So
if it's specced at all, I don't see any reason to make it different
from Selection.toString, which in turn needs to do pretty-printing to
match user expectations.

Re: Spec'ing innerText (Was Re: [Editing] Splitting Selection API Into a Separate Specification)

[Aryeh Gregor]

On Fri, Apr 11, 2014 at 9:05 PM, Ryosuke Niwa  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.

But I'm not a CSS expert by any means, so I could well be entirely
wrong.  The approach I took in my abortive spec attempt is certainly
not good at all (which is part of why it was abortive).

Re: [Editing] Splitting Selection API Into a Separate Specification

[Ryosuke Niwa]

> On Apr 11, 2014, at 9:29 PM, Boris Zbarsky  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

[Boris Zbarsky]

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

Spec'ing innerText (Was Re: [Editing] Splitting Selection API Into a Separate Specification)

[Ryosuke Niwa]

On Apr 11, 2014, at 7:09 AM, Domenic Denicola  
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

[Ryosuke Niwa]

Done: http://rniwa.github.io/selection-api.html

On Apr 11, 2014, at 7:35 AM, Arthur Barstow  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 
> ). WDYT?
> 
> -Thanks, AB
> 
> 
> 

Re: [Editing] Splitting Selection API Into a Separate Specification

[Arthur Barstow]

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 ). WDYT?


-Thanks, AB

RE: [Editing] Splitting Selection API Into a Separate Specification

[Domenic Denicola]

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

[Ryosuke Niwa]

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  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

[Ben Peters]

> 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

[Adam Sobieski]

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

[Johannes Wilm]

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  wrote:

>
> On Mar 18, 2014, at 2:22 PM, Johannes Wilm 
> wrote:
>
>
>
>
> On Mon, Mar 17, 2014 at 4:59 AM, Robin Berjon  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  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

[Ryosuke Niwa]

> On Mar 18, 2014, at 2:22 PM, Johannes Wilm  wrote:
> 
> 
> 
> 
>> On Mon, Mar 17, 2014 at 4:59 AM, Robin Berjon  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  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

[Johannes Wilm]

On Mon, Mar 17, 2014 at 4:59 AM, Robin Berjon  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  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

[Aryeh Gregor]

On Mon, Mar 17, 2014 at 1:59 PM, Robin Berjon  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  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"

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

[Ryosuke Niwa]

On Mar 17, 2014, at 4:59 AM, Robin Berjon  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

[Robin Berjon]

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

[Arthur Barstow]

On 3/16/14 9:57 AM, ext Arthur Barstow wrote:
[Draft] 



That should be:

[Draft] 

Re: [Editing] Splitting Selection API Into a Separate Specification

[Arthur Barstow]

On 3/14/14 3:21 PM, ext Ryosuke Niwa wrote:

On Mar 14, 2014, at 5:58 AM, Arthur Barstow  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] 

Re: [Editing] Splitting Selection API Into a Separate Specification

[Aryeh Gregor]

On Fri, Mar 14, 2014 at 1:43 AM, Ryosuke Niwa  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  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  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

[Johannes Wilm]

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  wrote:

>
> On Mar 14, 2014, at 5:58 AM, Arthur Barstow  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

[Ryosuke Niwa]

On Mar 14, 2014, at 5:58 AM, Arthur Barstow  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

[Arthur Barstow]

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] 





[1] https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html

- R. Niwa

Re: [Editing] Splitting Selection API Into a Separate Specification

[Ryosuke Niwa]

On Mar 13, 2014, at 5:08 PM, Domenic Denicola  
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

Re: [Editing] Splitting Selection API Into a Separate Specification

[Kenji Baheux]

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 :

> 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

[Domenic Denicola]

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.

[Editing] Splitting Selection API Into a Separate Specification

[Ryosuke Niwa]

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