Meeting input

Hi,
some thoughts for your meeting in Paris - sorry that I can't show up as an
observer myself.

You have some "deprecate or spec" decisions to make - I hope you keep in
mind that removing features from the web is very, very hard and will take a
long time, and just having a new spec (even if you suceed in getting it
past the hurdles to become a W3C Recommendation) won't guarantee either
implementation or uptake among developers. Also, it's likely we're still a
couple of years away from having widespread implementation support for your
new features and meanwhile many new projects will be built on the old
stuff. Telling developers to not use cE=true during the next few years is
impractical.

For this reason, I suggest that you add a warning - let's call it "intent
to deprecate" - to the older specs, but still keep them in a sort of
low-resource maintenance mode. If some UA developer happens to be working
on something and notices an error in those specs, it should be fixed if
it's easy to do so. If a web developer reads those specs, they should be
encouraged to check the implementation progress of the new work and be
aware that things are changing - but not be told it's bad or wrong to use
the old features until the new ones are ready.

Just my five cents - I hope it makes sense :)
-Hallvord

PS: Editing is sort of a special case among UA features because it's
possible to emulate pretty much all of it with JS. Generally, nobody
decided to do HTML parsing or image decoding in JS on their website because
of cross-UA inconsistencies, but editing is different. This is - believe it
or not - probably one of the reasons editing is such a compatibility mess.
UAs are spoiled by all those editor developers fixing up their problems,
and the pressure for fixing editing hasn't generally been of the "drop
everything else, GMail is broken" type of pressure.