Meeting minutes
This meeting
Nigel: Today, we have some admin tasks to rattle through, for DAPT and IMSC,
… it may be that we don't have the full set of people to discuss DAPT and IMSC issues.
… We do have a couple of WebVTT issues as well.
… Any other business, or points to make sure we cover within the agenda?
no other business
DAPT
Publication of a CR Snapshot
Nigel: I believe we have resolved all open HR issues.
Atsushi: Not back from travels yet, I will check that.
Nigel: We already have a resolution to publish 2nd CRS.
… The last pull request (#331) was merged yesterday.
… So I think the next step is to request the transition.
Atsushi: Yes, I will check and do that.
Test suite and implementation report
Nigel: Cyril sent his regrets but I was in contact with him earlier in the week
… and he intends to add the Netflix implementation to the implementation report.
… I checked the test suite has been updated to reflect the most recent spec changes.
… And the tests listed in the implementation report match the test suite.
MAY contain zero or one ... objects should be MUST w3c/dapt#324
github: w3c/
Nigel: Pop quiz.
… When you see the wording "A DAPT Script MAY contain zero or one ... objects"
… do you think that means MUST instead of MAY?
Gary: MAY means optional, if there needs to be exactly zero or one it should be MUST.
… The MAY sounds too optional.
Andreas: I agree, the multiplicity is 0..1 so if there's a need for at least one object it needs to be MUST
Nigel: This is zero or one, maximum
Gary: I think it should be MUST, it's easier to make things less strict than more strict after the fact.
Nigel: Any other views?
SUMMARY: Change the MAY to a MUST.
Nigel: I think this is actually an editorial change, it is clear that was intended.
Gary: I would agree.
DAPT and IMSC compatibility (editorial)
Nigel: I raised two issues, one on DAPT and the other on IMSC.
… IMSC already has sections about compatibility with other TTML based specifications.
… So helpful to add one for DAPT.
… And to mirror that in DAPT with a section on IMSC compatibility.
… I opened a PR on IMSC a short time ago, one to follow on DAPT.
… The most interesting thing is that in DAPT you can have audio but in IMSC you cannot.
… I think that's fine.
… The other interesting informative proposal is a description of how to use DAPT metadata to
… drive or improve the production or presentation of subtitles and captions.
IMSC 1.3
Nigel: There is a CRS transition request open.
… Is there anything holding that up?
Atsushi: I created the request with a strategy review. Everything is under hand for review.
… There are conversations around accessibility review, but it's just a no-reply from them so I described the situation
… and left the decision to higher management.
Nigel: Thank you, so you think it's okay?
Atsushi: I believe so.
… We may need some update after entering CRS, on their comment, but in any case that should be a minor point.
Nigel: Yes they only wanted an informative change.
… Any other points or questions about IMSC 1.3?
WebVTT open issues
Gary: One VTT thing we didn't list is the cue backdrop issue,
… which seems like we have consensus from Firefox and Apple.
… I've been trying to get input from Chrome but it's complicated.
… I don't know how we want to handle it, maybe wait to see if we can get feedback, otherwise move forward.
Eric: We might as well move forward. They have known about it for a long time,
… and they can speak up if they object.
Gary: Yes, I want to wait a little longer since it was Thanksgiving last week.
… We may hear in the next week or two, if not we can move on.
WebVTT should allow pages to modify the caption display area w3c/dapt#531
github: w3c/
Gary: One of the last questions was if the cue backdrop alone is sufficient.
… I think it is not, because users who would want to modify it would need to do extra work.
… If you have cues positioned at the top you would need to handle those differently to cues at the bottom,
… not just changing the size of the display area.
Jer: Can you say more about why shrinking the cue area isn't sufficient?
Gary: I think it is good. There was a question about adjusting the cue backdrop positions up and down.
Jer: You would have to select cues by their layout, which would be a recursive algorithm.
Gary: You couldn't have a solution that pushes cues outside the display area.
Jer: I've looked at websites that try to do this using webkit- CSS properties.
… They've tried to target the backdrop object and transform it upwards.
… They don't do something different on a per cue basis.
… Transforming the cue display area, shrinking it or moving it, would be simpler.
… It would be worth calling out a tracking issue that you would not be able to dodge controls in the middle of the screen,
… but those would be symbiotic APIs.
Gary: Yes I don't think this would preclude having that as an additional API.
… I did try to change the line property, but had to work around bugs.
… In Safari if you replayed a changed cue then Safari would make a new cue, with HLS subtitles.
Eric: With inband captions, if you seek back and play a section already played they deliver the captions again.
… So webkit compares the caption delivered inband by the media engine to the ones it already knows about.
… If they're different it assumes that it's new.
… The OS cue doesn't have any kind of a unique identifier so we just have to go based on the data.
… We've long asked...
Jer: Please file a bug!
… Our deduplication logic should probably take into account the original cue not the modified one.
Gary: You could have in the original source file the same cue text at the same time but on a different line.
… There isn't a good subset of properties to compare.
Eric: no
Gary: If you can keep track of what was modified in javascript that would be helpful.
… The reason I did that is there was no way to target the display area.
… In Safari and Chrome we have the exposed pseudo elements, but not in Firefox.
… So I ended up backing the changes out except in Firefox.
Jer: That's the point of the proposal, so we can get interop on a single way to do this.
Gary: We would need to confirm with the Firefox folk but it seems like something we should move forward to.
… Next question is which properties do we want to allow it on?
… Basic top/bottom/left/right.
… Also transition I think.
… Probably also the helper properties like inset and block level ones, that entire family of properties.
Jer: I've noticed people using transform to move things around.
… We probably don't want to expose any of the properties that move things around.
… It's a big footgun to set the background colour of the caption area and then hide the video.
… Padding on the edges would be useful to shrink the display area.
… All the font and text layout CSS properties are covered by the cue pseudo element so we don't need those.
Gary: And hopefully the cue backdrop as well.
Jer: It doesn't necessarily make sense to include font styling in the backdrop because you can't render text there,
… that's the job of the cue itself.
… What I have seen is that moving the cue area is used both for dodging controls
… and also transferred outside the screen to hide them, to use inband cues for their contents but not their rendering.
… Hopefully won't be necessary if we can get a high level of interop.
Gary: I wonder why they don't just use mode: hidden
… I think some folk just don't know about it.
Jer: Another issue though - what if you transform cues out of the video viewport itself?
… Webkit applies overflow: hidden to the media element's shadow DOM
… You can't transform cues outside the video area.
… We will need to resolve if that's okay or not.
Gary: If you transform the cue -1000, -1000 is it displayed or clipped or forced back into the display area?
Jer: There's a lot of text in WebVTT about how to move cues around, and one option is to move them outside the video display area.
… What does that mean?
… I don't think those unresolved edge cases should prevent us from moving forward on this.
… There's already an interop problem we should solve.
Nigel: There's a use case for presenting captions outside the video, it would be bad to prevent that.
Jer: I'm talking about the video element area not the video content area.
… If you want you can do that by playing around with object fit etc.
… In the currently specified WebVTT.
… There is a bit of ambiguity about what the viewport means when the video aspect ratio doesn't match the aspect ratio of its containing element.
Gary: yes
Jer: The ability to change the object fit should probably not affect the cue location.
… It might be nice to clarify that in a separate issue, that the viewport is not necessarily the video area.
Gary: But then you get issues like the cue height being related to the viewport, the text might get absurdly large.
Jer: The viewport is only defined by the height now, would be nice to define by the minimum dimension.
Gary: You could still have a huge element area with a small video area.
Jer: If you have a dramatically mismatched aspect ratio and you want to restrict the layout of the cues to just the video area,
… a property you could apply to this proposed new area is the aspect ratio itself.
… We should make sure that we lay out the cues within the content area of this new area object.
Nigel: Likewise could you deliberately move them outside that?
Jer: I think you already can.
Nigel: I recall an issue some years ago where there were arguments about the rendering area height.
Gary: Maybe this cue display area is the viewport.
Jer: Viewport is a confusing concept in CSS, which has, after WebVTT, introduced the "container" concept.
… This is familiar to clients of CSS and implementers, so it would make sense
… to define the container area for cues, rather than viewports, which for CSS is the whole rendering area including scrolling.
… I've referenced that as a future change, in a different issue, about using the minimum width/height as the basis for font size.
SUMMARY: We want to move forward with cue container and create a new issue regarding the viewport/containing area for follow-up discussion
Interop: Applying system accessibility preferences to WebVTT cues w3c/dapt#537
github: https://
Gary: This is several issues hiding under a trenchcoat!
… What if the subtitle author specifies a style and the user modifies it to make a terrible user experience.
… One of the questions was around if getComputedStyle() should expose the data about the cues inside the video element.
… From my reading and from when it was created it was not possible to get computed style of pseudo elements except ::before and ::after.
… Looking at the privacy and security considerations it talks about being private by default
… so my reading is that the expectation is they should not be available,
… in which case how Firefox handles it would not be applicable,
… but it should be explicitly called out in the spec,
… assuming it's okay to say that these pseudo elements should not be exposed via getComputedStyle().
Jer: I don't think there will be a lot of pushback from clients because it is already that way for Safari and Chrome.
… It does make things harder to test, because layout WPT tests would be easier if we could query the style.
… It's not a sufficient concern in comparison with the privacy issues.
… I don't think Firefox has that issue now because they don't expose user preferences.
… I also don't know if any websites rely on Firefox's behaviour. It's possible, hence the interop question.
Gary: It could also, in privacy considerations, say that if you are applying OS level styling you must not expose that data.
Jer: This is tied in with the FCC regulation changes, which I need to file an issue for.
… The regulation depending on your legal staff's understanding may require exposing system settings to websites, where possible.
… I will raise the issue explaining the choices we made in that explainer we talked about [at TPAC].
… It might be a requirement soon to expose system preferences to web apps.
… I will file an issue so we can get commentary from other implementers.
Eric: On that issue, if we want to say in the spec that computed style is not accessible we might just
… want to say that the captions are in a closed shadow node which means nothing in it is accessible from javascript.
… That's actually how our implementation works, so we don't have to do anything special to silo it from javascript.
Gary: Wouldn't that imply a specific implementation method, which would require Firefox to change?
Eric: Sure, that's true, so we might want to say, instead, that nothing should be available, not just getComputedStyle().
Gary: mm hmm.
… I guess we shouldn't make any changes here until we hear the fallout from the FCC stuff.
… The other big issue was around what if a user decides to set the text color to white and the content makes the background white
… and the user ends up with white on white cues. Can we mitigate that? I'm not sure we can.
Eric: I don't think there is anything we can do.
… It is possible for a user, per the FCC regulations, to be able to control the display,
… and essentially mark any of the properties of the caption as not changeable.
Jer: If the user sets color to white and ends up with illegible captions, the user can resolve it to override the background color as well.
Gary: Potentially the best we can do is note that it is possible but users should be able to change it.
… Also the new FCC regulations talk about previewability as well. If when you're modifying captions in the first place you see that
… then you would not fall into that trap.
Nigel: That doesn't work if the preview is a UA-provided standard caption, because that won't take into account
… if the page provides black on white or white on black captions, for example.
Jer: [offers demo]
Meeting close
Nigel: Thanks all, let's adjourn the meeting, next call is on 18th Dec, last of the year. [adjourns meeting]