- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 27 Aug 2020 16:37:10 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <6238496B-1CE6-4DB4-A672-00A230006652@bbc.co.uk>
Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2020/08/27-tt-minutes.html
In text format:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
27 August 2020
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2020/08/20-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/137
[4] https://www.w3.org/2020/08/27-tt-irc
Attendees
Present
Andreas, Atsushi, Cyril, Gary, Mike, Nigel, Pierre
Regrets
-
Chair
Gary, Nigel
Scribe
nigel
Contents
1. [5]This meeting
2. [6]Virtual TPAC 2020 Planning
3. [7]Arrange joint virtual TPAC meeting with CSS WG #140
4. [8]Joint TPAC meeting with MEIG and Media WG re: text
tracks #139
5. [9]The codecs parameter should have a formal definition of
the use of the combination operators.
w3c/tt-profile-registry#71
6. [10]MIME parameters ("codecs") for bucket ISO BMFF-wrapped
TTML versus "application/ttml+xml"
w3c/tt-profile-registry#76
7. [11]Interaction between tts:writingMode and tts:direction
on paragraph element. w3c/ttml2#1211
8. [12]Meeting close
Meeting minutes
This meeting
Nigel: [Agenda run-through] Today we have Virtual TPAC 2020
planning,
… TTML2 IR (not much to say there at the moment)
Pierre: Can we cover the writingMode and direction issue?
Nigel: I think we should have time for that.
… Also for the agenda, I added back our favourite TTML Profiles
Registry #71 again,
… after I stalled when trying to make progress.
Mike: That would be one we could hopefully reach closure on
today.
… I think we have answers, to be moved around as necessary.
Nigel: Any other business?
group: [no other business]
Virtual TPAC 2020 Planning
Nigel: A few things here to consider.
… APA joint meeting about synchronised media accessibility
requirements
… I also added "ADCG?"
… And CSS issues and MEIG and Media WG
Nigel: For the APA request to discuss accessibility
requirements for synchronised media,
… my proposal is to suggest to Janina that she proposes a time
for a joint meeting, having
… told her about the other interested groups.
… I'm assuming that nobody from this group thinks we should
_not_ meet to discuss
… synchonisation requirements, unless anyone says otherwise.
group: [no objections!]
Nigel: OK I'll do that then.
… Next up is ADCG. Since we aren't having a specific TTWG
virtual f2f meeting at TPAC,
… there's nothing to discuss, but when we do organise such a
meeting and add ADPT to
… the agenda, then we'll have something to discuss, and I
should invite ADCG to participate
… even if formally as Observers.
Arrange joint virtual TPAC meeting with CSS WG #140
Gary: I haven't got round to adding proposed issues but plan
to.
… The specific one I wanted to add was about viewport units,
and the media element
… and WebVTT and how they interact.
… The reported problem is if you style a cue with viewport
units they get sized according
… to the browser viewport and not the media viewport.
Nigel: Right, and it possibly makes more sense to have a
video-related length unit.
Gary: Yes either a visual video length unit or the viewport
unit should only be with respect
… to the visual area of the video. That would be something to
discuss with the CSS WG.
Nigel: While we're here, any other CSS properties or
not-yet-properties that anyone would
… like to add to the list?
Pierre: Possibly direction, depending on how our conversation
goes re TTML2 writingMode etc.
Nigel: We don't need a complete set now but a reminder to
everyone, if you have something
… to discuss with CSS WG please do add it to #140.
Joint TPAC meeting with MEIG and Media WG re: text tracks #139
Pierre: Now would be a good time to decide whether or not to
have that discussion.
Nigel: Are you talking about the TextTracks proposal
implemented in Safari preview?
Pierre: In general, to have a joint meeting about the state of
Text Track on the web in general.
Nigel: I see that there's a whatwg pull request that just got
closed about the ability to
… remove text tracks too.
Andreas: I would support what Pierre proposes.
… There are different issues about Text Track, some are
continuations of the discussion from
… last year at TPAC.
Mike: I'd also be supportive of looking into this further.
… I discovered that DASH-IF has a fair amount of information on
this.
… I think most of this is public or at least W3C-centric, but I
will do some more homework
… and track down what I can share.
Nigel: OK that seems like adequate momentum to say yes to this.
Pierre: The most important thing is to pick a time and put it
into the calendar.
Cyril: We should be clear that we aren't talking about DataCue
in this case but about TextTrackCue.
Nigel: Why the strong distinction?
Cyril: The use cases are very different I think.
Andreas: I would also support that we separate the slots and
make clear that there are
… two different issues. I can imagine that the Media WG and
maybe the MEIG would try
… to bring the discussion into adjacent slots.
… The area for solution is the same, so they could want to
discuss them together.
Pierre: On July 29th Atsushi sent an email proposing agenda
items.
Nigel: I don't have that in my inbox!
Pierre: Maybe we should pick a time and suggest that we host
the joint discussion at that
… time.
Nigel: Is it not more in the domain of the Media WG to host?
Pierre: If we want it to happen we should just do it otherwise
who knows?
Nigel: Okay
[13]WIki Page for joint meetings
[13] https://www.w3.org/wiki/TPAC/2020/GroupMeetings#Joint_Group_meetings_-_Week_of_12-16_October
Nigel: I see that this meeting is listed as ON HOLD and we need
to make the discussion happen
… to arrange the meeting.
… It would be in the week 12-16 October.
… Atsushi please could you resend your email and give everyone
a kick to restart that discussion
… to arrange the time?
Atsushi: Yes, I think there may have been one response. Sorry I
haven't managed to make
… a summary of the discussion.
Pierre: I think we, this group, should look now for a 1 hour
slot during that week.
Atsushi: There is no specified time, so it is free to be
defined by groups.
Pierre: What about 7am Pacific on Thursday 15th October, so 1
hour before this meeting?
Nigel: Works for me
Andreas: Me too.
<atsushi> >Request for joint meeting during Virtual TPAC 2020
between MediaWG + MEIG and Timed-Text WG
<atsushi> > MEIG would like to add DataCue API to this agenda.
<atsushi> > I recommend following up with the Bullet Chatting
CG to see whether a joint meeting is needed. I haven't heard an
update on their progress in a while.
Nigel: I added in the proposal
… to the wiki, I guess the next step is to tell the other
Chairs about it and see if they can
… accommodate the time request.
… Atsushi, would you be able to get in touch with everyone to
tell them about the proposed time?
Atsushi: I think we got a reply from MEIG only but not from
others.
Pierre: I think an email from you and Gary directly would
really be more effective.
Nigel: Okay
Pierre: The reason is the amount of noise and confusion around
TPAC so it is easy for mass
… emails to disappear into the ether.
Nigel: Okay, surely we can manage this between us, Gary?!
Gary: Yes I think so.
Pierre: Make it short!
The codecs parameter should have a formal definition of the use of the
combination operators. w3c/tt-profile-registry#71
Nigel: I was puzzled about this because I couldn't see what
needs to be done.
Mike: I agree with your assessment.
… [describes history of the issues]
… The post I made the other day was more appropriate to #76 so
I'll repost it there.
… Hopefully we can bring closure to both of these.
Nigel: In terms of #71, would a BNF satisfy this?
Mike: I didn't open this issue but I agree it would.
Nigel: And Cyril you seemed to suggest that is what would be
needed too.
Cyril: The BNF is certainly needed because it clarifies what
characters can be used.
… But also the wording is confusing to me. What does it mean to
say that applications are
… "encouraged to adopt the following syntax"?
Mike: These are intertwined a little bit.
… TTML1 cites RFC6381's element item, which is in the middle of
the ABNF for @codecs,
… and it constraints the W3C TTML profile character set to that
item.
… The good news is it is any TOKEN except ., and now + and | of
course.
… It turns out as always that Glenn's writing is precise but
sometimes obtuse. Everything
… is okay in there. The character set is crisply defined by
RFC6381 even though this has
… nothing actually to do with RFC6381. Does that make sense?
Nigel: That's my understanding as well.
github: [14]https://github.com/w3c/tt-profile-registry/issues/
71
[14] https://github.com/w3c/tt-profile-registry/issues/71
Cyril: [trying to digest]
Mike: We've intertwined application/ttml+xml and
application/mp4 codecs parameters.
… The first one is just this profile code thing. The second one
follows 14496-30 with the
… stpp.ttml.[thing we define here] though we don't mention it
anywhere.
Nigel: I think the "encouraged to adopt" language is there
because in a sense we can't
… force anyone to adopt this.
… My memory bells are ringing about a discussion we had about
this.
Mike: Decoders today are not | and + aware, certainly not in
the ISOBMFF universe, and
… I don't know who uses the application/ttml+xml media type,
but maybe
… if a sidecar is delivered over the web it would matter.
Cyril: We should define the syntax, but the encouragement to
adopt is secondary.
Nigel: That makes sense.
Mike: Agreed.
Nigel: I think this syntax may be used at least in part in the
DVB TTML specification, I would
… need to check to confirm.
Nigel: To conclude then, I think this has turned the request
into:
… 1. Define the syntax of codecs
… 2. Separate out the "encouragement to adopt" language.
Mike: I would offer that it would be helpful to add a note of
the form:
… "For codecs parameter for MP4 please see ISO14496-30".
Nigel: Is that the resolution to #76?
Mike: Not quite. To separate them, ISOBMFF folk will get
confused by the identically named
… parameter. I'm suggesting we should add a note about that to
tell people where to
… go to understand about stpp.ttml. So:
… 3. Add an informative note.
Nigel: Okay, any more on this one?
Mike: Then I think we're done on this.
Cyril: I agree
SUMMARY: @nigelmegitt to take a pass at creating a PR to do the
above
MIME parameters ("codecs") for bucket ISO BMFF-wrapped TTML versus
"application/ttml+xml" w3c/tt-profile-registry#76
github: [15]https://github.com/w3c/tt-profile-registry/issues/
76
[15] https://github.com/w3c/tt-profile-registry/issues/76
Mike: If we all look at my comment on #71 from two days ago:
[16]Mike's comment
[16] https://github.com/w3c/tt-profile-registry/issues/71#issuecomment-680222378
Mike: We covered most of this, but I want to cover the
character set constraint based on
… RFC6381 "element" which makes the syntax precise.
… The codecs parameter here is a subset of RFC6381.
… I'm noting that it is nothing to do with RFC6381 and the
citation is only for the syntax
… This clarifies that ISOBMFF is about application/mp4 and that
we also point to 14496-30
… which we agreed to do a moment ago.
… I think an example would be helpful, so I produced an
example.
Nigel: Isn't there an example already?
Mike: Just an abstract one.
Nigel: Oh I see, a real world one would be better.
Mike: If this is okay then I'll make a specific language
proposal.
Nigel: Sounds good to me.
Mike: Let me know if we're there.
Cyril: I think we're in agreement here.
SUMMARY: @mikedo to make a language proposal.
Interaction between tts:writingMode and tts:direction on paragraph
element. w3c/ttml2#1211
Nigel: Good updates over the past week, are we getting closer?
Cyril: No!
github: [17]https://github.com/w3c/ttml2/issues/1211
[17] https://github.com/w3c/ttml2/issues/1211
Pierre: If I may I'd like to go back to the [scribe missed]
Cyril: We asked 4 questions but don't have answers on any of
them.
… I would like to know the opinion on semantic derivation on
padding and textAlign.
… On the second q, he gives history about why unicodeBidi is on
a p, but I don't think
… I have an answer because unicodeBidi is not applicable on a p
but maybe there's some
… reparenting specific behaviour.
… I'm lost in the answer on the paragraph embedding level.
… That's what I meant by being no closer.
Andreas: It's the typical case where the closer you look the
further it gets.
… My question is if we can solve individual parts of the
Unicode Bidi algorithm without the
… big picture of how it is applied in general. The more I read
about it the less clear it gets
… because there are so many entangled specifications.
… For the reader it is not clear which specification applies.
Cyril: Are the specifications in conflict?
Andreas: They won't fit together. For example XSL-FO was
written before unicodeBidi:isolate
… was added to the algorithm but TTML2 uses it, so it is
difficult to follow.
… TTML uses the layout mechanism and text handling from XSL-FO.
I won't say it is in conflict
… but it is also not clear what Glenn tried to state in his
latest post, a clear algorithm for
… how it all works together.
Pierre: That's definitely where I am.
… In particular there is broad understanding of Unicode Bidi
algo across inline elements.
… I still don't understand what setting unicodeBidi on p does.
I don't understand that.
… CSS does not do that either.
Nigel: Maybe tts:color would be a comparable example.
… Oh, no, it only applies to span.
Pierre: Yes, we made changes to a number of style attributes to
remove applicability to p
… when they only apply to span.
… [shares screen with codepen]
… Two p elements:
… 1st includes rtl "hello", with unicode-bidi set to override
and direction: rtl
… In CSS direction:rtl changes the inline progression direction
because it is right-aligned and
… the start edge is to the right.
… the border-inline-start: 10px solid red; shows the start edge
… Setting direction on p changed the writing mode and the
direction of the unicode-bidi algorithm.
… If you do the same thing for a span within a p it does not
change the start edge but it does
… change the writing order. The same string is still written
right to left, but the line is left aligned.
Andreas: This is what we discussed and seemed to agree, that it
happens in CSS but is not
… aligned with TTML.
Pierre: My fundamental question, for the first p, is that, in
CSS since you cannot change
… direction on p, without changing the progression direction,
is there any circumstance when
… you would want to change the direction of p without changing
the progression direction?
… If there is then we should ask for it from CSS.
Andreas: Short answer to this: you can find a use case, like an
arabic programme with an English
… citation, with writingMode on region but textAlign on p.
… It's just syntactic sugar and convenience why you can set
direction on span. [scribe: ??]
Pierre: I asked Glenn that, and he said no.
Andreas: That's the second thing. The paragraph level is the
base direction of the paragraph.
… In the unicode bidi algorithm this is a special construct,
not the same as inserting
… special characters. Every p has this, but from the algorithm
it is not the same.
… I need to go through the complete thing, but from now I can
see that at least you may
… have a different count of embedding levels which would lead
to exceeding the maximum
… number of levels depending on which option you choose.
Relevant for testing but not
… for real world use.
… Algorithmically, it's not syntactic sugar but practically it
is hard for me to see the difference.
Pierre: So for instance if you try to transform TTML into
HTML+CSS, when you encounter
… direction on p you would create a child span with direction
on the child span, and that
… would be the rendering equivalent?
Andreas: I hope so, yes.
<Zakim> gkatsev, you wanted to ask about border inline start
for the span and contexts
Gary: If you colour the border inline start of the span, is it
also on the right?
Pierre: Within the span, yes.
Gary: Then I guess this is because the p is still in the
standard writing mode, it pushes the
… span to the left even if it it rtl.
… It's direction: rtl; that does something different, and it's
the context that makes it look
… like something different is happening but for the actual
element where you apply the
… direction the same thing is happening within it.
Pierre: So there is no equivalent to tts:direction in CSS today
because every time you set
… direction in CSS it does change the writing direction even if
you set it on a span.
Gary: I guess you could set writing-mode on top of it to set it
manually?
Pierre: No you can't anymore in CSS. It's only for vertical.
… I don't mind going back to CSS and saying that their approach
does not address some
… important use cases but otherwise the divergence between TTML
and CSS is not helpful.
Andreas: Elika commented at the beginning that they changed it
in CSS so we maybe need
… to go back to CSS level 1 to see if it was similar to what
TTML is doing now. In general
… it shows how difficult it is to balance all these different
specs, especially XSL-FO that is
… getting more and more decoupled from what is in CSS.
… I see no alternative but eventually to rebase TTML on CSS to
have an aligned development.
Pierre: Before that huge step, can you think of practical use
cases where setting
… inline progression direction differently from the unicode
bidi writing direction is useful?
… Or tell me my question is silly!
Cyril: I'm not sure I understand the exact issue. Is it true
that we can do things in TTML
… that we cannot map to CSS, or the opposite?
Pierre: In this specific case, in CSS it is not possible to set
the inline progression direction
… separately from the unicode bidi direction.
Cyril: Is it possible to get the same effect with different
elements?
Pierre: I don't think so because setting direction also sets
the writing direction. In TTML
… the two are set separately.
Andreas: From my current view, from the power of expression
both strategies should be
… equivalent so you can express both, but if not you need to
find which strategy allows you
… to do more than the other. I don't see it at the moment.
… There are two different concepts of the unicode bidi
algorithm and the alignment point.
Nigel: I'm not sure if we have a clear understanding of the
spec, but to the extent that we do,
… if we change the interpretation, that would be a bad thing
for existing authored documents
… if they get rendered differently.
Pierre: Looking at Direction003 test, the reference render
changes both the alignment and
… the unicode bidi direction. That's how its been since April
2017.
Cyril: And we agree that TTPE would show it left aligned?
Pierre: Yes
Cyril: And an HTML render would have it right aligned?
Pierre: Yes, if you set direction: rtl; on p then it would
right align when text alignment is start.
Andreas: Yes, it seems that TTML is doing something different
here.
Pierre: Yes, and I'm worried about CSS being widely implemented
and used...
Cyril: ... could we limit the divergence in IMSC by saying
writingMode and direction should
… match?
Pierre: Yes of course, but then this test would need to be
changed because this test has
… them not matching on p.
Cyril: The content would then not be valid IMSC, so we would
remove it.
Pierre: I'm concerned that diverging from CSS makes it harder
for people to do TTML in general.
Nigel: Another option is to state that when mapping to CSS when
they don't match you have
… to reverse the mapping of the start and end keywords.
Andreas: A formal way is to do it like CSS or say don't use
direction on p, possibly.
… The unicode bidi algorithm really applies to inline text.
… With writing mode set already to paragraph embedding level.
Pierre: I think that would be a super clean solution by the
way. Just remove "p" from applied to
… and the problem is gone completely.
Nigel: You can still have writingMode on region though
Pierre: Yes absolutely, it means that in TTML the only way to
change the alignment is on a region.
Nigel: And then you can't have text alignment start based on
the script direction on a p by p basis.
Pierre: That's Glenn's interpretation now though.
Nigel: Yes that's right.
Andreas: You can always set left and right.
Nigel: True
Pierre: Having a use case here would really help if we want to
go back to CSS and tell them
… they have missed a use case. Otherwise we should explore
getting closer to CSS rather
… than farther away.
Nigel: Seems like a good place to draw today's conversation to
a close.
SUMMARY: Keep working towards answers to the questions!
Meeting close
Nigel: Thank you everyone, we're over time, let's adjourn.
[adjourns meeting]
Minutes manually created (not a transcript), formatted by
[18]scribe.perl version 121 (Mon Jun 8 14:50:45 2020 UTC).
[18] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 27 August 2020 16:37:27 UTC