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
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: 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: https://github.com/w3c/tt-profile-registry/issues/76
Mike: If we all look at my comment on #71 from two days ago:
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: 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]