14:58:28 <RRSAgent> RRSAgent has joined #tt
14:58:28 <RRSAgent> logging to https://www.w3.org/2019/06/13-tt-irc
14:58:30 <trackbot> RRSAgent, make logs public
14:58:30 <Zakim> Zakim has joined #tt
14:58:32 <trackbot> Meeting: Timed Text Working Group Teleconference
14:58:32 <trackbot> Date: 13 June 2019
14:58:44 <cyril> Agenda: https://github.com/w3c/ttwg/issues/42
14:58:47 <cyril> Chair: Nigel
14:58:51 <cyril> Scribe: Cyril
15:00:23 <nigel> Present+ Nigel
15:00:25 <cyril> Present: Cyril, Gary, Nigel
15:00:34 <nigel> Log: https://www.w3.org/2019/06/13-tt-irc
15:00:49 <glenn> glenn has joined #tt
15:02:06 <cyril> Present+ Andreas
15:02:14 <cyril> Present+ Glenn
15:02:16 <atai2> atai2 has joined #tt
15:02:18 <cyril> Present+ Pierre
15:02:35 <cyril> Topic: this meeting
15:03:16 <cyril> nigel: 2h meeting today
15:03:29 <cyril> ... we've got comments/questions following CfC on WebVTT
15:03:42 <cyril> ... a bunch of issues on TTML2
15:03:50 <cyril> ... an outstanding profile registry issue
15:04:07 <cyril> ... and an outstanding question for Philippe about the ICC profile
15:04:20 <cyril> ... lastly update on charter status dependent on Philippe
15:05:02 <cyril> ... in AOB we could discuss Karaoke
15:05:08 <cyril> ... and live and audio description
15:05:12 <cyril> ... if time allows
15:05:33 <cyril> Topic: WebVTT transition to PR
15:06:01 <cyril> nigel: plh sent a CfC last week
15:06:06 <cyril> ... one more week to go
15:06:13 <cyril> ... people have been looking at it
15:06:32 <cyril> ... queries have been coming regarding failing tests
15:06:43 <cyril> ... 1st one is text-wrap: balance
15:06:47 <nigel> -> https://lists.w3.org/Archives/Public/public-tt/2019Jun/0020.html Thread re text-wrap: balance;
15:07:02 <cyril> ... I noticed that there is a must requirement in the spec
15:07:16 <cyril> ... but there does not seem to be any implementation nor tests
15:07:28 <cyril> ... I'm struggling how we can progress on this one
15:07:52 <nigel> scribe: nigel
15:08:16 <nigel> Cyril: What is the policy re referencing other docs not at CR stage? text-wrap: balance is at WD.
15:08:38 <cyril> scribe: cyril
15:09:04 <cyril> nigel: in the past we have avoided from TTWG specs normative references to documents that are not in PR
15:09:19 <cyril> ... we haven't normatively referenced something that is at WD stage
15:10:15 <cyril> glenn: we definitely have not referenced WD or ED
15:10:20 <cyril> ... CRs are questionable
15:10:26 <cyril> ... would require justifications
15:10:39 <cyril> ... there have been some CRs that have become the status quo
15:11:23 <cyril> ... part of the problem is that membership of W3C has given its opinion before PR
15:12:03 <cyril> cyril: either we do an exception or change it
15:12:04 <glenn> s/has given/has not given/
15:12:36 <cyril> gkatsev: I've been working under the assumption that if WebVTT does not proceed to PR it will be removed from the charte
15:12:43 <cyril> s/charte/charter
15:13:15 <cyril> ... I would not have any problem removing it and going through another CR if it would be kept in the charter
15:13:24 <cyril> pal: that seems the logical thing to do
15:13:41 <cyril> gkatsev: removal from charter is my major concern
15:14:19 <cyril> pal: your concern is that if remove this feature, it would delay publication and risk being removed from the charter
15:14:24 <cyril> gkatsev: yes
15:14:32 <cyril> pal: where did we say that?
15:14:46 <cyril> nigel: it's a WG resolution
15:15:13 <cyril> ... that said, the tone that we've had from Philippe is that we'd rather delay the charter to have WebVTT in
15:15:33 <cyril> ... the charter update is more for the scope update
15:15:47 <cyril> ... we could delay the charter update
15:15:57 <cyril> pal: the current charter expires May 2020
15:16:20 <cyril> nigel: yes, but we've decide to proceed with documents that are not currently in charter
15:16:33 <cyril> ... so that would be annoying to have those documents delayed
15:17:11 <cyril> pal: so the concern is about a resolution that we passed
15:17:13 <nigel> -> TTWG Charter repo
15:17:22 <nigel> s/-> TTWG Charter repo//
15:17:27 <nigel> -> https://github.com/w3c/charter-timed-text TTWG Charter repo
15:17:46 <cyril> nigel: the resolution was passed long before Gary joined
15:17:56 <cyril> ... there was no active editor, ...
15:18:17 <cyril> pal: my preference is to treat WebVTT like any other spec, no more no less
15:18:25 <cyril> ... and to proceed along those lines
15:18:52 <cyril> atai2: the goal should that we don't make our life harder with our own decisions
15:19:07 <cyril> ... if we can amend/interpret our decision
15:19:23 <cyril> ... then that leaves enough time to proceed and remove any feature that is not implemented
15:19:27 <cyril> ... and follow the usual process
15:19:40 <nigel> q+ to check if we have consensus to remove the text-wrap: balance; feature
15:19:52 <cyril> nigel: 2 things going on
15:19:58 <cyril> ... concern about the charter
15:20:03 <nigel> ack n
15:20:03 <Zakim> nigel, you wanted to check if we have consensus to remove the text-wrap: balance; feature
15:20:08 <cyril> ... and text-wrap: balance
15:20:17 <cyril> ... do we have consensus about text-wrap: balance ?
15:20:32 <cyril> ... there is no indication that I'm aware of that the CSS module will move on
15:20:40 <cyril> ... we could get input from CSS
15:20:59 <cyril> ... or we could remove the requirement and replace with something that is implemented
15:21:24 <cyril> gkatsev: it would be nice to know from the CSS WG what the state of the text module is
15:21:41 <cyril> ... but even if they start implement it, the best choice is to remove it
15:21:49 <cyril> ... and add it in a new version
15:22:22 <cyril> nigel: the proposal I would make is to ask CSS WG (Philippe) and simultaneously to prepare a PR to mark it at risk
15:22:30 <cyril> ... any other proposal? objection?
15:22:46 <cyril> glenn: I just noticed that the text module was modified in ED 3 days ago, so there is active work on it
15:23:00 <cyril> nigel: that may be a good sign, the last update was a long time ago
15:23:10 <nigel> s/update/WD
15:23:28 <cyril> nigel: so we have consensus on what I proposed
15:23:53 <cyril> ... we have then 2 actions: one on Philippe and one on Gary
15:24:31 <cyril> glenn: what is the dependency on the Text module?
15:24:47 <cyril> nigel: if you search for "text-wrap" you'll find it
15:25:02 <cyril> ... level 4
15:25:24 <cyril> glenn: we should definitely not reference level 4
15:25:57 <nigel> -> https://github.com/w3c/webvtt/issues/455 Issue for marking this as at risk
15:26:01 <cyril> ... hasn't been modified since April, that's not too long ago
15:26:36 <cyril> glenn: balance is defined by the user agent
15:26:51 <cyril> ... tex has an algorithm
15:27:01 <cyril> ... but even you had support for it, it'd be hard to test
15:27:27 <cyril> ... it would be reasonable for an implementation to say that its implementation of balance does not do any balancing
15:27:45 <cyril> nigel: filing the line until no more character can fit would work?
15:27:47 <cyril> glenn: yes
15:27:51 <nigel> -> https://github.com/w3c/ttwg/issues/50 Issue for plh to liaise with CSS WG
15:28:29 <cyril> nigel: next one is about text-combine-upright
15:28:36 <nigel> -> https://lists.w3.org/Archives/Public/public-tt/2019Jun/0025.html Email from Pierre about text-combine: upright
15:29:18 <cyril> ... I haven't checked the status in WPT
15:29:27 <cyril> gkatsev: it is available in most browsers
15:29:42 <cyril> pal: but it's not demonstrated in the context of WebVTT, right?
15:30:00 <cyril> gkatsev: the test that is using this property is failing across all browsers currently
15:30:38 <cyril> pal: my concern is that in the past the group has gone through great lengths to make sure that every feature was implemented by 2 implementations
15:30:48 <cyril> ... we should apply the same principle to all specifcations
15:30:57 <cyril> ... we should have one set of criteria
15:31:14 <cyril> ... if there is no 2 implementation, we should remove it and add it later one
15:31:14 <nigel> -> https://wpt.fyi/results/css/css-typed-om/the-stylepropertymap/properties/text-combine-upright.html?label=master&product=chrome%5Bexperimental%5D&product=edge&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&aligned WPT for text-combine-upright
15:31:22 <cyril> s/later one/later on/
15:31:39 <cyril> gkatsev: for me, the way it is in the spec it is not a feature in itself
15:31:52 <cyril> ... it is a property of the CSS feature extension
15:32:02 <cyril> ... and there are tests demonstrating the CSS feature extension
15:32:28 <cyril> ... to me the CSS feature extension is working and missing just an extra property
15:32:43 <cyril> pal: but the test is failing
15:32:57 <cyril> nigel: could we ask Apple to have that in a dev build?
15:33:09 <cyril> gkatsev: I can have a look
15:33:42 <cyril> nigel: on WPT the text-combine-upright is only passing in Chrome and Edge
15:34:01 <cyril> ... so we might struggle to see 2 independent implementations that pass it
15:34:12 <cyril> ... that might be another reason to mark it at risk
15:34:32 <cyril> gkatsev: I think the prefix versions are fine
15:34:55 <cyril> ... are we ok with grouping the standard version and vendor-prefixed one?
15:35:04 <cyril> nigel: I don't know
15:35:41 <cyril> ... if an implementation would map the standard version to the vendor-prefixed one to make it pass, that should be fine
15:36:28 <cyril> ... what wouldn't work would be to use the vendor-prefixed one and testing that because that is outside the spec
15:36:34 <cyril> gkatsev: I'm not positive on that
15:36:44 <cyril> ... the way that CSS has been working
15:37:04 <cyril> ... is that once it's get closer to the standard version, it's equivalent
15:37:13 <cyril> ... it's up to the group to decide
15:37:23 <cyril> ... but all decisions would be correct
15:37:51 <cyril> ... personally, I would prefer to allow vendor prefixes
15:38:15 <cyril> nigel: it actually depends on the vendor commitment to replace vendor prefixes
15:38:28 <cyril> ... I would have to dig a bit more to see what's acceptable
15:38:49 <cyril> pal: does the W3C even have rules or guidelines on vendor prefixes?
15:38:56 <cyril> nigel: there is an accepted practice
15:39:04 <cyril> ... I have not seen anything written down
15:39:19 <cyril> ... I've seen implementations behind flaggs
15:39:49 <cyril> pal: my personal take is to say that if you had to use vendor prefix to demonstrate interop is awkward
15:40:02 <cyril> ... because a user would have to magically add the prefix for a given implementation
15:40:11 <cyril> nigel: that would be demonstration of non-interop
15:40:24 <cyril> ... a single document would not work
15:40:33 <cyril> pal: because the CSS is embedded in the document
15:40:43 <nigel> s/text-combine: upright/text-combine-upright/g
15:41:13 <cyril> pal: do the prefixes hold up for ever?
15:41:20 <cyril> ... do they go away after a while?
15:41:41 <cyril> ... you wouldn't want somebody to create documents that work today with prefixes but not in 5 years
15:41:54 <cyril> gkatsev: what you do in WebVTT is the same as in CSS
15:42:02 <cyril> ... you put both: standard and prefixed
15:42:15 <cyril> pal: got it
15:42:39 <cyril> pal: caniuse.com does not show results for text-combine-upright
15:42:52 <cyril> ... my recommendation is to get an initial version of WebVTT out
15:43:00 <cyril> ... and put at risk things that don't pass tests
15:43:15 <cyril> ... when browsers implement the feature, just update the spec
15:43:28 <cyril> ... that's simple, less risky and closest to reality
15:43:45 <cyril> nigel: it looks like marking it at-risk is simple to do
15:43:54 <cyril> pal: and easy to add back
15:44:38 <cyril> nigel: from an alignment perspective, we would have something in IMSC1.1 and not in WebVTT
15:44:49 <cyril> pal: yes, but that was not in IMSC1.0
15:45:33 <cyril> gkatsev: the plan is to have all features that are marked at risk and removed be put in a new WD so that browsers can reference that
15:45:57 <cyril> nigel: your proposal Pierre is to mark text-combine-upright at risk?
15:45:59 <cyril> pal: yes
15:46:07 <cyril> nigel: any objection?
15:46:20 <cyril> ... we do have consensus
15:46:40 <cyril> ... I'm creating an issue and assigning it to Gary
15:47:05 <nigel> -> https://github.com/w3c/webvtt/issues/456 Mark text-combine-upright as at risk
15:47:06 <cyril> pal: as a follow-up question, are there any other feature that failed to have 2 implementations?
15:48:02 <cyril> gkatsev: as far as I remember there are no other features who all of their tests are failing
15:48:49 <cyril> pal: what's setting position?
15:49:02 <cyril> gkatsev: I think it's vertical or horizontal
15:49:19 <cyril> pal: the IR shows only one implementation
15:50:08 <cyril> gkatsev: that is probably passing in vtt.js
15:51:16 <cyril> pal: I would suggest doing the same thing for tests that don't pass
15:51:54 <cyril> ... if you go through that table and it says 1, if you can tweak vtt.js then we would be fine
15:52:05 <cyril> nigel: there was an action from last week
15:52:10 <cyril> ... we had discussions about long and int
15:52:23 <cyril> ... gary you were to make a test for int
15:52:34 <cyril> ... how are we doing with that
15:52:42 <cyril> gkatsev: it's on my list
15:52:56 <cyril> nigel: it's in progress
15:53:13 <cyril> nigel: I don't think that the CfC can go ahead
15:53:29 <cyril> ... we have to in the CR loop again based on the discussion today
15:53:38 <cyril> pal: it can be fast
15:53:40 <cyril> nigel: yes
15:55:05 <cyril> cyril: can we get an agreement that everything that's red should be marked at risk?
15:55:12 <cyril> pal: yes
15:55:21 <cyril> nigel: I agree
15:55:32 <cyril> gkatsev: marking everything red at risk is simple
15:55:50 <cyril> pal: if later on it works, you can remove the 'at risk'
15:55:58 <cyril> gkatsev: not sure about the int vs. long
15:56:48 <cyril> cyril: what's the likelihood of having 4 browsers change when they are already interoperable?
15:57:01 <cyril> nigel: I think we should adopt Cyril's suggestion
15:57:25 <cyril> ... because the requirement for long was not very strong
15:57:39 <cyril> gkatsev: there is an issue of alignment with other specs
15:58:38 <cyril> cyril: the proposal is to mark at risk all the features that are red in the IR
15:59:01 <cyril> nigel: we also need to change the line attribute to be unsigned int?
15:59:09 <cyril> gkatsev: unsigned int would pass
16:00:03 <cyril> nigel: any objection to changing to unsigned int?
16:00:20 <cyril> ... no objection, we should resolve to do that
16:00:30 <cyril> ... I'm creating an issue and assigning it to Gary
16:00:58 <nigel> -> https://github.com/w3c/webvtt/issues/457 Change line attribute to unsigned int
16:01:23 <cyril> nigel: the second proposal is to mark at risk everything that does not have 2 passing tests
16:01:36 <cyril> ... any objection?
16:01:51 <cyril> ... none
16:02:17 <cyril> ... ok, we'll do a new CR publication
16:02:47 <nigel> RESOLUTION: Mark any remaining features with tests that don't have at least 2 passes as at risk
16:03:05 <cyril> nigel: that's everything on the WebVTT agenda topic
16:07:58 <nigel> scribe: nigel
16:08:00 <nigel> Topic: Clarify use of 'applies to' in style property definition tables (ttml2#1088).
16:08:08 <nigel> github: https://github.com/w3c/ttml2/pull/1089
16:08:51 <cyril> scribe: cyril
16:09:05 <cyril> nigel: this one is about 'applies to'
16:12:06 <cyril> ... we're looking at pull 1089
16:12:10 <cyril> ... this PR adds a note
16:12:47 <cyril> pal: that should be part of the broader discussion
16:12:51 <cyril> ... in isolation it makes sense
16:13:07 <cyril> ... the real issue is what do we write in "applies to"
16:14:01 <cyril> glenn: are you asking us to approve or not the whole collections of PR? as a whole?
16:14:30 <cyril> ... the intent was dividing them because they are orthogonal
16:15:21 <cyril> nigel: if we can't agree on what 'applies to' mean, we cannot move on
16:15:37 <cyril> pal: depending on the context of applies to the meaning might change
16:15:53 <cyril> nigel: if we know what 'applies to' should mean, then we can put it
16:16:10 <cyril> ... the current proposal says make it say what CSS does
16:16:23 <cyril> nigel: are you agreeing?
16:16:37 <cyril> pal: I think we should assume that that's the case and move forward
16:16:41 <cyril> ... let's not merge now
16:16:57 <cyril> glenn: I think the chair needs to make a determination on how to move forward
16:17:09 <cyril> nigel: we have agreement can we move forward?
16:17:34 <cyril> glenn: Pierre has put a blocker for process reasons and I don't agree with
16:18:04 <cyril> nigel: moving forward means having a common ground
16:18:15 <cyril> ... is there any objection to adding this text?
16:18:31 <cyril> ... hearing nothing, we have agreement in principle
16:18:45 <cyril> glenn: before you move on, we have 2 approvals on this PR but a blocker
16:18:56 <cyril> ... we need Pierre to remove his blocker
16:19:07 <cyril> nigel: I'm sure Pierre will remove his blocker
16:20:02 <cyril> github: https://github.com/w3c/ttml2/pull/1079
16:20:43 <cyril> github: https://github.com/w3c/ttml2/pull/1089
16:20:59 <cyril> github-bot, end topic
16:21:10 <cyril> github: https://github.com/w3c/ttml2/pull/1079
16:21:28 <cyril> topic: text-decoration
16:21:32 <cyril> github: https://github.com/w3c/ttml2/pull/1079
16:22:55 <cyril> pal: I have the same position as on the previous PR, the proposed text is fine
16:23:09 <cyril> ... in fact I integrated it in 1071
16:23:18 <cyril> ... same as before for me
16:23:28 <cyril> nigel: any objection to this text change?
16:23:41 <cyril> ... none
16:23:48 <cyril> ... we resolve to accept this change
16:23:55 <cyril> github-bot, end topic
16:24:05 <cyril> topic: text-emphasis
16:24:13 <cyril> github: https://github.com/w3c/ttml2/pull/1081
16:24:35 <cyril> nigel: my comment there was on 1080
16:24:56 <cyril> ... I was worried that inline areas that are not glyph areas would be affected
16:25:00 <cyril> ... but you convinced me
16:25:15 <cyril> ... so I don't have any objection on this one
16:25:30 <cyril> ... anyone objects to this?
16:25:46 <cyril> ... none
16:25:52 <cyril> ... we've all agreed to this
16:25:59 <cyril> glenn: can you remove your blocker?
16:26:10 <cyril> nigel: let's work out removal of blockers later
16:26:15 <cyril> github, end topic
16:26:25 <cyril> Topic: font selection strategy
16:26:37 <cyril> github: https://github.com/w3c/ttml2/pull/1083
16:26:44 <cyril> pal: same as before
16:26:54 <cyril> nigel: any objection to adding this text?
16:27:09 <cyril> ... I think not
16:27:16 <cyril> ... everybody is happy with this in principle
16:27:23 <cyril> ... we agree to accept that change
16:27:27 <cyril> github-bot, end topic
16:27:47 <cyril> Topic: font variant
16:27:54 <cyril> github-bot: https://github.com/w3c/ttml2/pull/1085
16:27:54 <github-bot> cyril, Sorry, I don't understand that command.  Try 'help'.
16:28:07 <cyril> github:  https://github.com/w3c/ttml2/pull/1085
16:28:12 <cyril> pal: same for me
16:28:29 <cyril> nigel: I don't have an objection
16:28:34 <cyril> ... anyone has an objection>
16:28:40 <cyril> s/>/?/
16:28:56 <cyril> ... none
16:29:01 <cyril> ... we're happy to accept this
16:29:06 <cyril> github-bot, end topic
16:29:16 <cyril> topic: text combine application
16:29:26 <cyril> github: https://github.com/w3c/ttml2/pull/1087
16:29:30 <cyril> pal: same here
16:29:55 <cyril> nigel: there was a typo that was fixed
16:30:18 <cyril> ... any objection?
16:30:26 <cyril> ... no objection
16:30:33 <cyril> ... we agree to approve it
16:30:41 <cyril> github-bot, end topic
16:30:53 <cyril> topic: Emphasize null style semantics in context of ruby container spans
16:31:06 <cyril> github: https://github.com/w3c/ttml2/pull/1101
16:31:18 <cyril> nigel: I summarized it
16:31:39 <cyril> ... it adds a note to all the "applies to"
16:32:44 <cyril> ... my summary of the debate is whether we need to do it normatively or informatively
16:33:03 <cyril> ... Pierre how do you feel about that at the moment?
16:33:22 <cyril> pal: I feel like day 1
16:33:40 <cyril> ... the practice is to list what a property applies to in this line
16:33:47 <cyril> ... and in the prose to add text
16:34:02 <cyril> ... I don't see any reasons to not list the span that it does not apply to
16:34:17 <cyril> nigel: you don't see any difference in making it normative/informative
16:34:36 <cyril> pal: the practice is so loose in TTML2 that it does not make any difference
16:35:00 <cyril> nigel: can you live with the proposal?
16:35:17 <cyril> pal: it could be expressed more clearly
16:35:59 <cyril> nigel: glenn, if we said "spans except ..." with an editorial way
16:36:24 <cyril> glenn: 1) a span that serves as a ruby container, base container or text container is not an element
16:36:35 <cyril> ... it is no different than a span that is empty
16:36:46 <cyril> ... we do not say these properties do not apply to spans that are empty
16:37:30 <cyril> ... 2) a span that serves a ruby container is not an element by the definition that we use or that CSS uses
16:37:57 <cyril> ... until we introduced ruby align and ruby position, we did not have any case that called out a qualified version of an element
16:38:19 <cyril> ... we went off-track in my opinion when I wrote that text
16:38:42 <cyril> ... if we had not done so (I believe it was an error) we would not have that conversation
16:38:50 <nigel> q+ to say that elements are not necessarily only defined by their qualified name alone
16:39:02 <cyril> 3) there is no normative impact and it's not testable to say that it does not apply to
16:39:18 <cyril> ... so it's strictly an informative advice for the reader
16:39:26 <cyril> ... that we can deal with through a note
16:39:40 <cyril> ... it's not different to other parts of the spec where you have to follow the text
16:39:48 <cyril> 4) the issue about optimization
16:40:16 <cyril> ... we don't document premature optimizations that could turn out to be false
16:40:56 <cyril> ... out of the 18 properties that Pierre wanted to modify I've determined that 3 do apply
16:41:05 <cyril> ... the other 15 are somewhat arbitrary
16:41:21 <cyril> ... because for example color could follow the same logic
16:41:35 <cyril> ... my original opinion was not to write anything
16:41:41 <cyril> ... the note is a compromise
16:42:07 <cyril> ... I do not accept Pierre's proposal
16:42:19 <cyril> ... we already have a definition of ruby container in the text, defined in 10-1
16:42:47 <nigel> ack ni
16:42:47 <Zakim> nigel, you wanted to say that elements are not necessarily only defined by their qualified name alone
16:43:14 <cyril> nigel: it seems reasonable to me to specify elements not only by name but qualifying the selection
16:43:24 <cyril> s/but/but by/
16:43:59 <cyril> ... you say that CSS does not talk about qualified elements
16:44:14 <cyril> ... but actually CSS uses whatever is meaningful even if it's not an element
16:44:29 <cyril> ... there is a precedent in CSS
16:45:03 <cyril> ... I take your point that there is no normative impact
16:46:19 <cyril> nigel: do these arguments work for you?
16:47:07 <cyril> pal: I'm all for finding a compromise
16:47:28 <cyril> ... we are very close, because Glenn's latest proposal adds text to "applies to
16:47:51 <cyril> ... we are in the right direction
16:49:19 <cyril> ... if that link linked to a specific note not a generic one, and that note listed those elements to which the style property does not apply
16:49:29 <cyril> ... that might be wordy but explicit and not ambiguous
16:49:31 <nigel> scribe: nigel
16:49:38 <nigel> scribe: cyril
16:49:53 <cyril> glenn: what I hear you are proposing is to copy the note 15 times in the text with exact wording
16:50:05 <cyril> ... or with just the name of the property substituted
16:50:15 <cyril> ... we try to use generic languages
16:50:39 <cyril> ... it creates a maintenance issue
16:50:56 <cyril> pal: I don't disagree, it's wordier
16:51:05 <cyril> ... I'm trying to find a compromise
16:51:16 <cyril> nigel: why do we need those specific notes?
16:51:39 <cyril> pal: it has to be very clear for everybody whether or not by reading the applies to line it applies to or not
16:51:49 <cyril> ... a generic note does not do that
16:52:19 <cyril> ... just like unicodeBidi does not apply to div
16:52:22 <nigel> scribe: nigel
16:52:29 <nigel> Cyril: Q about the text in Glenn's pull request.
16:52:46 <nigel> s/Cyril: Q about the text in Glenn's pull request.//
16:52:50 <nigel> scribe: cyril
16:53:11 <cyril> glenn: I definitely do not agree with the intent that pierre stated
16:53:20 <cyril> ... that the applies to line be definitive and complete
16:53:27 <cyril> ... with respect to the application semantics
16:53:53 <cyril> ... I'm convinced that the information in the applies to line has to be taken in context of the full prose of each style
16:54:46 <cyril> ... in XSL-FO appendix B.4
16:54:57 <cyril> ... there is generic language
16:55:13 <cyril> ... that says that further clarification may appear in the text
16:55:38 <nigel> [[ For each property the formatting objects it applies to is listed. It should be noted, however, that for some formatting objects there are qualifications on applicability or values permitted. ]]
16:55:39 <cyril> ... that's why I'm disagreeing in part with Pierre's original premice
16:55:57 <cyril> pal: thanks for highlighting the crux of the issue
16:56:13 <cyril> ... past practice in TTML and CSS has been to be exhaustive in the applies to line
16:56:24 <cyril> ... that's the intention of my proposal
16:56:45 <cyril> ... it's clear in CSS and TTML that that line has been exhaustive
16:56:58 <cyril> ... e.g. unicodeBidi
16:57:28 <cyril> ... div is not listed under unicodeBidi
16:57:44 <cyril> ... because it cannot apply to div so it cannot be listed there
17:00:58 <cyril> pal: if glenn's note would list the exact properties that "might not" apply, that would work for me
17:01:20 <cyril> ... I'm not fine with leaving a vague note
17:01:40 <cyril> glenn: I objected to that because of the maintenance effor
17:02:08 <nigel> scribe: nigel
17:02:36 <nigel> Nigel: if you're not happy with the note propose a change
17:02:51 <nigel> Pierre: I've proposed alternate text in a separately maintained PR, or would accept a specific note on each
17:02:53 <nigel> .. style property.
17:03:13 <nigel> Glenn: Here's a suggestion: if we put a note in each of those 15 properties that points to the generic note and says
17:03:30 <nigel> .. it applies to this specific property, would that satisfy you, and have the Applies to line point to that?
17:03:42 <nigel> Pierre: Yes, I think that would satisfy me. I don't like it editorially.
17:04:06 <nigel> Glenn: I'm proposing instead of the "See also" note I could add a note in each of the 15,
17:04:13 <nigel> .. and I would say the generic note applies to this property.
17:04:15 <nigel> Pierre: Yes
17:04:34 <nigel> Glenn: That would give you something explicit in each of the properties
17:04:44 <nigel> Pierre: Yes and then the note can be more definite
17:05:03 <nigel> Glenn: I'll tweak this PR to make those changes and we'll see if we can accept that, and maybe all the related pull requests too.
17:05:08 <nigel> Pierre: Sounds good to me.
17:05:27 <nigel> Nigel: Thank you both for working constructively towards a solution.
17:05:32 <nigel> Topic: Meeting close
17:05:43 <nigel> Nigel: We're out of time, thanks all.
17:05:57 <nigel> Glenn: Regrets for me for next week.
17:06:05 <nigel> Nigel: Let's try to move forward on GitHub on these.
17:06:45 <nigel> .. [adjourns meeting]
17:06:50 <nigel> rrsagent, make minutes
17:06:50 <RRSAgent> I have made the request to generate https://www.w3.org/2019/06/13-tt-minutes.html nigel
18:00:44 <nigel> s/github-bot, end topic//g
18:01:17 <nigel> s/3) there is no normative impact/.. 3) there is no normative impact
18:01:28 <nigel> s/so it's strictly an informative advice/.. so it's strictly an informative advice
18:01:37 <nigel> s/4) the issue about optimization/.. 4) the issue about optimization
18:02:44 <nigel> rrsagent, make minutes
18:02:44 <RRSAgent> I have made the request to generate https://www.w3.org/2019/06/13-tt-minutes.html nigel
18:03:25 <nigel> scribeOptions: -final -noEmbedDiagnostics
18:03:32 <nigel> rrsagent, make minutes v2
18:03:32 <RRSAgent> I have made the request to generate https://www.w3.org/2019/06/13-tt-minutes.html nigel
19:00:04 <Zakim> Zakim has left #tt