Meeting minutes
Rename CSS pseudo-class :picture-in-picture
Rename CSS pseudo-class :picture-in-picture
mounir: Goal is to rename the :picture-in-picture CSS pseudo-class. I think you, Jer, were not super fan of it.
jernoble: Not clear whether the goal is to rename the existing class or to add a new one.
mounir: At the moment, we're not considering adding a new class.
jernoble: If it would rename a pseudo class that people are already using, then I'm not super fan.
mounir: The goal would be to rename the name to append -inline. Then, there is the question of duplication.
… There will be different paths depending on who shipped it already.
… Having an -inline name is not a bad thing in any case.
… If we add the -inline name, we have a path to remove the old name.
jernoble: Testing with Chrome, I think it hasn't shipped
… I don't see the value in renaming this once people have shipped and started using it.
… My opinion is that we should find a new name for things within the picture in picture element.
mounir: The issue is not that we want to use the name in the window. It's that people may try to use the pseudo-class because the name is so vague and expect that this would style the element in the other window, whereas it's styling the video in the original page.
… That's why we wanted to add a clarification by adding "inline".
… I'm fine keeping both names with the vague one flagged as deprecated, and the inline one being the recommended one.
… I think we can find a compromise by adding the inline one and deprecating the old one.
jernoble: I said my piece. Any other views?
… Maybe new proposed text would make things clear.
mounir: How to move forward? Could we suggest to Francois Beaufort to craft a PR and have you or someone else from Safari review it?
jernoble: Yes.
Resolution: Francois Beaufort to craft a PR to add picture-in-picture-inline pseudo-class.
TPAC F2F 2020
mounir: We got an email from W3C management to check whether we want to have a F2F at TPAC as a group. I would assume that as a group we want to meet. We don't know whether TPAC will be physical or virtual. Last I heard, it's still physical, but I would be surprised if it remained the case.
… One open question is whether to include a session on WebCodecs.
… We had fruitful discussions on WebCodecs last year at TPAC, and lots of progress since then, so seems useful to add it to the agenda, especially since it's flagged on our charter.
jernoble: Is it being incubated in another group?
mounir: I would say it's in WICG for now... Yes, confirmed.
jernoble: So we could do a joint session between the CG and ourselves.
mounir: Right.
jernoble: Make sense to me.
Resolution: We will meet at TPAC 2020 and include WebCodecs as a joint session with the WICG.
Autoplay API: update on API shape and editors
mounir: We reached out to the TAG to get advise. They recommended a synchronous API
… Further discussion will be needed, but hopefully that shouldn't require going back to the TAG at this stage.
… Paul reached out to me before the meeting to mention that someone from Mozilla would volunteer as editor. Anyone else?
jernoble: If no one else, we may be able to find someone within Apple to do it.
mounir: This is a good first spec for an editing role. It's mostly about writing the outcomes of discussions down.
jya: Nothing to add for now, I'm catching up as I've been out of the loop for a while.
Discuss how to reconcile colorGamut & transferFunction with ISO 23001-8:2016
Discuss how to reconcile colorGamut & transferFunction with ISO 23001-8:2016
vi: Happy to talk about it now if folks are willing to
GregFreedman: I don't have much to say. The cases you're pointing out don't look like cases we'd be querying ourselves.
vi: What about [example using Dolby parameters with discrepancies between colorGamut and transferFunction input and the color information implicit in the mime type]?
GregFreedman: I don't know if the question is really for content providers. I think it falls on the user agent to provide an answer that is consistent.
jernoble: As a user agent, let me chime in. This is not specific to HDR properties. Example of resolution: low-profile H.264 presented as 4K. Conflict within properties and mime type.
… One possibility is to reply "Not supported" because properties are not all satisfiable.
… Another possibility would be to decide which of these properties have precedence over the others.
… Should we prioritize the content type for instance?
cpn: It would seem to me that detecting that this case happens and reporting it to the developer would be good.
jernoble: We don't have lots of venue to do so.
… A console message could perhaps work.
… I don't think that's something that should be specified in the spec.
jernoble: Any strong feeling between these 2 options?
cpn: I would prefer to see rejecting in case of inconsistencies.
jya: It would be nice to have consistency between user agents.
jernoble: That consistency implies some text in the spec along the lines of "in case of inconsistency, reply no"
jya: That seems like a good approach to me.
jernoble: OK, then that needs text. Let's get back to the issue and move things forward there.
Resolution: reject the promise when there are conflicting inputs, details can be discussed back in the issue
TextTrackCue: add optional event synchronisation
Add optional event synchronisation
cpn: For context, this is work we've been doing in the Media & Entertainment IG on Media Timed Events.
… Ongoing incubation on DataCue in the WICG.
… And two proposals against the HTML spec.
… First is on recommending timing accuracy for TextTrackCue enter and exit events.
… Historically, Chromium has not been super accurate with these event firing, which were tightly coupled with timeupdate events, roughly fired every 250ms.
… There's a desire to have much more accurate timing sync capabilities.
… With recent changes to Chromium, all main user agents are on par with good timing accuracy.
… We'd like to add some language to the HTML spec to specify that timing accuracy.
… I'd like feedback on whether this proposal and wording look good.
GregFreedman: If events have been missed, with the proposed wording, I cannot tell whether a subtitle that has been skipped should be showed slightly after, or altogether eliminated?
cpn: That's a slightly different issue.
… If you're using cue change events, it's possible that, in this situation, the cue would be missed, as the cue would no longer be in the list of active cues.
… If, instead, you're listening to enter and exit events, you're guaranteed to get them.
jernoble: If all implementations are already conformant, why would we need to add non-normative guidance?
cpn: For developers that use these APIs, it does cause some confusion. Having some clarification would benefit them. It would also help setting up the expectations for any future implementations.
jernoble: Do you think that web developers use spec language for this? Or do they e.g. use MDN?
… That is, another option would be to reach out to MDN and add language around expectations.
cpn: I'd like us to do both.
… This stems from the fact that one of the implementations didn't meet these expectations for a long time. Documenting the expectations seems a good thing.
jernoble: I don't think it can be anything else than a SHOULD.
cpn: Right, I was not looking for something normative, actually. Philip suggested that in response to the issue.
mounir: What would be the issue specifying what everyone is doing now?
jernoble: I don't think you can crystallize things to a precise value, e.g. 20ms.
mounir: Goal is to have every browser use enter/exit as a way to drive show/hide. If the spec was saying that, wouldn't that solve the issue without having to specify a time value?
jernoble: Maybe I misunderstand the issue. Can these events be skipped in Chrome?
mounir: I think we're driving everything through timeupdate. But the goal here is to make Chrome non-compliant.
jernoble: This is a quality issue, rather than something that the spec can mandate.
… A note would, I think, strike the right balance.
… Responding to cue change events within 20ms, without requiring implementations to do that.
cpn: Would you guys be happy if I craft a PR along these lines?
jernoble: Sure!
TextTrackCue: add unbounded duration
TextTrackCue: add unbounded duration
cpn: If you're using cues for metadata rather than for captioning, you may want to describe when an event starts, but you may not know in advance when the cue ends, e.g. the start of a news program in a live stream.
… Goal is to make it possible to create a cue with a start time that would run until the end of the media stream.
… Idea is to use infinity value to mean "no end".
… There are some use cases related to broadcasting. There are other use cases in other industries.
… Proposal is to make endTime an unrestricted value.
ericc: That sounds fine, as long as we say that it's only legal in files that have infinite duration. It wouldn't make sense in a file that has a finite duration.
cpn: I would need to think about that.
jernoble: There are a number of file formats where cues don't have a duration until another cue comes up.
… I wonder whether there's an opportunity to have not only an infinite duration, but actually not to have a duration at all.
ericc: What we do is when we get one of these in-band captions for which we only know the start time, we give it an end time that is the duration of the file.
… And then we update the end time when we get the next cue.
jernoble: And maybe that's fine and we can continue doing that.
EME: Persistent Usage Record
mounir: The feature is in the charter. Chrome is working on this.
… Any feedback on this?
xiaohan: I am trying to enable Persistent Usage Record (PUR) in Chromium and would like to know whether other browsers would support it.
jernoble: Safari has implemented the PUR session type, and think it's already in use. I'm pretty sure that we're happy with the current API.
xiaohan: I'm wondering about implementation details, given concerns raised by the TAG
jernoble: I can only talk about FairPlay. We store the proof messages on disk in the open. The proofs are cryptographically signed and encrypted, same as key messages. We make no effort to prevent tampering; according to clients who use PUR sessions, the only effect that corrupting or deleting these messages is that media providers might stop serving new keys to those users.
mounir: Any feedback from Mozilla on the API itself?
jya: I need to consult.
mounir: Tess, any feedback from the TAG?
tess: None off hand, no.
xiaohan: The plan is to send a TAG review to get feedback to drive the process forward. It has been in the ED for a pretty long time.
… If you have comments, let me know!
mounir: End of meeting, thanks everyone!