Re: Meeting input

On Tue, Aug 11, 2015 at 11:45 AM, Johannes Wilm <mail@johanneswilm.org>
wrote:

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

Please don't interpret this as some official Mozilla position or as an
indication that Firefox won't implement what you're working on. It's just
my opinions, speaking from experience with browser and web development.
I'm *not* saying "don't do your new stuff". I'm *not* saying "I'll oppose
implementing this new stuff". I'm just trying to say "be prepared for a
gradual and sometimes slow transition from old to new stuff, and be
prepared to do some maintenance work on the old stuff if necessary".


> Have you looked at the documents as they are now with warnings attached to
> the top? Is this what you are asking for?
>
Yes, the current text is good. I suggest you decided at the F2F meeting to
leave them like this for now - you can always add a text saying
"deprecated" or "obsolete" at some point in the future. So for your
"deprecate or spec" decisions there's a third option: "maintenance mode
w/warning" and I recommend that option :)


> 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.
>
That's not really the case - of course JS can read from/write to clipboard
when the clipboard events are triggered from the UA's trusted UI (keyboard
shortcuts or "copy/cut/paste" menu commands).

When it comes to the clipboard, coming up with a better API for
reading/writing directly isn't really hard - solving problems regarding
formats/privacy/security *is* hard. So I've listened to feedback from other
spec authors and developers saying that those questions should be explored
before we design another API. I know the execCommand() approach isn't ideal
(and it never was) but given how careful developers and vendors want to be
here, and given that third parties are already screaming about clipboard
access being risky [1] [2] I find it's a good idea to take those baby steps
forward. First buy-in and alignment on the stuff that already exists but is
patchily and incompatibly implemented, then moving forward on formats and
security (I've recently learnt reading might be easier than writing, but I
know writing binary formats has some important use cases) - and at some
point simplifying that API, probably in the next "version" of the spec.
Right now the most important todo is to add further annotations to this
table: http://sync.hoplahup.net/xwiki/bin/view/CnP/NamesForWebClipOps which
Paul Libbrecht was kind enough to start compiling - and annotations also
need to cover security concerns for each data type.


> 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'd expect such questions to be solved in editing specs, with an algorithm
I can just reference. This is just tangentially related to a spec about
clipboard events and APIs, so I'm not sure why content insertion/removal
should be covered there. This may be a good example of something you should
work a bit on even if the old specs are in "maintenance mode"..?


> I think the real-world result of this will be that all the editors will
> continue with hacks as they do now
>

The first real-world result should be that editors can rely on a 'paste'
event listener, use event.clipboardData.getData('text/html') if it's HTML
they want, and do the cleanup and insertion without any
cursor-in-hidden-element hacks at all. And it will work cross-browser when
vendors have aligned their implementations. The only feature we're
postphoning is the ability to read from the clipboard without the user
giving a "paste" command from trusted UI - because privacy is a hard
problem.

The only feature that depends on execCommand() is to have custom copy/cut
buttons in your UI - here legacy editors are using execCommand() already,
and with the new spec it will "just work" without a security prompt, and it
will be cross-browser.

(Our goals are really complementary - I'm making last year's approach work
better while you're fixing next year's :))
-Hallvord

[1] http://tbranyen.com/post/clipboard-hijacking-with-html5
[2] https://news.ycombinator.com/item?id=9582727