Re: [clipboard-apis] spec status

On Apr 8, 2014, at 2:22 PM, Hallvord R. M. Steen <hsteen@mozilla.com> wrote:
>> short status, plans, expectations and such for your spec(s).
> 
> Some details are still being discussed with implementors (special thanks to Ben Peters at Microsoft for bringing up issues recently). In particular, it's still somewhat under-defined how to copy / expose to paste listeners HTML source with styling. IMO that's a real blocker which has come up recently and should be dealt with.

That's going to be an extremely challenging task.  I'd personally prefer deferring that to a future specification or put it in another spec such as the HTML Editing API specification to unblock the work on the rest of clipboard API spec.

> * I should investigate if I can throw out the recently added "semi-trusted" events concept again and just reference something usable - Anne pointed out something.
> * clearData(mimeType) has seen some pushback, it's unclear if it can be implemented correctly in a nice, cross-platform way. I don't really mind dropping it, so I guess I should classify it as "at risk"
> * It's also an open issue whether this spec should describe the safety measures some browsers implement if you paste markup that is *not* handled by any event listeners. (Some browsers remove stuff like javascript: URLs from HREF attributes and drop onfoo="" event listener attributes.) I think it's a bit outside of the scope of a spec describing the *JavaScript* API, but on the other hand it's not described anywhere else AFAIK. Perhaps you could discuss this at the meeting and give me some feedback?
> 
> All in all, I guess I should also try to find some time to run the tests (they are not consistently automated yet, since it's quite complicated to automate everything here) and get a better overview of the implementation state. The spec is based on current implementations but firstly they are often inconsistent and secondly the spec has changed a few things in response to feedback and miscellaneous pondering, so there are certainly bits that implementors need to review and catch up with. (Some of these issues have dodgy interactions with for example UI elements' enabled states, so implementors may be a bit hesitant to change.)
> 
> -Hallvord R
>

Received on Wednesday, 9 April 2014 20:51:49 UTC