Re: Meeting input

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

Right. Small maintenance stuff is one thing. But if really everything is to
work the same, and all the mentioned merge and split operations are to work
the exact same way, then that's a fulltime position for a considerable
amount of time. If we get clear statements from all the main browser
vendors saying they will actually implement this in cE=true, maybe we can
convince people to put the needed amount of time/energy into this (and
someone to finance them during this time).

Otherwise I think it will be lower level maintenance than that.

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

Agreed, given definition of maintenance given above.

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

Did you get more feedback asking for not allowing alternative forms of
access than the one email on the public-webapps list that asked for that? I
am a little afraid we end up in a fight between militant execCommand
supporters and haters if we just say one has to use execCommand, while the
rest of execCommand is not working and we are working on a non-execCommand
workflow. The question is then: given that the clipboard spec seems to be
based on the execCommand, do we need to put clipboard-related stuff into
the input or cE=events specs to get around that limitation? I'm thinking of
things like should we add cut/copy/paste intention events, and should we
add a way to trigger intentions manually (given certain security
restraints)?
I had hoped the clipboard api would work both for the new and the old
approach, but this could be an alternative way of doing it.

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

The problem here is that the algorithms used for execCommand should likely
be based on current practice in order not to break too much. Once there is
a copy/paste spec for the modular cE system, it will instead base its
merging mechanisms on the many years of realworld experience with
JavaScript-based merging.
So if you reference an algorithm we add to the execCommand spec, it will
tie everything down to the current execCommand way of doing things.

This is why the execCommand way of doing things should be in the
execCommand spec. The execCommand spec should depend on the clipboard api
spec - not the other way round.

Or, as an alternative we could use the above mentioned approach of just
adding everything we need to the two specs we will deal with.

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

Great!

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

Yes, I got that. It means it doesn't really concern a lot of the editor
projects as far as I can tell, including Fiduswriter, which is why I hadn't
thought about it before. But it will be to concern of some editors still.

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

I agree; that's how it should be. That's why we put lits of energy into
making things work for the old way of doing things. Let's try to make sure
it's a true compromise and not just the new approach being broken from the
start because the old approach doesn't allow any alternatives.

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