14:01:58 RRSAgent has joined #tt 14:01:58 logging to https://www.w3.org/2018/07/05-tt-irc 14:02:00 RRSAgent, make logs public 14:02:00 Zakim has joined #tt 14:02:02 Meeting: Timed Text Working Group Teleconference 14:02:02 Date: 05 July 2018 14:02:33 Log: https://www.w3.org/2018/07/05-tt-irc 14:02:36 scribe: nigel 14:02:39 Present: Glenn, Nigel 14:02:50 tmichel has joined #tt 14:03:05 Regrets: Cyril, Andreas 14:03:09 Chair: Nigel 14:03:57 Glenn: Regrets from me for the next two meetings as I'm travelling, unless I'm in a connected location. 14:04:07 Present+ Pierre, Thierry 14:04:49 Topic: This meeting 14:05:14 Nigel: Today we have the usual order of agenda items: TTML1, TTML2, IMSC, CSS, 14:05:28 .. I'm not sure if there's anything on IMSC requirements or on WebVTT and don't 14:05:37 .. expect to cover those unless attendees want to. 14:05:54 .. Any particular topics anyone wants to cover, or "Other business"? 14:06:18 .. We have at least one agenda issue for TTML2 so they are already on the agenda. 14:06:25 group: [silence] 14:06:32 Nigel: Okay let's proceed. 14:07:13 Topic: TTML1 14:07:19 Nigel: Do we have any agenda points for TTML1? 14:08:24 .. Is it worth looking at action-513? 14:08:28 Action-513? 14:08:29 Action-513 -- Pierre-Anthony Lemieux to Look at ttml2 backporting to ttml1 3rd ed to see if we can change the ref from ttml2 to point to 3rd ed. -- due 2018-07-05 -- OPEN 14:08:29 https://www.w3.org/AudioVideo/TT/tracker/actions/513 14:08:43 Pierre: We're still making (editorial) tweaks to TTML2 so we should port those to TTML1 too. 14:09:10 Glenn: My key concern is timing. Philippe's tool says the earliest date we could go 14:09:24 .. to Rec for TTML2 on 13th Sep. If we are to do that then we also need to go to a 14:09:28 .. final CR on TTML1. 14:09:41 Pierre: Can we go to a final CR on TTML1? Is there any change to TTML2 for CR2 14:09:50 .. that can't be done non-normatively on TTML1? 14:10:04 Glenn: I see, could we track TTML1 and TTML2 editorial changes together? 14:10:07 Pierre: Exactly. 14:10:19 .. Is there an easy way to see the substantive changes from TTML2 CR1 to CR2? 14:10:27 Glenn: The change document is fully up to date now. 14:11:05 -> https://www.w3.org/TR/ttml2/ttml2-changes.html TTML2 Change Summary 14:11:12 Nigel: That's from the published CR2 14:11:27 .. It's pretty detailed in terms of the technical changes. 14:12:14 Pierre: Glenn, do you know any that would have an impact where we changed our mind, 14:12:25 .. things we did between CR2 and CR1 that should be reflected in TTML1 3rd Ed? 14:12:33 Glenn: I can't do that in real time, I would have to review them. 14:12:43 .. The only one that might would have to do with lineHeight. I'd rather keep hands off 14:12:53 .. on that. My general view is that none of the changes we've made in CR2 must 14:13:00 .. necessarily go back in TTML1 at this point. 14:13:13 Pierre: Can we look at tts:lineHeight right now? To see if they are incompatible or if 14:13:18 .. TTML1 3rd Ed is bad here? 14:13:31 Glenn: I don't see a necessity to backport anything. Whether it is desirable or not is a 14:13:39 .. different story. I'm not ready to say either way on that right now. 14:13:51 Pierre: So if today we referenced TTML1 3rd Ed from TTML2 would you be happy? 14:13:56 .. Assuming both go to PR together. 14:14:07 Glenn: I wouldn't say today but would be prepared to make a decision before July 26. 14:14:17 .. Between now and then I will have a chance to review. 14:14:30 Pierre: I think it's desirable, right, because we know 2nd Ed has some incompatibilities 14:14:32 .. with TTML2. 14:14:42 Glenn: My only concern is there's a finite risk in doing that. Say for example we go to 14:14:54 .. PR with both on the same day, and for some reason TTML1 3rd Ed fails to have support 14:15:18 .. to go to the next step, e.g. the AC votes for TTML2 but not for TTML1 3rd Ed. 14:15:30 Pierre: There's an equal risk that the AC votes down TTML2 because it does _not_ 14:15:35 .. reference TTML1 3rd Ed. 14:15:41 Glenn: We don't have an objection so far. 14:15:49 Pierre: I think both scenarios have comparable really low risk. 14:15:56 Glenn: I agree, I just don't want to make a decision today. 14:16:08 Pierre: I propose to make a tentative decision today to ref 3rd ed and unless someone 14:16:21 .. comes up with a reason not to do it then we can revert. 14:16:35 Glenn: I'm not comfortable to make a firm decision today without reviewing. 14:16:47 .. I suggest Pierre opens a PR milestone issue on TTML2 that proposes updating the 14:16:49 .. reference. 14:17:00 .. That way we can track it. If we make that change then we can say we have a comment 14:17:02 .. asking for that. 14:17:05 Pierre: I'll do that. 14:17:27 Nigel: I would be in favour of changing the reference to TTML1 3rd Ed. Actually I would 14:17:42 .. take some persuading _not_ to do that. My understanding of our work on 3rd Ed has 14:18:00 .. always been that the goal is to reduce the delta between TTML2 and TTML1 so it has 14:18:10 .. been my working assumption we would do so, and it looks like an oversight that we 14:18:14 .. have not already made the change. 14:18:55 nigel_ has joined #tt 14:20:16 Action-513: Pierre to raise issue on ttml2 to change reference to TTML1 3rd Ed; all to review to check this does not cause any problem. 14:20:16 Notes added to Action-513 Look at ttml2 backporting to ttml1 3rd ed to see if we can change the ref from ttml2 to point to 3rd ed.. 14:20:39 Nigel: Anything else on TTML1? 14:20:46 .. We're still waiting for tests I recall. 14:20:53 Topic: TTML2 14:21:07 action-443? 14:21:07 action-443 -- Glenn Adams to Prepare a document showing mapping arib ruby extension features to ttml2 for use as a liaison document to arib. -- due 2018-07-05 -- OPEN 14:21:07 https://www.w3.org/AudioVideo/TT/tracker/actions/443 14:21:49 Glenn: I haven't been able to get to that yet. I can draft something really short without 14:21:53 tm has joined #tt 14:22:00 .. substance in it that we can pass on to ARIB telling them that TTML2 has features that 14:22:15 .. intersect with ARIB-TT and offers support for some of the functionality; we're in CR2 14:22:25 .. taking further comments for editorial changes etc etc. 14:22:37 .. If the purpose of this is simply to notify ARIB folks that they might want to look at it 14:22:47 .. I'd rather put the onus on them than continue to bear the burden to describe how 14:23:02 .. TTML2 could possibly be used in their context. That would require me to go heads 14:23:12 .. down reviewing a Japanese document which is time consuming for me. 14:23:17 Nigel: They do have an English translation. 14:23:30 Glenn: In any case I'd rather put the onus on them - I have a lot on my plate. 14:23:47 Nigel: That's fair, if you can do that please then I will get that to them as soon as possible. 14:23:50 Glenn: Okay. 14:24:17 Action-443: Glenn to prepare non-detailed message for use as a liaison message; Nigel to send. 14:24:17 Notes added to Action-443 Prepare a document showing mapping arib ruby extension features to ttml2 for use as a liaison document to arib.. 14:25:28 Nigel: Glenn, please could you give us a quick status update on the TTML2 tests that 14:25:40 .. you've been adding lately? 14:26:00 Glenn: I've been focusing on making sure there are minimally adequate tests for use 14:26:13 .. in validation processes with both positive and negative validation results for the new 14:26:24 .. features. Once I've done that I'll do the same for presentation semantics. 14:26:36 Nigel: Thanks, can you give us a sense of how far through that work you might be? 14:26:49 Glenn: I've got tests for most of the tests but have to go through and tweak them to 14:26:59 .. make sure they are self-consistent with each other in scope and are correct, so the 14:27:12 .. verification process is about 30-40% complete for the validation tests right now. 14:27:22 .. In some cases I'm adding new validation tests when there's something lacking. 14:27:41 .. If I can do 4 hours a day on this I can usually knock off 10-20 features. Since we only 14:28:04 .. have 255-114 = 141 new features I can probably knock them all off in a week of 14:28:14 .. focused work. Depends how much time during my holiday I will have! 14:28:41 Nigel: Do you want to delegate any of them to anyone else? 14:28:52 Glenn: I'm working behind the scenes with Cyril who is doing the same with Netflix 14:29:06 .. internal representations however he will be out for most of July too. Obviously it 14:29:19 .. needs to be done by August 9th for sure. 14:29:29 Nigel: Yes, and obviously people need time to run the tests and report on them. 14:29:32 Glenn: That's true. 14:29:53 .. I'm also marking features on the spreadsheet Cyril circulated on green. I've not yet 14:30:04 .. augmented that spreadsheet to show which tests go with which features however it 14:30:18 .. is fairly self-evident which tests go with which features if you look in the repository 14:30:22 .. right now. 14:30:30 Nigel: Any other questions or comments on that? 14:30:34 Nigel: Thank you by the way! 14:31:09 Nigel: We have 3 open issues marked for the agenda. 14:31:42 -> https://github.com/w3c/ttml2/labels/agenda TTML2 issues for the agenda 14:32:26 Topic: Fix typo (#857). ttml2#866 14:32:32 github: https://github.com/w3c/ttml2/pull/866 14:32:43 Glenn: This doesn't need Andreas's review in my opinion, it is just a typo fix to change 14:32:55 .. "extended area" to "extended rectangle" which is the term used in XSL-FO and was 14:32:56 .. intended. 14:34:06 Nigel: I'd still like to give Andreas a week to review it - if he hasn't managed to by 14:34:11 .. then then I will go ahead and approve it. 14:34:14 Glenn: Ok 14:34:33 Topic: Clarify that construct effective {content,processor} profile is performed only once. ttml2#860 14:34:39 github: https://github.com/w3c/ttml2/issues/860 14:34:50 Glenn: Nigel you don't want to comment there at all and I want to address my original 14:35:02 .. issue, which is that absent a comment some readers might incorrectly assume that 14:35:15 .. it is possible to change ECP or EPP over the lifetime of document processing, and the 14:35:24 .. semantics of validation processing assume constancy. 14:36:03 .. applies to document transformation and processing. 14:36:14 .. The assumptions are there and we don't document those very well, and at this point 14:36:20 .. an informative note is the least I could do about that. 14:36:21 tmichel has joined #tt 14:36:36 .. In order to address one of your concerns (maybe) I tweaked this last night by adding 14:36:47 .. another note that goes in the top of the conformance section and says the conformance 14:36:59 .. requirements are scoped to implementations that operate on a static instance. 14:37:12 .. Processors that modify documents are not governed except that a final document 14:37:22 .. should satisfy conformance (paraphrased). 14:37:51 .. During the interim stages of authoring and editing all bets are off basically. 14:38:04 .. The second thing is for the two notes I added I qualified them to say "for the purpose 14:38:14 .. of complying with generic processor conformance ..." to scope those informative 14:38:24 .. statements to generic processor conformance processing. 14:38:43 Nigel: I haven't had a chance to review those recent changes, but my position is that 14:38:49 .. the issue simply doesn't exist. 14:40:28 Nigel: I don't see what problem this is solving, it seems too complicated and unnecessary. 14:40:34 .. I think we should simply say nothing. 14:40:49 Glenn: Most of the comments fall in the category of "it's obvious or wrong" and there's 14:41:01 .. no requirement that all notes are correct. You're stating that it could be wrong is in 14:41:13 .. my opinion based on some generalised fear that we're going to say something wrong 14:41:27 .. that is premature. Most notes are "for the avoidance of doubt take note..." but here 14:41:37 .. we have two important assumptions that are not so obvious at all. The fact that we 14:41:52 .. only perform document validation once and abort if unsupported profile once, for some 14:42:08 .. readers it would not be obvious that the parameters used can not change. They may 14:42:20 .. make the wrong assumption like maybe you have that they can change within a single 14:42:31 .. processing session. In our scope we have some assumptions that they are constant 14:42:47 .. because if they are not then all bets are off. All the semantics assume that if it is 14:43:02 .. valid once it remains valid. I don't know how you can say it is obvious or wrong. Not 14:43:13 .. adding the note does not address the concern I have raised even if you don't think 14:43:29 .. it is an important concern. When I read the spec recently, I saw there are a number of 14:43:40 .. paths in the spec to those procedures. One might get the wrong impression that they 14:43:53 .. might be evaluated multiple times and come up with different answers. I wanted to 14:44:05 .. make it documented that that is not the intention. 14:44:10 Nigel: I agree that it is not the attention. 14:44:19 Glenn: How do we document it in a way that addresses your concerns? 14:44:44 Nigel: If you're insisting on adding some text then we need to add some scoping text 14:45:08 .. perhaps like what you have done (I need to review) essentially creating the abstract 14:45:20 .. concept of a validation session within which everything is held constant and the 14:45:38 .. outcome does not change on re-evaluation (and indeed such re-evaluation is unnecessary). 14:45:54 Glenn: Not just a validation session but also scope of computing the results of the 14:46:05 .. processor profile effect on the document, e.g. abort semantics. You cannot decide 14:46:17 .. not to abort at one point because all required features are satisfied and later on 14:46:21 .. decide that you should abort. 14:46:35 Nigel: There are different reasons for aborting. 14:46:49 Glenn: The only cases are to do with validation and lack of support for required features. 14:47:03 .. Those are two different use cases with different paths to those at different points in time. 14:47:16 Nigel: Okay, anyone else have comments on this? 14:47:19 group: [silence] 14:47:33 Nigel: In that case the action is with me to review and potentially propose further changes. 14:48:12 SUMMARY: @nigelmegitt to review recent commits. 14:48:39 Topic: Unicode bidi should probably not be animatable. ttml2#881 14:48:46 github: https://github.com/w3c/ttml2/issues/881 14:49:17 Glenn: If we're open to changing the animatability status of properties as non-normative 14:49:27 .. changes I'm certainly okay with this and if we do that then I would like to radically 14:49:33 .. reduce the set that is continuously animatable. 14:49:44 .. There's also another problem that we use the terms discrete and continuous right now 14:49:58 .. in each property. Previously we had discrete or none in TTML1 since we did not have 14:50:01 .. any form of continuous. 14:50:17 .. There are actually 2-3 kinds of continuous animation available, linear, paced and spline. 14:50:32 .. The paced animation limits the application in SMIL and SVG to a tight set of potential 14:50:42 .. features that have reasonable interpretations under those semantics. We have not 14:50:55 .. so far attempted to delineate what continuous means in our property definition tables. 14:51:10 .. For example linear-spline, linear-paced and linear-spline. In fact discrete is a 14:51:25 .. calculation mode in animation as well. In retrospect we have not done a very good 14:51:34 .. job in specifying the animatability of these properties. 14:51:46 .. One of the difficulties of implementing them is whether or not it triggers relayout. 14:52:00 .. For instance fontSize can be animated in implementations, and some CSS and SVG 14:52:12 .. implementations do that, however whenever you do font size changes the content 14:52:21 .. needs to be relaid out. It complicates the implementations. 14:52:31 .. To the extent that we rely on CSS and SVG implementations supporting this as opposed 14:52:45 .. to requiring TTPE or IMSC.js to perform multiple layouts along discrete time events 14:52:57 .. for example on every frame, that's definitely going to impact performance and other 14:53:09 .. factors. If we are going to change any of the animatability of properties I would 14:53:21 .. propose that we scale back to only a few properties for continuous animation namely 14:53:33 .. color, opacity and position. 14:53:55 .. The other one is potentially for gain and pan, which have reasonable interpretations 14:54:05 .. for continuous animation and don't require relayout. 14:54:23 .. I would also be okay to go out the door today. 14:54:36 .. We have not defined any features that tie the animatability of specific features to their 14:54:44 .. animation calculation mode. 14:55:13 Nigel: We have already marked `#animation-verion-2` as at risk, so we could argue that 14:55:25 .. removal of some animation semantics is reasonable as a result of implementation 14:55:30 .. feedback when we go to PR. 14:55:34 Glenn: I like that approach. 14:55:44 Pierre: Works for me. 14:55:58 .. I was reviewing the Process document and there's no way to make substantive 14:56:10 .. changes between CR and PR. Given our timetable, unless it is fatal we should capture 14:56:21 .. those issues and proceed with a 2nd Ed immediately. 14:56:30 Glenn: There is an exception as Nigel mentioned. 14:56:46 Pierre: Absolutely. I would rather deal with stuff that can be dealt with as at risk, that's better. 14:57:00 Glenn: This would be a case where we can address a comment as somewhat short of 14:57:12 .. full removal of a feature. I don't think there's anything that deals with this nuance so 14:57:24 .. it's probably worth Nigel running it by Philippe. 14:57:37 Nigel: Okay I'm happy to that. 14:58:07 SUMMARY: @nigelmegitt to check with @plehegar if partial removal of at risk features might be okay. 14:58:21 Glenn: Otherwise we could always deprecate or clarify or both in TTML2 2nd Ed. 14:58:37 .. By the way writing-mode was already excluded from animation in CSS. 14:58:52 Nigel: It's discretely animatable. 14:58:55 Glenn: That's ok. 14:59:27 .. In my perspective we should review all the continuous cases and scale some of them 14:59:38 .. back to discrete. We should also add a note that continuous means linear, paced or 14:59:50 .. spline depending on the property and in some cases paced may not apply. 14:59:52 Nigel: Makes sense. 15:00:03 Glenn: The alternative is to remove continuous and simply list all the possible 15:00:13 .. calculation modes depending on the case. That would be more explicit. 15:00:17 Nigel: Agreed. 15:00:31 .. I just want to come back to the point about audio gain and pan properties - it is 15:01:17 .. almost completely pointless from an audio description perspective to have gain or 15:01:37 .. pan that cannot be continuously animated. The only possible get-out is if implementations 15:01:51 .. are given the freedom to process discrete animations as continuous, but that's not ideal. 15:02:15 Glenn: Of the 4, we've said gain, pan and pitch are continuous and speak is discrete. 15:02:20 .. That's what we have right now. 15:02:30 Nigel: I'm not so bothered about pitch as I don't see a use case. 15:03:52 SUMMARY: Several style properties probably are marked as continuously animatable but should not be. 15:04:18 Nigel: Does IMSC 1.1 allow for any continuous animation? 15:04:22 Pierre: It does not. 15:04:26 Nigel: Okay then it is not affected. 15:05:21 Topic: Add #opacity-image feature. ttml2#883 15:05:26 github: https://github.com/w3c/ttml2/issues/883 15:05:44 Glenn: Right now @spoeschel and myself are having a dialog. We have `#opacity-block` 15:06:00 .. and `#opacity-inline`. The problem is that we have tied those to content elements 15:06:10 .. and in our definition of content elements in the terminology they are tied to the 15:06:27 .. content class which does not include image right now. However image does describe 15:06:40 .. itself as defining block and inline areas depending on the context of use. 15:07:00 .. So we have a discrepancy. My plan is to editorially change the definition of the 15:07:20 .. term "Content element" in the terminology section to add the image element to the 15:07:23 .. set of content elements. 15:07:30 Pierre: What is the consequence of the current text? 15:07:46 Glenn: Right now content element as defined points at the content module... 15:07:57 Pierre: Imagine it were published as is today, what would be the consequence of the 15:08:05 .. issue that Stefan raised, practically? 15:08:14 Glenn: There's no way to require specifically the combination of opacity and image 15:08:22 .. unless we make this minor tweak. 15:08:26 Pierre: I don't think that's fatal. 15:08:41 Glenn: I agree and that's what I suggested to Stefan, it is arguable whether we need 15:08:51 tm has joined #tt 15:08:52 .. a combined feature in the first place. 15:09:03 Pierre: I would log this as an issue to be deferred to 2nd ed and move on. 15:09:07 Glenn: That works for me. 15:09:16 Pierre: I'm concerned with tweaking the definition of content element. 15:09:53 Glenn: Right now table 5-3 in section 5.4.1 core catalog defines the modules. 15:10:11 Nigel: Changing that feels normative and I'd be concerned about the impact. 15:10:25 Pierre: A change to core definition, and how set and timing is applied are all intertwined. 15:10:32 .. My inclination is to say move to 2nd Ed. 15:10:43 Glenn: One of the problems if we don't do anything is there are many cases where we 15:10:53 .. use content element as a phrase and we really mean it includes image as well and 15:10:58 .. we have failed to note that. 15:11:11 .. One way to handle it is to add an informative note that our intention is also to include 15:11:16 .. image without making it normative text. 15:11:29 Pierre: As you know the layout, style inheritance etc have specific conditions based 15:11:36 .. on content element and we would have to review. 15:11:42 Glenn: In many cases they mention image. 15:11:55 Pierre: We spent a lot of time reviewing it in the past. If the only consequence is there 15:12:07 .. is a bit of ambiguity about the application of opacity on image that does not sound 15:12:11 .. like a blocker to me. 15:12:31 .. It's fine to defer it and even open a pull request for 2nd ed. Unless it is fatal I think 15:12:37 .. it sounds super-risky, even to add a note. 15:15:03 Glenn: I intended to make the `#opacity-block` and `#opacity-inline` features to 15:15:16 .. include image but did not explicitly check that the definition included it. 15:17:43 tmichel has joined #tt 15:18:04 Nigel: I'm with the view that we should not make a change now here, for two reasons: 15:18:20 .. 1. If anyone really needs a feature designator they can extend a current one, if we 15:18:31 .. have not already introduced it in a future edition. 15:18:47 .. 2. Introducing the proposed change now puts us at high risk of accidentally making 15:18:55 .. a substantive change with very small benefit. 15:19:07 .. I also think it is very unlikely that anyone will request this feature designator. 15:19:11 Glenn: Oka. 15:19:14 s/a/ay 15:19:36 PROPOSAL: Defer this until ttml.next 15:19:39 Glenn: Ok 15:19:47 Pierre: I'm fine with that too. 15:19:52 RESOLUTION: Defer this until ttml.next 15:20:01 github-bot, end topic 15:20:47 Topic: Clarify 'any attribute' language (#879). ttml2#880 15:20:52 github: https://github.com/w3c/ttml2/pull/880 15:21:06 Glenn: This changes "any attribute" to "any attributes" inside curly braces where we 15:21:12 .. mean any one or more attributes. 15:21:24 Nigel: I expect that's all the clarification that is needed. 15:21:34 Glenn: As an FYI this syntax comes from the XML schema specifications. 15:21:48 .. For the curly braces. There's also some usage in CSS to refer to a collection of 15:21:56 .. characters, that we use in a couple of places. Just a historical note. 15:22:18 Nigel: I will get around to reviewing that in the course of things. 15:22:22 Pierre: I think it's an improvement. 15:23:14 github-bot, end topic 15:23:33 Topic: IMSC 15:23:47 s/TTML1 3rd Ed and TTML2 15:23:56 s/IMSC/TTML1 3rd Ed and TTML2 15:24:19 Pierre: I reviewed this and think the only thing is the interpretation of lineHeight="normal". 15:24:39 .. I think the text today in TTML1 3rd Edition is incorrect because it talks about the 15:24:51 .. computed value being considered to be no less than the largest font size of the element 15:24:59 .. and all its descendants in the ISD. 15:25:13 Glenn: That is in direct contravention of CSS that says the computed value of 15:25:27 .. line-height: normal is normal. That's why I had to make the change in TTML2. 15:25:39 Pierre: The bigger issue is the text in TTML2 does not mention descendants whatsoever. 15:25:46 Glenn: That was intentional because it is wrong. 15:25:59 Pierre: Exactly, right, so the text in TTML1 3rd Ed is bad today and unfortunately there 15:26:11 .. is a must there so that really has to be corrected in 3rd Ed. 15:26:29 .. That is the only change I know of. 15:26:43 Glenn: By the way this language originated in CSS and XSL-FO, the discussion of 15:27:01 .. descendants in line-height, at least partially. If you look at the CSS 2.1 or 2 definition 15:27:23 .. of lineHeight there's a phrase or sentence [UAs may determine the line height according 15:27:36 .. to the largest font size], but an element can only have one font size so it can only 15:27:47 .. really mean the largest among descendants, or among children. 15:27:56 Pierre: or the largest glyph size. 15:28:07 Glenn: Needless to say it is highly ambiguous and we already have statements from CSS 15:28:15 .. folk is that it's at least partially wrong. 15:28:31 Nigel: We need to come to what we do about it in TTML1. 15:28:37 Glenn: The problem is the word "must". 15:28:50 Pierre: We could start a CfC today. 15:28:56 Nigel: Can someone open a pull request first? 15:29:08 Glenn: What would that do to the timeline for TTML1 going to PR? If it requires going 15:29:15 .. to CR again that would be a problem. 15:29:17 Pierre: Why? 15:29:30 Glenn: It would reset the date on the timer for the 3rd Ed. 15:29:46 Pierre: We don't need a CR3 on TTML2 I think. 15:29:58 .. We need a CR2 for TTML1 because it is a change on TTML1. 15:30:19 Glenn: If you do that it will alter the timing and we cannot update the reference. 15:30:28 Pierre: I'm fairly certain that we will not need a new CR for TTML2 15:30:37 Nigel: I agree. 15:30:49 Glenn: I'm saying to go to Rec on TTML2 with a reference to TTML1 3rd Ed would be 15:30:55 .. delayed until TTML1 3rd Ed goes to Rec. 15:31:02 Pierre: There's a 2 week difference right now. 15:31:52 Nigel: I feel that there may be a way (depending on Philippe or Thierry) to finesse this 15:32:05 .. so that there is no adverse effect on the Rec publication date for TTML2. 15:32:41 Pierre: I think we should explore trying to be more efficient with Philippe and/or Thierry. 15:32:51 .. Even if there is a delay it is procedural between PR and Rec. 15:33:03 Glenn: My understanding is there's a 60 day exclusion period that gets reset when you 15:33:05 .. do a new CR. 15:33:11 Pierre: We just did CR2 for TTML2. 15:33:29 Glenn: From what I hear from Philippe, one substantive change to a CR triggers a new 15:33:34 .. 60 day exclusion period. 15:33:38 Nigel: What's the problem with that/ 15:33:43 s|/|? 15:34:31 Glenn: A new CR today would put TTML2 Rec into October. I've made commitments 15:34:41 .. to go to Rec in September so I'm not prepared to agree with a delay. 15:34:56 Pierre: There would be no change to the document, this is just procedural. 15:35:14 .. I encourage you to check with your clients. 15:35:25 .. TTML2 referencing an obsolete spec is bad. 15:35:40 Nigel: As mentioned earlier in this meeting that does itself represent a risk. 15:35:52 Glenn: I am going to have to object if there is one day delay to TTML2. 15:36:09 Pierre: I encourage you to check with your clients to see if that is really a blocking issue 15:36:16 .. and would be happy to talk to them about that. 15:36:26 Glenn: Based on my current commitment that is my position right now. 15:36:49 .. If we can agree that the 60 day period does not apply, for example noting that it is 15:37:05 .. an error not to match XSL-FO or CSS, with Philippe, then that could help. 15:38:46 .. I think our long-standing goal is to publish TTML1 3rd Ed and TTML2 at the same time. 15:39:26 Nigel: A concrete proposal in the form of a pull request on TTML1 3rd Ed would be 15:39:57 .. very helpful in terms of the discussion with W3 staff. 15:40:08 Pierre: I will do that immediately and recommend we start a 2 week clock today. 15:40:15 Glenn: I'm okay with that pending the PR being merged. 15:40:36 Pierre: I will copy the exact text from TTML2 minus the non-applicable text. 15:40:43 Glenn: It's not a must-have for me to fix it. 15:40:59 .. You could put an informative note in saying it should be "may". 15:41:06 Pierre: Let's first check what our options. 15:41:10 s/./are. 15:41:37 Nigel: I think that's as far as we can go on this right now. 15:41:53 Topic: IMSC 15:41:59 Nigel: A reminder we are mid-way through the CfC. 15:42:05 Pierre: There are 2 pull requests awaiting approval. 15:42:19 .. One has been approved by Cyril but it touches on an issue close to your heart Nigel 15:42:24 .. so you might want to look at it. 15:42:35 .. The other I think is good to go but is missing an approval. 15:42:43 Nigel: I will prioritise those so they can be merged. 15:42:53 Pierre: I don't think they are controversial. 15:43:20 Nigel: Anything else to raise on IMSC 1.1 for the CfC? 15:43:24 group: [silence] 15:43:33 Nigel: If there are comments then please raise on the repo. 15:44:09 .. Do we need to cover the pull request on the imsc-vnext-reqs? 15:44:21 Pierre: No, I think I just need to make a small change as per your suggestion Nigel. 15:44:23 Nigel: okay. 15:44:37 Topic: CSS actions 15:44:40 action-512? 15:44:40 action-512 -- Pierre-Anthony Lemieux to Raise an issue with css wg requesting support for lineshear -- due 2018-07-05 -- OPEN 15:44:40 https://www.w3.org/AudioVideo/TT/tracker/actions/512 15:45:12 Nigel: CSS has been discussing shear and I added a reference to the CSS issue on 15:45:19 .. fonts-4 in the agenda. 15:45:45 -> https://github.com/w3c/csswg-drafts/issues/2869 [css-fonts-4] oblique angle for synthesis in vertical text 15:46:27 Pierre: I have not done anything on this yet. Is there an urgency? 15:46:37 Nigel: Only for getting CSS support for things that will end up in IMSC! 15:46:46 Pierre: The two fundamental issues for IMSC 1.1 is: 15:46:53 .. 1. Only Firefox has good support for Ruby. 15:46:55 s/is/are 15:47:08 .. 2. Arabic rendering does not work across spans in WebKit. 15:47:18 .. In practice that is probably a much bigger issue. 15:47:23 .. But yes I have to file those things. 15:48:02 Nigel: I imagine CSS WG has been meeting this week because there has been a burst 15:48:08 .. of activity. It's worth keeping your eye on. 15:49:25 Topic: Meeting close 15:49:48 Nigel: We've completed our agenda today so I'll close the call. Thanks everyone! [adjourns meeting] 15:49:54 rrsagent, make minutes 15:49:54 I have made the request to generate https://www.w3.org/2018/07/05-tt-minutes.html nigel 16:04:04 s|s/TTML1 3rd Ed and TTML2|| 16:04:07 rrsagent, make minutes 16:04:07 I have made the request to generate https://www.w3.org/2018/07/05-tt-minutes.html nigel 16:04:24 s/github-bot, end topic//g 16:04:25 rrsagent, make minutes 16:04:25 I have made the request to generate https://www.w3.org/2018/07/05-tt-minutes.html nigel 16:19:08 scribe+ nigel_ 16:19:10 rrsagent, make minutes 16:19:10 I have made the request to generate https://www.w3.org/2018/07/05-tt-minutes.html nigel 16:20:05 s/scribe+ nigel_/ 16:20:12 scribe: nigel_ 16:20:14 rrsagent, make minutes 16:20:14 I have made the request to generate https://www.w3.org/2018/07/05-tt-minutes.html nigel 16:21:50 i/Action-513/scribe: nigel_ 16:21:52 rrsagent, make minutes 16:21:52 I have made the request to generate https://www.w3.org/2018/07/05-tt-minutes.html nigel 16:23:40 i/Glenn: I've been focusing/scribe: nigel 16:23:48 rrsagent, make minutes 16:23:48 I have made the request to generate https://www.w3.org/2018/07/05-tt-minutes.html nigel 16:25:06 scribeOptions: -final -noEmbedDiagnostics 16:25:07 rrsagent, make minutes 16:25:07 I have made the request to generate https://www.w3.org/2018/07/05-tt-minutes.html nigel 16:27:39 Zakim has left #tt