Meeting minutes
This Meeting
<atsushi> (will come shortly)
Nigel: [iterates through agenda] TTML2 - maybe we need to discuss the pull request for 1212
… Do we need to discuss MPEG liaison?
Cyril: I don't think you've received it yet, I'm trying to track it down. I don't think we need
… it on the agenda, I think I have an action to work with Pierre on the wording, which we
… can discuss next time maybe.
Nigel: Ok, let's remove that from the agenda.
… Next is 2 Process2020 topics, default branch name, and AOB.
… Is there any other business?
Cyril: There was a Media WG meeting the other day and I raised the idea of text track
… support in MSE and there was some good feedback.
Nigel: OK, AOB+ that.
… One from me: status of TTML Profile Registry publication.
Remove applicability of tts:direction on <p> w3c/ttml2#1214
github: https://
Pierre: My summary: long discussion on #1211. Boils down to what does tts:direction
… actually do when applied to p. 4 options available:
… 1. Keep things exactly as is by having tts:direction on p have no effect on the inline progression direction.
… This is probably what TTML and XSL-FO have in mind but is incompatible with CSS3.
… 2. Make things consistent with current CSS by having tts:direction on p override the inline
… progression direction set by the writing mode.
… This is inconsistent with existing TTML and XSL-FO.
… 3. Make tts:direction not applicable to p and instead set the paragraph embedding levels differently.
… 4. Keep things as is but note that the result of applying tts:direction on p is implementation-dependent.
… The PR I propose is a compromise, option 3 here.
… It makes tts:direction not applicable on p, removes the opportunity for inconsistency.
… Instead the paragraph embedded level is set from the computed value of the
… writingMode on region, so it is always set to the inline progression direction as determined on region.
… It's consistent with the spirit of TTML, and compatible with modern CSS, and if we ever
… change our mind we can make tts:direction applicable again and maybe then it will be
… more obvious what to do.
… As an aside, we have to decide what to do with unicodeBidi on p, which should be easier
… to deal with.
Andreas: I have minor comments on the pull request but in general I fully agree with the
… intent, for the reasons Pierre mentioned.
Nigel: What's the impact in terms of potentially breaking existing documents?
Pierre: It's really hard to tell. I've not seen many if any right to left IMSC documents in the wild.
… The few I have seen I think just set the writingMode and that's it, without any direction.
… I don't know, in terms of hard numbers.
… If we're going to settle on something now is a good time.
Nigel: Not quite what I meant - rather, if there were a document with direction on p, and
… we made this change, what would be the impact?
Pierre: If the author set direction to explicitly set the paragraph embedding level explicitly,
… presumably that would be consistent with the writingMode, because it would be unusual
… to set the two unequal, so there would be no change.
… If an author had used tts:direction on p to override the inline progression direction set
… by writingMode that would break those documents. Why would someone do that? Maybe
… because they think they're in CSS? This approach would break those documents, possibly.
Andreas: If you specify tts:direction on p or reference a style through some inheritance then
… it is actually specified for p. It is not an error - you can do it even if there is no effect.
… The question about the change breaking, my interpretation is that you would set direction
… on p and there is a deterministic behaviour expected for the rendering. From the long
… long thread we had on that, where all the experts were discussing and could not really
… get a grip on it and agree, it seems to be agreed that there's no deterministic behaviour
… so therefore it doesn't break anything. On the contrary, if you do that, it might not even
… break an existing application. I would argue that if an application would render it the
… way CSS3 does it, it would maybe be okay, but at least not an error.
… If you now fix and make normative a deterministic behaviour then it is very clear that
… some implementation is no longer conformant.
Nigel: Thanks, that's a good point, definitely food for thought.
… I think what you're saying is that this change removes from reachability some features
… of CSS, in that you couldn't get a mapping from a TTML2 document by a processor
… conformant to this PR, which would end up setting the direction property on a p element.
… If you're mapping from TTML to HTML + CSS, say.
… Is that fair?
Pierre: exactly. The only place where you would set the direction property would be the
… equivalent of the region TTML element, which is fine because that's where the inline
… progression direction is set.
Cyril: When Pierre said he hadn't seen Arabic documents in the wild I was wondering what
… we do at Netflix. We have 100,000s Arabic documents. I picked one completely at random
… and it uses direction on p.
… I will paste the example.
… The document I have has no writingMode on the region at all.
<cyril> <p xml:id="p1" begin="00:02:15:02" end="00:02:16:16"><span tts:unicodeBidi="embed" tts:direction="rtl">اجعل نوم أخيك...</span></p>
Andreas: The direction is on span not p
Cyril: Sorry, I need to wake up!
Andreas: Exactly how it should be used.
Cyril: I will try to see if we ever use direction on a p
Pierre: In general that's the question.
Nigel: It seems like Netflix is the best placed to give us real world data.
Cyril: I'm looking. I think the difficulty is checking various vendors. I suspect that if all
… vendors use the same tool, given there's a restricted set of production tools, once we have
… looked at the output of all those tools, if none of them use direction on p then we're
… probably in good shape.
<cyril> <p style="style.default" region="region.after.center" begin="00:00:12:00" end="00:00:14:07"><span tts:direction="rtl">مسلسلات NETFLIX الأصلية</span></p>
Pierre: If they use it on a p and it is consistent with writingMode then it's not terrible.
Cyril: Another example above, again nothing on the p or region
… I will run some queries before expressing an opinion on the change.
Andreas: It's also important to see what would happen if you removed it if you do find it.
… It should be an interoperable behaviour, and at least it should be tested.
Pierre: I will work on implementing Andreas's suggestions - they don't change really the
… fundamental proposal.
… I do want to understand why the group concluded that unicodeBidi is not applicable on p
… when CSS does say some values are applicable to p. I'm happy either way. It would be
… good to get confirmation there.
Andreas: I've seen in your comments you asked for a reference. I couldn't find the discussion
… part but in one of Glenn's latest comment he said he considered removing the application
… of unicodeBidi from p in a later version and that's my recollection from the discussion as
… well, and there's issue #1212 that says to do this.
Pierre: If you go to the latest CSS drafts, some values of unicode-bidi that do have an impact
… on p, including embed. We should point to some discussion or assessment in the PR I think.
Andreas: There is a part of the minutes where Elika explained what they do if it is applied to p.
Pierre: yes, it's in the CSS spec. I think that's less urgent.
… My goal is to close this by end of year.
Nigel: Good discussion on this given the PR is only 11 hours old so already a massive step
… forward, let's keep reviewing.
SUMMARY: Continue reviewing
Process 2020 - Living Standards
Gary: I wanted to get your thoughts on Living Standards in particular because of how
… tied WebVTT is to the web platform, and because of how it seems that living standards,
… if you've never been a Rec then it's a bit easier to become a living standard.
… It seems like adopting it for WebVTT makes sense, since it allows us to get a minimal
… release out and then add features as we go along.
Nigel: By living standard do you mean continual CR or a Rec that can be updated.
Gary: I imagined Rec that allows us to update, and provides a path for moving ahead with WebVTT.
… It allows new features to be added.
Nigel: Thanks, any views?
Andreas: Just for my understanding, isn't this what Nigel calls a continuously updated CR?
… The other way round would be to come to Rec status, but is that what you mean?
<atsushi> https://
Gary: Process2020 does have a new feature for Recs where you say that new features
… can be added.
Nigel: My reading is that both models exist.
<atsushi> https://
Gary: Atsushi put a link above - there's a section about it
Nigel: My understanding is that P2020 allows new features to be added to a Rec but
… labelled as being like CR status features, and when they've met the requirements
… for Rec the labels can be removed.
Atsushi: The group can publish CR snapshots
Nigel: I think Gary's proposal is not about CR snapshots?
Andreas: Currently WebVTT is still in CR status?
Gary: yes
Andreas: But you still intend to bring it to Rec?
Gary: Yes that would be good for it.
Andreas: And then you have the possibility to add features after Rec?
Gary: Yes so you can add features individually instead of going through the entire process.
Nigel: Imagine turning the clock back for IMSC 1.1 and allowing this to be done to add the
… font feature - it would have made things much easier. As long as there's a dated versioned
… link that can be referenced externally.
Nigel: I think there has to be something in the document itself that says it will use this model?
Gary: Yes there's a whole bunch of things that need to be updated and incorporated before
… it can be moved on, and the new end time request from Rob that we can discuss another day.
<atsushi> might be this one(?): https://
Nigel: CfC or proposal to make this change and allow people to consider it?
Gary: Yes.
… Atsushi that link above is the one to start with.
Atsushi: Sorry I misunderstood - it's not CRS but a way to add new features to Recs, and
… allow the change to be reviewed.
Nigel: Yes, it would involve incorporating "Candidate Changes"
Atsushi: Yes, 6.2.11.4 and 6.2.11.5 would need to be applied.
Nigel: Suggest emailing a list of steps and CfC to allow people to think about it?
Gary: Yes sounds good
Atsushi: P2020 is already applied, and this is also about revising a Rec after publication.
Nigel: I think the document itself needs to explain the working mode.
Gary: I believe so, if we want to do it at Rec.
Atsushi: First we need to go to Rec, and after that add in new features.
Gary: Yes that's the plan, to get the pared down thing to Rec with the addition that says
… new features can be amended, and then we can add new features.
Nigel: Is your plan to move "at risk" features to Candidate Changes to allow transition to Rec
… more easily?
Gary: Yes I think so, at least the ones we think should definitely stay in.
Nigel: Thanks that would be useful to explain.
Gary: One final thing: maybe it makes sense to transitioning IMSC to this working mode.
… I know it is more complicated but would be good for any other specs being maintained.
Pierre: Gary, I think it's really worth exploring and look forward to seeing how it works for WebVTT!
Gary: It should be easier for WebVTT because it isn't at Rec.
Pierre: I would like to know what the game plan is for version numbers. Just a year, or a date?
… Or a 1st Ed, 2nd Ed, etc. It's worth thinking about how we're going to do this.
Gary: Good thought.
Pierre: I don't particularly think that the CSS way is very helpful - I find it confusing.
Gary: I'm not sure how it's done for the Rec. For the CR model there are dated snapshots.
Pierre: That's clear at least. You pick one snapshot and implement it.
Gary: That's something I will figure out before sending the email.
Pierre: I'm happy to kick around ideas if you want to ping me. That's been a challenge for
… IMSC, so maybe there's a better way of doing this going forward. Right now we're discussing
… a potential change to TTML2 which is in CR. Do we withhold it, put it in the CR... The way
… the world is going how to update the spec is really important.
Process 2020 - Patent Policy 2020
Atsushi: We need to ask the question to W3M whether we need to do something.
… Two options:
… 1. W3C batch update on various WG Charters to update to patent policy 2020, soon.
… or 2. postpone application until our next rechartering in 2022.
… There will be a WBS on this.
Nigel: From a practical perspective I'm not sure the impact on us?
Pierre: Isn't there an interaction between the new patent policy and the ability to do CR snapshots etc?
… To the extent that we want to consider the new mode of work we might need to switch.
Atsushi: For CRD / CRS we would need Patent Policy 2020.
Nigel: Nobody is proposing to use that at the moment.
<atsushi> https://
AOB - text tracks and MSE
Cyril: Quick update: the Media WG met and started triaging issues for MSE v2.
… Three categories: editorial, in scope and out of scope backlog.
… The Media WG encourages people to review the issues in scope, and the out of scope
… ones if they care about them. The list doesn't include Text Track support in MSE in scope or
… out of scope. I asked the group - they were curious to know what it meant but there was
… no immediate position so I take it as a good sign.
… I encourage TTWG participants who are also Media WG to create an issue if they are interested.
Nigel: Maybe I could talk to you about this offline Cyril?
Cyril: Yes
Meeting close
Nigel: Thanks, we haven't managed to cover Default Branch Name or the AOB on TTML Profile
… Registry publication so will postpone those or cover offline. We're out of time for today,
… so I'll adjourn. Thanks everyone! [adjourns meeting]