Re: Meeting input

On 11 Aug 2015 04:36, "Hallvord Reiar Michaelsen Steen" <hsteen@mozilla.com>
wrote:
>
> 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.
>

This effort was initially led by browser people and we JS people were told
that it would be impossible to fix cE=true. Now you, as a representative of
another browser, seem to be telling us the opposite. That seems a little
surprising, so I guess we'll just have to see what happens.

At the same time, at this it seems it would be much less work to implement
our minimal spec with events and direct JS access to clipboard and exact
caret position, then to:

* try to finish writing the execCommand specification fully
* create a full description of all paragraph splitting and merging
mechanisms so that UA behave the exact same way
* create a second version execCommand to be more flexible in what it
applies so that it can be useful at least for very simple editors
* implement this without half the web breaking on the first day

Altogether, I would estimate this could probably be done in 2-3 years if
all browsers really put their weight behind it. With the same amount of
energy, I would estimate 1 month for cE=events.

> 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.
>
Have you looked at the documents as they are now with warnings attached to
the top? Is this what you are asking for?

It is too bad you cannot be there, not even online. I think it is important
to get to an agreement between what to put in the clipboard api spec and
what to put in the various specs we maintain. Right now the clipboard API
spec fully relies on execCommand and gives no other access to the
clipboard. And it doesn't seem to specify how exactly pasted content is
merged with existing content or how things are merged when using cut.
I think the real-world result of this will be that all the editors will
continue with hacks as they do now: when pasting is detected, the caret 'is
moved to a hidden cE-element, and after the paste takes place the contents
of that element are extracted and JS deals with merging things properly. I
am sure that larger editor projects have found even better combinations of
hacks to get what they need through tens of thousands of hours of trial and
error.
I really hope we can come to an agreement that a) on the one hand allows
for you guys to make clipboard actions available through execCommand and
browser-based merging mechanisms, because that seems ti be important to you
guys, even though no editor will likely ever use it, b) and on the other
hand doesn't tie the clipboard down to execCommand and specific, yet still
unspecified merging algorithms.

To me it seems clear that anything specific to execCommand should go into
that spec. The clipboard Api should define general procedures for adding
and taking clipboard content, including the security model. These
procedures could then be referred to in a definition of JavaScript calls to
directly access the clipboard, in the execCommand description of
paste/cut/copy (with specific descriptions of the merge algorithms in the
execCommand spec), and in a possible future description of paste/copy/merge
in a future cE-copy/paste module spec (which will likely have a different
definition of a merging algorithm).

Right. Check out the notice as it is now. There doesn't seem to be any
protests against it.

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