On Apr 8, 2014, at 2:22 PM, Hallvord R. M. Steen <[email protected]> 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 >
