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