- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 12 Nov 2020 17:23:22 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <492579AC-D380-4FF8-B6DB-D30A8528C625@bbc.co.uk>
Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2020/11/12-tt-minutes.html
In text format:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
12 November 2020
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2020/11/05-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/158
[4] https://www.w3.org/2020/11/12-tt-irc
Attendees
Present
Andreas, Atsushi, Cyril, Gary, Nigel, Pierre
Regrets
-
Chair
Gary, Nigel
Scribe
nigel
Contents
1. [5]This Meeting
2. [6]Remove applicability of tts:direction on <p>
w3c/ttml2#1214
3. [7]Process 2020 - Living Standards
4. [8]Process 2020 - Patent Policy 2020
5. [9]AOB - text tracks and MSE
6. [10]Meeting close
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: [11]https://github.com/w3c/ttml2/pull/1214
[11] https://github.com/w3c/ttml2/pull/1214
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> [12]https://www.w3.org/2020/
Process-20200915/#publishing-crrs
[12] https://www.w3.org/2020/Process-20200915/#publishing-crrs
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> [13]https://www.w3.org/2020/
Process-20200915/#rec-track
[13] https://www.w3.org/2020/Process-20200915/#rec-track
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(?): [14]https://www.w3.org/2020/
Process-20200915/#revised-rec-features
[14] https://www.w3.org/2020/Process-20200915/#revised-rec-features
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> [15]https://lists.w3.org/Archives/Member/chairs/
2020OctDec/0028.html (survey email)
[15] https://lists.w3.org/Archives/Member/chairs/2020OctDec/0028.html
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]
Minutes manually created (not a transcript), formatted by
[16]scribe.perl version 124 (Wed Oct 28 18:08:33 2020 UTC).
[16] https://w3c.github.io/scribe2/scribedoc.html
----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
---------------------
Received on Thursday, 12 November 2020 17:23:45 UTC