<nigel> Log: https://www.w3.org/2019/06/06-tt-irc
nigel: we've got WebVTT IR
… gary has made some progress
… we've got TTML2 aggenda items
… TTML2 Profile Registry
… Philippe should join and give charter update
glenn: I have a broader set with a different order
nigel: that's what was labelled agenda on tuesday
glenn: when we get there we can fine tune the order
nigel: it's fair for members to cover the ones that were on the agenda first
glenn: ok
nigel: AOB?
nigel: Gary has posted an update
… a beautiful Wiki page
<nigel> WebVTT Implementation Report
gkatsev: I have transformed the spreadsheet into the wiki page
… for all the features that are not at risk
… I believe there are 10 tests that are not passing
… but I think these tests are failing mostly because impl bugs
… and because of the way WebVTT is with no "feature" per se
… one test not passing does not mean that a feature is not implementable
… because the parts that are being tested is also tested in rendering tests
… so unless we can get implementations to fix their bug, we'll be stuck there
glenn: can you remove the tests?
… we've done that in other specs
plh_: we could remove it from the report and/or the repository
… if it is not wrong, I would not remove it from the repo
glenn: in TTML2 and IMSC1, we used a driver to remove tests that we did not want in the report
plh_: we just need a list that is relevant for the director
plh_: the main goal for the report is to show to the Director
… if we have red and explanations that's fine
nigel: you said 10 tests
… that sounds like a large number
plh_: no, it's not
nigel: I still find it hard to grasp the user impact
gkatsev: the failing tests I don't think show that the spec is not implementable
nigel: the exit criteria says 2 indep implementations of each feature
… implementability is not part of the exit criteria
… that's a different thing
… I'm trying to understand what might look like a feature and that is not passing
plh_: we have multiple tests for each feature
nigel: a failing test might show that a part of a feature has a problem
… or it might be an edge case
plh_: or it shows that the underlying CSS engine is not yet there
… WebVTT delegates a lot of things to CSS
… if one of those tests fail, does it mean we should not mention that property in WebVTT?
… I don't think so
nigel: you've made a logical leap that's too big
plh_: webvtt relies on CSS semantics
nigel: yes, but these are implementation tests not semantics test
plh_: can you point to a feature that is pretty bad
nigel: I'm worried about positioning
… settings line, settings position
… if you cannot be sure that WebVTT cannot work with positioning of text
… that's a problem
gkatsev: all of these positioning things are tested in the rendering test and working properly
… the parsing tests are complex and have lots of edge cases
… Firefox fails because their parsing is very very strict
… and parses as much as it can and as soon as it sees something unusual that should be ignored it ignores everything
… a lot of the implementations are quite old
… I'm actually surprised to see how well they do
… the region lines are failing because the tests use a 2^32 value that is beyond integer and the spec says it's a long
plh_: in this case of long, how often do you want to use such a big number
… blocking the spec on this kind of thing would be stupid
nigel: can we ask as a macro level, with the implementations that we have test for, can we use regions?
gkatsev: you can use regions in Firefox and VLC
nigel: and the failing tests, what do they show us?
… region lines is the long one
… if you use normal numbers it passes?
gkatsev: yes
nigel: in a well formed file that uses id in the int space, Firefox would render correctly
gkatsev: yes
plh_: at this point, people need to look at the IR and ask questions
… I'd like to start a CfC to move into PR
… if people need more time to review the PR, they should ask
pal: it seems that some tests are non-sensical, we could just change the test
plh_: I think it makes sense to have edge cases test
pal: what's uncool is to ship a product with failing tests?
… I'm just talking basic software practices
nigel: we're not talking about the tests being cool, we're talking about the spec
pal: what makes me uncomfortable is that if a feature is in the spec, somebody will run into it
… one issue is to remove the test, file an issue with the spec to fix it
… if we say we'll never do it, we should fix the spec
plh_: the implementations need to be fixed
pal: I've seen similar examples in TTML
pal: I don't want block the spec
… I want to resolve it without ignoring it
plh_: I'm suggesting not to resolve them in a rush
… maybe the v2 of WebVTT will fix that
pal: I'm suggesting to remove the test and file an issue with the spec and move on
gkatsev: the main utility of keeping it long is consistency with other specs like HTML
… but I cannot imagine someone using a long
plh_: I'd like to start a CfC
… the failures are edge cases at this point
pal: file an issue and remove the test
plh_: you want to rush things, I don't
nigel: if you want to start a consensus gathering, you should start
… you can send an email for CfC or ask here
… with a 10 day
plh_: I'll start an email CfC
… and if people are not happy, they will have 10 days to do so
pal: I'm totally confused regarding filing issues
… what's the problem
plh_: I just don't want to block the spec
pal: it can be in the backlog
… I'm kindly asking Gary to file an issue because he understands better
gkatsev: I can do that
nigel: specifically for this one, it would be nice to have a test that does not exercise the long range and show that it passes
nigel: done on WebVTT?
glenn: I'd like to go in a different order
… 1107 ?
nigel: no because it's unfair to ask people to review issues that were not in the agenda
glenn: no because there are dependencies
nigel: anybody had a look at it?
… [silence]
plh_: I think we need to move on with the agenda
… as sent out by nigel
glenn: in that case, I'd like to defer 1108 and 1089 and request a 2h meeting next week
<nigel> github: https://github.com/w3c/ttml2/pull/1098
nigel: there are many open parts on this
… there are unresolved conversations
nigel: about TR and RR I pushed that in a separate conversation
Nigel: [group iterates through unresolved conversations and moves issues to separate tickets] We've resolved all the unresolved conversations.
… Any objections to merging?
group: no objections
Nigel: Ok we can go ahead and merge this.
<glenn> regrets for Jun 20 meeting
nigel: any update ?
plh_: still within W3M
… I've got a few comments that I need to address
… nothing substantive
… it should be approved not Wednesday but the next one
nigel: I did notice a comment on horiz review
… the one from richard, it seems to be a mistake on our side
plh_: I'm pushing the accessibility people to review
<plh_> https://github.com/w3c/strategy/issues/177
plh_: we changed the charter regarding horiz review 2 weeks ago
<plh_> https://github.com/w3c/strategy/projects/2
pal: maybe the reason it was removed is because it was in the liaison section
… could be added easily
Nigel: I have a clash for what would be the first hour of a two hour meeting if we do it at the usual time of 1400 UTC
… next week, so I'll send out a separate message to the group about scheduling the call next week.
… Thanks everyone. [adjourns meeting]