Re: existing contenteditable spec

On Mon, May 25, 2015 at 1:36 PM, Johannes Wilm <johannes@fiduswriter.org>
wrote:
> Ok, but there may very well be a decision to just not standardize
> execCommand, etc. at all and instead to just deprecate it, in which case
the
> other version also disappears.

Some parts of the spec are necessary parts of the web platform going
forward -- e.g., what happens when a user presses "Enter" with the cursor
in an editable element?  The exact behavior needs to be specced, and
authors considerable pain from having to work around browser
incompatibilities in this sort of thing.

execCommand() itself might be reasonable to deprecate in favor of
author-provided libraries.  However, that doesn't mean there's no need to
spec it, as long as a non-negligible number of sites still use it -- which
they do, last I checked.  Browsers need to support existing sites
properly.  Every difference in browser implementation is some difference in
behavior in a non-negligible number of sites, which is bad.  Deprecated and
little-used features might not be high-priority to spec, but ideally they
should still be specced.

> With "historical behavior" I meant the behavior browsers currently show,
and
> your document seems to list a lot about how Opera X and Chrome 11, etc.
> behave in this and this situation.

These comments are hidden in normal reading, if the stylesheets and scripts
are working correctly.  Those aren't part of the spec themselves -- they're
just background to explain why I specced it the way I did, in case anyone
thinks it should be done differently.  (I originally made them HTML
comments.)

Specs of existing features need to always match preexisting implementations
as much as possible, because sites depend on how existing implementations
work, and changing existing implementations is always risky.  It could
break sites, which makes users angry, so implementers are unwilling to do
it unless strictly necessary.  A spec that deviates too much from existing
behavior is very unlikely to get implemented in practice.  So any spec of
contenteditable needs to be closely based on how current browsers behave,
or else it will probably not wind up getting used.

On Tue, May 26, 2015 at 1:34 PM, Florian Rivoal <florian@rivoal.net> wrote:
> Can't we use the test suite that comes with the spec to determine which
parts of it are interoperable, keep that, and decide on individual parts of
the rest whether this is something that should be dropped, tweaked, or
actually implemented?
>
> Or is there no (sufficient) test suite for that?

The spec has an extremely comprehensive test suite (if I do so say so
myself :) ).  What you're describing is basically what I did to write the
spec in the first place.  For each point, I tested all browsers.  If they
agreed, I specced it.  If there was disagreement and one existing behavior
seemed significantly more sensible, I went with that one.  Otherwise, I
went with the majority, or flipped a coin.  In occasional cases I went
against all browsers, if I thought they were all totally unreasonable.
This is documented in the comments, which in the original spec with proper
scripts and styles <https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html>
are collapsed at the right-hand side until you click on them.

I encourage anyone who wants to take over the spec to speak with me about
the way I wrote the test suite, and any specific things they want to
change.  I spent some hundreds of hours developing it, and usually had a
pretty good reason for everything I did, so it would be a shame to have to
start from scratch.  (I would volunteer to continue editing it myself, but
I no longer work on a consistent basis.)