23:41:01 RRSAgent has joined #tt 23:41:01 logging to http://www.w3.org/2015/10/28-tt-irc 23:41:02 olivier has joined #tt 23:41:03 RRSAgent, make logs public 23:41:03 Zakim has joined #tt 23:41:03 akitsugu has joined #tt 23:41:05 Zakim, this will be TTML 23:41:05 I do not see a conference matching that name scheduled within the next hour, trackbot 23:41:06 Meeting: Timed Text Working Group Teleconference 23:41:06 Date: 28 October 2015 23:41:24 chair: nigel 23:42:27 Present: olivier, andreas, akitsugu, nigel, glenn, zcorpan, pierre 23:42:32 glenn has joined #tt 23:42:36 rrsagent, this meeting spans midnight 23:48:20 scribe: nigel 23:48:28 Topic: Introductions 23:48:35 Simon Pieters, Opera 23:48:42 Nigel Megitt, BBC 23:48:48 Olivier Thereaux, BBC (obs) 23:48:50 Glenn Adams, Skynav 23:48:57 Akitsugu Baba , NHK 23:49:20 dae has joined #tt 23:49:25 s/NHK/NHK (obs) 23:49:38 prsent+ dae 23:49:42 present+ dae 23:49:54 s/prsent+ dae/ 23:50:07 atai2 has joined #tt 23:50:14 Dae: Netflix 23:50:36 Institut für Rundfunktechnik 23:50:56 s/Institut/Andreas Tai, Institut 23:52:25 pal: Pierre Lemieux, MovieLabs 23:52:43 Topic: Agenda Review 23:53:09 nigel: Goes through agenda. Any proposals to change it? 23:53:26 pal has joined #tt 23:53:30 pal: What are we trying to achieve on each of these topics? 23:54:02 atai2: Can we go for TTML <--> WebVTT mapping immediately after lunch? 23:54:18 ... Also tomorrow morning before IMSC can we have a session on industry feedback on TTML? 23:54:50 ... Apart from the mapping, are there any other topics we should cover re WebVTT? 23:55:10 zcorpan: I thought also we should have a session on WebVTT. 23:55:26 nigel: When would be a good time to do that? 23:55:45 zcorpan: Maybe this afternoon. The main thing I want to talk about is how we publish 23:56:00 ... working drafts, and having a single URL for ED and /TR WD snapshot. 23:56:33 nigel: That fits with the tools discussion.. 23:56:37 zcorpan: Can we move that to today? 23:58:57 nigel: I wanted plh to come along for the tools part. 00:30:20 Topic: HTMLCue proposal 00:32:25 nigel: Introduces topic - history of this coming from Glenn and Erik Lindstrom of Opera. 00:32:54 ... The idea being to use the timing abilities of TextTrackCue to do generic HTML presentation. 00:33:15 ... We sent a proposal to WHATWG and in summary the response was that there are 00:33:24 ... things that we need to think about, and possible unintended consequences. 00:33:43 atai2: We also wanted to get developer/implementor views, which we did yesterday. 00:33:59 nigel: Yes, yesterday I ran a breakout session on the topic, minutes at 00:34:07 ... http://www.w3.org/2015/10/28-htmlcue-minutes.html 00:34:14 ... which had good attendance. 00:35:47 zcorpan: There were a few misunderstandings. One was that the HTMLSpec had a 00:36:05 ... 250ms potential delay for notifying when a cue was rendered in Javascript. In fact 00:36:19 ... that was an unrelated event called timeUpdate. There are separate cue enter and 00:36:33 ... cue leave that have accurate timings, so Javascript events aren't going to miss a cue. 00:37:07 ... The other conclusion was that instead of using HTMLCue it is a better idea to have 00:37:22 ... the js parse the cue data and then render it on top of the video and not have the 00:37:26 ... browser do that. 00:37:51 ... Going back a step, one of the reasons is that the track element is not capable of 00:38:04 ... executing scripts currently, or of referencing external references from the subtitle 00:38:16 ... track itself. The assumption is, like the img element, including a subtitle file is safe 00:38:27 ... and cannot do anything. If we allow html inside a subtitle track it can suddenly do 00:38:39 ... lots of things that could be a security or privacy problem or both, so it is unlikely 00:38:47 ... that browser vendors are going to jump at implementing it. 00:38:57 glenn: Of course we're not making the assumption that it is necessary to process 00:39:09 ... scripts or fetch resources. It's possible to put restrictions on how the HTML is 00:39:11 ... processed 00:39:25 zcorpan: As Ted pointed out, safely subsetting HTML is extremely hard and it is 00:39:39 ... probably a bad idea to do that - it's easier and safer to start from zero and add things. 00:39:52 glenn: We already know about flags like sandbox flags that control the context. 00:40:05 ... It would be one thing if we were introducing a whole new type of sandbox rather than 00:40:18 ... using the existing mechanisms that are already implemented. For example, if we 00:40:32 ... triggered it as a sandboxed feature, would that raise the same issues? 00:40:47 zcorpan: The current sandbox was not designed as a be-all security feature, but as a 00:41:04 ... defence in depth feature for when untrusted content is also sanitised on the server, 00:41:18 ... to catch bugs. Also there is no sandbox value that does what we want to do. It will 00:41:29 ... still fetch external resources for instance. So we still have the problem of defining 00:41:34 ... what is the safe subset of HTML. 00:41:52 atai2: I think there are 2 different views - one is on the feasibility of the technical solution, 00:42:05 ... and the other is how to proceed. We wanted to get browser side perspective, 00:42:24 ... but nobody stood up from the browser community to say possibly this is feasible 00:42:40 ... instead the view was to use WebVTT with metadata payload and have js then 00:42:50 ... render the HTML. For us it would be important to decide what to do. One proposal 00:43:05 ... would be to follow this concept and see if that works for our use case. 00:43:26 zcorpan: As an aside, the same technique would work for ad display also. 00:44:46 nigel: This technique is to use a TextTrack whose kind attribute is metadata, then have 00:45:06 ... javascript pull out the HTML data and render it on the onenter(). The objection I raised 00:45:35 ... was that this subverts the purpose of the kind attribute and prevents accessible 00:45:52 ... solutions from knowing that tracks are intended for display for accessibility. 00:46:12 ... There was an action that Ted proposed to raise a feature request on this... 00:46:28 zcorpan: Yes, I can take an action item on that, to expose the accessibility preferences 00:46:46 ... to Javascript so that scripts can honour the user preference. 00:47:45 Action: zcorpan Raise an issue on the HTML spec to add an API to expose the user preference 00:47:46 Created ACTION-440 - Raise an issue on the html spec to add an api to expose the user preference [on Simon Pieters - due 2015-11-05]. 00:51:45 nigel: From an architectural perspective it still seems neater to me to keep TextTrack kind 00:51:58 ... for its intended purpose and to use different cue types to express different presentation 00:52:15 ... semantics - VTTCue is great for expressing how VTT cues should be presented 00:52:21 ... but not for other types. 00:52:35 zcorpan: I thought of another approach for HTML - to allow more than one value in the 00:52:53 ... kind attribute, for example "metadata subtitles" where the term "metadata" just means 00:53:08 ... 'not for direct rendering by the UA'. 00:53:23 atai2: I think we need to decide where to take this forward. 00:55:19 nigel: It feels too soon to stop this now - there's a suggestion from another browser manufacturer that they would be interested in doing some work here. 00:55:33 atai2: For me the next step is to analyse further the proposal to use metadata in this way. 00:58:06 nigel: It's worth noting that dash.js already uses this approach. They had to use VTTCue because it was the only text track cue that is implemented. 00:58:24 zcorpan: It's not overloading VTTCue - it was actually designed to support that. 00:58:40 atai2: Another part of the proposal is to use a VTT file to store the payload. 00:58:53 zcorpan: Yes, but you don't have to use a VTT file - you can get the cue data from anywhere 00:59:15 ... XHR, a WebSocket, or wherever. You just need a mapping between a cue and the payload. 01:00:55 nigel: So we have one action - any others? 01:01:08 atai2: It would be good to look in depth at the approach and see how well it works. 01:01:18 zcorpan: If you have any questions on that I'd be happy to help. 01:01:38 nigel: That feels like a mini task force to go and think about this and generate a small 01:01:40 ... document. 01:01:55 nigel: That's Andreas, Nigel and Simon. 01:02:36 Action: atai2 Kick off the analysis work on the VTTCue carrying HTML idea. 01:02:36 Created ACTION-441 - Kick off the analysis work on the vttcue carrying html idea. [on Andreas Tai - due 2015-11-05]. 01:03:50 Topic: TTML2 - Script layout, rubys etc. 01:08:36 glenn: http://www.w3.org/TR/css-ruby-1/#edge-effects 01:09:11 ... * ruby overhand 01:09:17 s/nd/ng 01:09:34 ... * ruby overflow 01:09:40 ... * ruby reserve 01:09:44 ... * ruby offset 01:10:12 glenn: The use case for adding ruby markup to TTML2 was to support the lamba cap semantics. 01:10:31 ... It turns out that there are a couple of edge cases that were not handled by CSS. 01:10:42 ... In some cases CSS discussed them. In addition the Japanese Language Requirements 01:10:55 ... document discussed them, and in others neither of them were discussed. We ended 01:11:36 ... up defining 5 different style properties - the 4 as listed above and ruby overhang class 01:12:11 In the case at the above URL there's an example where the 6 ruby characters take more 01:12:28 ... width than the base. So you need to know how to overhang. In the top example 01:12:41 ... white space is added around the base to make the width match, so there's no overhang. 01:12:59 ... In the next example (example 18) the text is allowed to overhang adjacent base 01:13:01 ... characters. 01:13:12 s/In the case/glenn: In the case 01:13:27 glenn: CSS doesn't define a mechanism to control the behaviour of the rendering process 01:13:42 ... Additionally there's ruby overflow, which comes up when you have the case of wider 01:14:02 ... ruby than the base and the context is a line edge boundary. (Figure 19) 01:14:15 ... Let's say you have a text alignment of start or left, then the base characters push up 01:14:39 ... against the left edge. If the ruby text is wider than the base, and you specify a ruby 01:15:01 ... alignment such as center. You can specify how the ruby box aligns with the base content. 01:15:18 ... You can specify start, end, center, distribute space between, distribute space around. 01:15:34 ... In this case if you want to center the ruby then you push the ruby box outside the line 01:16:00 ... box to maintain the alignment. The base text has priority the text alignment. You have 01:16:26 ... an over constrained environment, which causes the problem. There are two ways to 01:16:39 ... resolve the overflow. You can relax the base text alignment and allow it to be pushed 01:16:54 ... out away from the line edge so the ruby does not overflow. I call that shift base overflow. 01:17:08 ... That maintains the alignment between ruby and base. 01:17:25 ... The other way to do it is to keep the base alignment but relax the ruby alignment. 01:17:57 ... I call that shift ruby. The third option I defined was overflow, which does not relax 01:18:09 ... either constraint but allows the ruby to overflow the line area, in which case you have 01:18:22 ... to use the tts:overflow property. 01:19:01 nigel: Do we need to strengthen any of the language in tts:overflow to cover this use 01:19:41 ... case? Right now there are no 'SHALLs' in tts:overflow, only 'SHOULD's. 01:20:24 glenn: That's a good point. The question is here if you use overflow but the implementation 01:21:00 ... is always clipping then you're going to lose that. 01:21:15 nigel: Do we know why there are only SHOULDs now? 01:21:27 glenn: My recollection is that we weren't sure if implementations could do clipping so we 01:21:30 ... kept the language loose. 01:21:52 ... The CSS spec says "This level of the specification does not provide a mechanism to control this behaviour." 01:22:08 ... It turns out that this isn't sufficient for captions. We need a way to explicitly define this. 01:22:23 RRSAgent, make minutes 01:22:23 I have made the request to generate http://www.w3.org/2015/10/28-tt-minutes.html nigel 01:23:08 atai2: So would the shift base extend the containing box? 01:23:21 glenn: shift base would insert white space, i.e. padding, on the inside of that box to 01:23:34 ... move the base content across to maintain the ruby alignment that has been specified. 01:24:55 ... Then there's a question about where you allow overhang - everywhere or dependent on 01:25:08 ... the base. It turns out that the JLR document defines classes of characters where 01:25:16 ... overhang is permissible and where it is not permissible. 01:25:52 zcorpan has joined #tt 01:26:06 http://www.w3.org/TR/jlreq/#adjustments_of_ruby_with_length_longer_than_that_of_the_base_characters 01:26:27 glenn: This shows the case when the ruby text is no larger than the corresponding base. 01:26:56 ... So there's no problem when the ruby is less than or equal to the base size. You get 01:27:08 ... the problem when the ruby requires more inline space than the base. 01:28:05 ... Fig 3.79 shows this. When you do allow overhang. In one case a hiragana ruby is 01:28:20 ... permitted to overlap a hiragana base, but not on a kanji base - doing the latter could 01:28:43 ... be misread as the ruby applying to the kanji character. Hence beneath figure 3.80 01:28:56 ... the points a and b describe the rules. 01:29:12 ... Fig 3.81 and 3.82 show this. 01:29:49 nigel: Is this based on language dependent rules or do we need syntax to define it? 01:30:02 glenn: Ruby is primarily used in Japanese, very rarely in Chinese and more rarely still 01:30:26 ... in Korean. Technically one could use the same layout features in all of those languages. 01:30:39 ... It's even potentially useful in other languages that don't normally use ruby, like for 01:31:00 ... annotations, like a scholarly piece on Greek, "interlinear text". To handle the