See also: IRC log
Next f2f dates, 21-23 of July in Cambridge Mass (MIT).
<slightlyoff__> am I the only one who's entertained by the Web Components award going to the W3C? ;-)
October f2f - currently on the books for Sept 29- Oct 1 in London.
I was similarly entertained.
FYI I’ve just sent the actual award in a package off to Dimitri.
<slightlyoff__> that's me
https://gist.github.com/twirl/9483deeb93d134ad2aa8
I produced some editorial feedback...
I’m happy with it but I think it needs more +1’s…
<scribe> ScribeNick: dka
Domenic: Mozilla’s approach to sandboxing the CDM seems good.
Alex: It’s important to distinguish classes of conformance. Mozilla may not be shooting for highest class of conformance.
… for non-firefox os devices they won’t be able to do verified boot, etc… (required for conformance).
… I think it’s a good architecture.
… but we shouldn’t kid ourselves about how far the studios are willing to let that go.
… studios will still have onerous requirements.
Domenic: it seems like it’s possible to have a CDM that doesn’t have complete control over your system.
Alex: let’s sat I have a non-first-run, non-big-budget movie in SD - for that pretty much anything will do. As you go up the tiers, get closer to release date, higher-bit-rate, more audio channels, they [will require higher levels of conformance]
Domenic: It seems - according to the EME spec there are well defined interfaces. Could we turn that into a more formal sandbox? Even for the highest quality content are there stillr restrictions you could make?
Alex: From the perspective of studios this will be a sandbox they control…
Domenic: can we restrict what hardware that code has access to?
Alex: It isn’t about have a particular strategy - you have to do something that meets some particular conformance goal.
Dan: could we feed some of this into Sergey’s draft?
Alex: Additional restrictions by user agents could try to guarantee code running in the sandbox meets some criteria…
Domenic: Because it’s in a secure worker that’s written in javascript it couldn’t crash your cpu, etc…
Dan: we need to get this feedback out.
Domenic: I took a look at Sergey’s feedback - I approved. Good stuff.
… but the urgent thing si that Chrome wants to implement a subset of the animations spec.
… doesn’t touch on the issues we need Alex’s feedback on.
… only think I want to add to Sergey’s dratf - around the finish event. It could be a promise.
… the argument for not being a promise is that you can restart the animation…
Alex: I am swayed by that argument. I think a promise feels odd here.
Domenic: but consider the image.loaded case. I put an issue on the promises guide to potentially add it.
<Domenic_> https://github.com/w3ctag/promises-guide/issues/25
Alex: I see a duality between having an event handler and a promise for each discrete operation.
… we should pick one and recommend it broadly.
Domenic: I think there is momentum behind promise methods for state transitions.
<bkardell_> note: it's somewhat troubling if the state can happen more than once
Domenic: I will put it in the promises guide and get feedback and then add a section in the web animations review that [reflects this].
Sergey: in my opinion we should have both. Finish event might be useful for syncronization.
<bkardell_> I love the idea of a loaded promise, for example, until someone changes the src - then what?
Alex: we should have language
that talks about considering the cases of how and when a
developer might want to add an event handler.
... internally there will be a queue of handlers - stuff you
call when things finish - one of them will resolve the promise
and one will make calls to event handlers...
Domenic: is that black box distinguishable from just registering a promise and registering an event at the same time?
[some discussion on this point]
I formulated some feedback: https://gist.github.com/torgo/e3396b8d0519d21b8600
<bkardell_> was there any conclusion or action items on the promises/animations thing?
https://plus.google.com/u/0/+ChrisMessina/posts/QC4PuXHyx3C
Alex: I think you’re right they’re over-complicating.
… we should note that their odds of success for globally mediating the URL space are quite low.
… users of applinks should understand that the economics don’t favor long-term agreement… will cause problems down the road.
Domenic: My perspective on the feedback - says the right things in the wrong order.
… what we should make a driving point in terms of action item - the point of the document should say “why can’t you do this? [use regular URLs]”.
Alex: it’s clear why they can’t.
… on IOS there is no simple way to register with the OS that “my app is the owner of this namespace.”
Domenic: so they redirect from the web page to the app...
Alex: the feedback needs to be directed to Android and IOS.
… the applinks guys are hacking with what tools they have.
… their applications would be better off on the web.
… the TAG should say - it would be better if the app envirnments allowed us to run webapps…
[as first class citizens]
<slightlyoff> apologies...have to run...like your feedback DKA, and I think it's in the right direction
<Domenic_> https://www.youtube.com/watch?v=XzRBgj1AJYA
<slightlyoff> "get yerself a real website, boy" is, I think, our best response
<slightlyoff> ok, really have to go = (
<slightlyoff> sorry
Dan: I wonder if there’s a middle way - some feedback other than “this is because Android and IOS suck.” :)
Domenic: I think we should say “we don’t like this - it’s bad for the web” but also being [pragmantic].
http://afbarstow.github.io/WebApps/charter.html
Peter: they have the URL spec in there and are working on adding the packaging spec.
… regrets for next week.
Dan: on URL spec, been speaking to various people...
Adjourned