What to do with contentEditableTrue? about editing

[fredck]

I think you summarised it well. To make cE=true usable, we need the following:

1. Quality behavior spec’ed.
2. Interoperability
3. Hooks for overriding the behavior.

One of the ideas that made cE=typing was that cE should be “modular”. It means that “typing” was one of the modules but we could have others. In this way one could have contenteditable=“typing newline delete etc”, enabling a series of editing modules. Each module could be spec’ed independently. Finally, cE=true could be simply spec’ed as a shortcut to have all modules enabled.

I’m for spec'ing cE=true to make it useful and I like the modularization idea.

[chaals]

We pretty clearly should spec it as well as we can. Although if that means it is "all modules enabled" we only have to decide what "all modules" means.

But I don't think that is what it actually means - currently it means "do all kinds of crazy stuff" - so the spec is probably going to be "here are the interoperable bits, and everything else is the wild west".

Which is close to "specified modules work - here they are. Also, the following gotchas are known to happen… (which are bugs we want to bring to closure)", no?

[johanneswilm]

(As earlier said in email):

Once we have a clear wording of cE=typing, I would be in favor of looking at these other parts. However, I also think they could likely (initially) be implemented via JavaScript. Following the principles set out in the Extensible Web Manifesto, we start out by having defined the primitives needed to make this happen in JavaScript libraries. The construction of JavaScript libraries for this purpose and writing of specs would then happen in parallel.

Once the JavaScript libraries and the specs stabilize sufficiently, and if there is an interest from browser makers, these specs can then be implemented by browsers. Alternatively they simply stay W3C specs implemented in Javascript.

[gked]

I would vote for option 1.
I would not want to touch CE="true" with a ten-foot poll. Don't spec it and deprecate it once CE="typing/intent/etc" is stabilized.
There is a good reason why CE="true" wasn't specced before. There are too many edge cases that are extremely difficult to cover. In addition, knowing that we are slowly steering away from CE="true", it would be very hard to convince my developers to potentially change its behavior because they would rather work on new features of CE="typing" instead. Any CE="true" work will eventually become a throw away work. And even if we were to implement changes to CE="true", I am not sure how its ripples affect the web.
Modularity idea also resonates with me as we can actually take action on separate modules and can actually define their behavior in the reasonable amount of time.

[johanneswilm]

Ok, I think there is not all that much disagreement about this then afterall.

@fredck + @chaals I understand your idea and I think it's a good thing to have a way to enable all modules once we have several different modules that could be enabled. However, it would probably be best to use another keyword for this so that browser makers don't have to choose between keeping the old cE=true and the new cE=all (or whatever keyword we will use to enable all editing modules).

I propose that at the Paris F2F meeting, we formally deprecate cE=true and take a formal decision not to spec it, after we decide on a cE=intent spec.

[chaals]

Yeah, I agree that this is what we want to do.

The formal decision process in webapps is that decisions are made asynchronously. Rough consensus and Connolly's law - "the one who does the work makes the rules" play a big part. If the Paris meeting concludes that is the right thing to do we say so, and if nobody screams then that's probably what will happen. Especially since it seems to be the path of least resistance…

[johanneswilm]

Current consensus seems to be that cE=true wil combine the features of cE=typing with all extra features currently found in cE=true, but in a specced way. Speccing will take place some time in the future.