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