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 <rniwa@apple.com> wrote:

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