| 07:21 | <philipj> | annevk: thanks for filing those issues |
| 08:14 | <annevk> | philipj: we're looking into implementing this and how to reconcile it with the infrastructure we have for Firefox OS |
| 08:16 | <philipj> | annevk: I guess that means you want some kind of priority between different kinds of audio |
| 08:16 | <philipj> | not sure how to square that with Android or other systems where there is no such concept, or if it's only the sytem itself which can have higher priority, which seems to be the case on iOS |
| 08:17 | <annevk> | philipj: maybe, it might be that the labels are sufficient |
| 08:17 | <annevk> | philipj: e.g. telephony would always use ambient-solo |
| 08:18 | <philipj> | you mean having labels that map to the three behaviors we have, but which also have something to do with priorities? |
| 08:18 | <davve> | ambient-solo doesn't sound right. Mute/pause telephone audio when going to background? |
| 08:18 | <philipj> | annevk: I guess you mean transient-solo right? |
| 08:19 | <annevk> | yeah, oops |
| 08:19 | <philipj> | we have talked about an ambient-solo which would be slightly different then |
| 08:19 | <annevk> | I see, my bad |
| 08:20 | <annevk> | But yeah, maybe something like priorities is needed, I haven't really thought it through entirely |
| 08:20 | <philipj> | anyway, yeah, phone calls behave like transient-solo, but there would be no way to build a WebRTC app which can trump all other apps in the same way that I presume the built-in phone app can |
| 08:20 | <annevk> | I don't think we want Phone > Skype though |
| 08:21 | <philipj> | actually on Android it doesn't seem like the phone app has special powers, but on iOS it probably does |
| 08:21 | <annevk> | Though there should be some way to indicate to the user that while you're on Skype, someone is calling (either through Phone, or perhaps something else, like Hangouts) |
| 08:21 | <philipj> | oh, you mean how to actually make the ringing sound without interrupting everyone else? |
| 08:22 | <annevk> | So while you're on Skype, Hangouts tries to become active, but that fails and therefore it sends some other kind of notification? |
| 08:22 | <philipj> | or whatever the sound is, you mentioned it could be different |
| 08:23 | <philipj> | so on Android you can check if another app says it's playing music, or if the phone call is in progress (separate from the audio focus system) but I don't think there's a way for say the Android Skype and Viber apps to play entirely nicely together, knowing when the other is in a call |
| 08:24 | <philipj> | haven't investigated that specifically though, but that's my guess |
| 08:28 | <philipj> | I suppose it's best to discuss specific changes in GitHub issues and involving those who have done the work on Firefox OS |
| 08:28 | <annevk> | Hopefully baku will participate directly |
| 08:29 | <annevk> | I think they mentioned you guys already had a meeting at one point? We might want to have another in due course... |
| 08:32 | <philipj> | yeah, a big hangout to get everyone in sync would be nice |
| 09:36 | <annevk> | philipj: how would you implement from script a pause invoked from the lock screen? |
| 09:45 | <philipj> | annevk: you'd have to keep track of all the media elements where you had assigned the session, and more importantly you'd need an event for when the lock screen pause button is pressed, and there isn't one yet |
| 09:45 | <philipj> | so multiple things missing :) |
| 09:46 | <annevk> | philipj: right, so I guess that's what I'm asking for |
| 09:46 | <annevk> | philipj: you also want pause/play I think if you need to synchronize with non-media element stuff, such as an animation |
| 09:48 | <philipj> | annevk: to merely synchronize, the smallest addition would be to expose when the session state goes from active to interrupted and back |
| 09:48 | <philipj> | which we also don't have |
| 09:51 | <annevk> | philipj: can a background tab request activation? E.g. is it feasible for a UA to grant that if it granted activation to that tab before when it was not in the background. |
| 09:51 | <annevk> | philipj: that's sort of the basic thing you need for telephony, with some extensions around service workers I guess... |
| 10:04 | <mrflix> | I’d like to propose <input type=time>’s max value to go beyond 23:59 e.g. 48:00 or 72:00. Any thoughts? |
| 10:09 | <Domenic> | it's not <input type=timespan>, it's <input type=time> (i.e. time of day) |
| 10:17 | <mrflix> | domenic: alright, makes sense. So I suppose there should be a <input type=timespan> |
| 10:17 | <Domenic> | mrflix: yeah, except browser vendors are already not so great about implementing the existing input types. better to just roll your own custom element. |
| 10:17 | <Domenic> | it'll be a lot faster than trying to convince all the vendors to implement your new input type |
| 10:20 | <mrflix> | Dominic: I see 😐. Thanks for the feedback! |
| 10:21 | <mrflix> | Domenic: Domenic* |
| 10:21 | <Domenic> | :) |
| 10:31 | <annevk> | except implementing your own input type is not really feasible either... |
| 10:31 | <annevk> | So might as well record this request somewhere |
| 10:32 | <annevk> | Since figuring out how to make <form> et al extensible might well take longer |
| 10:41 | <MikeSmith> | o |
| 10:41 | <MikeSmith> | oofs |
| 10:42 | <MikeSmith> | fat-fingered |
| 11:14 | <Domenic> | An interesting area of non-interop https://github.com/kpdecker/six-speed/issues/14 |
| 11:14 | <annevk> | Domenic: Chrome ignores the type attribute? |
| 11:14 | <Domenic> | annevk: maybe, or maybe something like assumes unknown => text/css |
| 11:14 | <philipj> | annevk: we haven't quite figured that out yet, there's some discussion in https://github.com/whatwg/mediasession/issues/50 |
| 11:14 | <Domenic> | or maybe uses the Content-Type in preference |
| 11:15 | <annevk> | Hmm |
| 11:15 | <philipj> | annevk: oh actually there isn't, that was in an email |
| 11:18 | <philipj> | annevk: summarized in https://github.com/whatwg/mediasession/issues/50#issuecomment-116615686 |
| 11:20 | <annevk> | philipj: I think we're considering some requirements and some "ask forgiveness UI" so the user can change course after we've given activation to a site, but nothing set in stone |
| 11:21 | <philipj> | annevk: isn't the (customizable) UI for "this tab is making sound" pretty much that UI? |
| 11:22 | <annevk> | yeah that might be sufficient |
| 11:57 | <Cwiiis> | Does anyone know if the type for an animation or transition duration in CSSOM is defined anywhere? And if not, what you should use when trying to specify CSSOM that uses a duration? |
| 12:08 | <annevk> | TabAtkins: zcorpan: SimonSapin: ^^ |
| 12:23 | <SimonSapin> | Cwiiis: this? http://dev.w3.org/csswg/css-values/#time |
| 12:27 | <annevk> | SimonSapin: what's that in JavaScript? |
| 12:40 | <Cwiiis> | SimonSapin: right - how do I reference that in idl? |
| 12:41 | <Ms2ger> | zcorpan, you have a cat tweeting for you? |
| 14:00 | <MikeSmith> | why don't any browser-engine projects use some kind of mechanism for documenting test coverage when they implement new features against a spec |
| 14:04 | <JoWie> | that is on my long todo list mikesmith |
| 14:04 | <JoWie> | for a headless browsers though :p |
| 14:59 | <TabAtkins> | Cwiiis: It's a string in the CSSOM, because everything's a string in the CSSOM, because the CSSOM is terrible. |
| 14:59 | <TabAtkins> | Cwiiis: What are you actually trying to do? |
| 14:59 | <Cwiiis> | TabAtkins: spec out the CSSOM for navigation transitions - which I was also going to ping you about, if you don't mind :) |
| 15:00 | <TabAtkins> | Ah, sure. I've got some feedback about your grammars anyway. |
| 15:07 | <Cwiiis> | TabAtkins: cool, all feedback gratefully received (probably) |
| 15:08 | <TabAtkins> | OK cool, feedback 1: FUCK ALL THIS SHIT |
| 15:08 | <TabAtkins> | (jkjkjk) |
| 15:09 | <Cwiiis> | ¬_¬ |
| 16:45 | <annevk> | MikeSmith: we accept... patches? |
| 18:22 | <annevk> | TabAtkins: any (constructive) help would be appreciated |
| 18:22 | <annevk> | TabAtkins: we'd like to get navigation transitions out there somehow |
| 18:23 | <annevk> | TabAtkins: and if we could improve some OM stuff along the way... all the better, but I guess we're okay with sticking with the DOMString mess |
| 18:37 | <TabAtkins> | annevk: We're working on better OM, as a transitional step until we get Value Objects from ES. Will be proposing something soon. |
| 18:37 | <annevk> | TabAtkins: what's this trend of not doing that in public? |
| 18:38 | <TabAtkins> | Working out basic shit first before putting something up in front of people? |
| 18:38 | <annevk> | Sure, but even at that level there's a bunch of people that could follow along and help out |
| 18:38 | <TabAtkins> | There's also a bunch of basic mistakes that'll just waste people's time. |
| 18:39 | <annevk> | The main thing that worries me is that you end up with some Google-centric proposal |
| 18:40 | <annevk> | Although that might happen either way, I guess; e.g. navigator.connect doesn't have many happy Mozillians atm |
| 18:40 | <TabAtkins> | Not sure what "Google-centric" could mean in the context of CSSOM APIs. |
| 18:41 | <annevk> | Mostly no non-Googlers consulted |
| 18:42 | <TabAtkins> | That's why we throw it at the list as soon as we've got something we're vaguely happy with. |
| 18:42 | <annevk> | (or not enough) |
| 18:42 | <annevk> | mkay |
| 18:42 | <annevk> | Thanks for fixing that bikeshed fragment issue btw |
| 18:43 | <TabAtkins> | I mean, we can start with a Shane-centric proposal and put it on the list, but I'm not sure how "proposed something that was created just by Shane" is any better than "proposed something that a couple of Googlers vetted". |
| 18:43 | <TabAtkins> | np |
| 18:45 | <annevk> | What I like about "here's an idea" is that it usually is more malleable to different opinions than something vetted |
| 18:46 | <TabAtkins> | Sure, but what I like about "we discussed this a bit" is that it's not a big pile of shit to start with. |
| 18:47 | <TabAtkins> | (There were *lots* of issues with the first draft.) |
| 18:52 | <jgraham> | Why is it important that Google discuss it a bit before !Google discuss it a bit? |
| 18:53 | <BigPants> | Sorry to butt in, but there might be a point to making those issues visible, in that people who aren't that experienced with specification work can see that even the more experienced people make mistakes and that it's an iterative process. Which might encourage more people to get involved and suggest changes. |
| 18:58 | <annevk> | BigPants: (no need to apologies next time, your opinions are welcome here) |
| 19:02 | <BigPants> | Fair enough! |
| 19:38 | <TabAtkins> | jgraham: It's that >1 people discuss it for a bit, and if one of us is discussing it, it's pretty easy to do a quick Hangout to hash things out (because face-to-face is faster iteration than over lists). |
| 19:53 | <jgraham> | TabAtkins: Seems like it would be possible to make that happen with the wider community with a little effort |
| 19:54 | <TabAtkins> | Not really. Or at least, it requires more than "a little". |
| 19:54 | <TabAtkins> | And it's just putting heads together for an initial proposal, one which is wide-open to change and revision after being proposed. |
| 20:03 | <smaug____> | hmm, CSS WG switching its chairs... perhaps a good thing |