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

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

Received on Sunday, 16 March 2014 12:28:46 UTC