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.
