Re: existing contenteditable spec

On Wed, May 27, 2015 at 6:54 AM, Aryeh Gregor <ayg@aryeh.name> wrote:

> 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.
>
>
I noticed that. That should go into the contentEditableTrue spec. But also
that may be deprecated. The new "contentEditableTyping" spec just records
user intentions (user tried to add a line break), but the default action is
None, meaning that it has to be entirely handled by Javascript. Even caret
movement will be turned into mere "intentions".


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

 Ok, understood. Yes so it may be that the specification gets a big sticker
"deprecated" on the top and that it then doesn't evolve much further from
there. It may be that it gets the sticker, and that it still evolves. Or it
may be that it gets no sticker and just evolves.

There seem to be different ideas about how to proceed with either
execCommand or ContentEditableTrue.

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

Ok, yes that seems to have stopped working when  converting it. But this
info is interesting.


> 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.
>
>
We were told by some browser people that it may be dangerous to touch the
existing execCommand & co due to sites depending on the various bugs it
has. And that the way forward may be to create new versions that function
properly.


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

All the test scripts have been properly transferred and copied. It's just
that neither one of you bothered to check the github repositories. :)

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

Ok, this is noted. We haven't changed any of the parts yet. Should
contenteditable or execCommand be further spec'ed (deprecated or not), the
person who starts changing actual browser behavior in the documents will
contact you.

-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org