See also: IRC log
<cyril> scribe: Cyril
nigel: there are lots of AOB
today
... profile registry, future reqs (probably nothing), TTML in
RTP
... WebVTT ?
gkatsev: yes
nigel: charter draft, some issues
with a PR
... a new issue on TTML and WebVTT mapping, poll on F2F
... historical content on mercurial
... tiny update on an ITU doc
... reminder that DST is coming to the US ahead of Europe, so
meeting time shuffling needed in March
atai2: possible liaisons with MPEG and the VR-IF regarding subs in VR/360
nigel: thank you Glenn for
getting conclusions on the previous PR, just merged
... we need some reopening discussions with the section that
describes possible way of discovery
... section 4.2
... glenn opened PR 53 that deletes the whole section
... I thought we agreed to move it to an informative annex
https://github.com/w3c/tt-profile-registry/issues/53
glenn: there are 2 reasons to
delete the section
... 1) the leading sentence is misleading at best
... it's possible that we define an algorithm not in TTML
today
... but I don't want to define another one and leave it up to
implementation
... if we do, we need to qualify the utility of this
... 2) it introduces another table
... that creates long-term maintenance issue
... it creates a second registry that has questionnable
use
... overall, best to remove it
... seems in accordance to make the document shorter
<Zakim> nigel, you wanted to note that if we keep 4.2 then we need to say it applies to content profiles not processor profiles
nigel: definitely I would concur
that it is confusing
... the document as a whole talks about processor
profiles
... but that section seems to talk about content profiles
... and we don't talk about it
... on the point of maintenance, I don't think that's a strong
point
... I don't see that as a prime factor
... the question is: is this table useful at all
<nigel> scribe: nigel
Cyril: I agree with Glenn, remove the section, make the document lean.
<scribe> scribe: cyril
nigel: any other views?
... proposal is to remove 4.2
... any objection?
... anyone wanting to keep it in one form or moving it
... silence
... the proposal is adopted
... I will amend my PR comment
glenn: that will remove a comment from cyril, we can close 2 or 3 issues as a side effect
nigel: summary is there is still a bit of editorial work to solve the remaining issues
glenn: I'll crunch through
those
... mike asked an IANA review
... to resolve that one we'll have to get external review
... the codecs parameter is new
nigel: no, it was in TTML 1 2nd
edition
... the IANA page already includes codecs
pal: let's not change at all if possible, no editorial change
nigel: none of the PR have done so
pal: great news
nigel: we should treat that as a
constraint for the future PR
... anything else?
... no
nigel: anything to say?
... to raise about that?
nigel: 4th draft has been added
<nigel> latest draft
nigel: this should resolve all
the comments that we raised
... section 8 says no IANA action
... the one thing that we haven't fully concluded
... is the codecs parameter
... we now have a requirement that says it shall be in the
SDP
... glenn if you could have a look at that and confirm that it
removes the need for anything else
glenn: ok
nigel: we welcome any other feedback
gkatsev: after last week's
meeting, I met with Silvia to talk about at risk stuffs
... we identified a couple of things to be marked at risk
... the style block is only supported by Safari and polyfilling
is tricky and cannot be done on time
... collision avoidance with snap to line false
... and also some selectors
... if we remove those items from the rendering tests, we can
reach 99% completion
... I'm going to work on marking those at risks and getting a
new spec snapshot
... FF has basic support
... for regions
... and VLC has it too, so we have interop
... in FF, they have chosen to give a default background to
boxes but Safari and VLC have not
plh: is FF following the spec?
gkatsev: yes
pal: I think either Chrome or FF
are not following the spec regarding opacity
... I don't know how precise we want to be
... what the threshold is for passing
nigel: what does the spec say about the background of regions
atai2: thank you gkatsev for the
update
... what does basic support for FF mean? what is the
target?
... do they complement each other?
gkatsev: the reason I'm saying it
has 'basic' support
... it's because all the tests pass
... but for the scroll tests, the sizing in FF is a bit
unexpected (not incorrect)
... but you can see a portion of the first cue as it goes out
of the region
... it's not perfect
... but I think it is still within tolerance
... and just filed as an implementation bug
nigel: does the spec talk about clipping
gkatsev: I don't think so
nigel: so then it would seem acceptable
gkatsev: I'll verify
... everything else that I looked at, nothing is not
implementable
... VLC is not implementing some of the style stuffs because it
is allows
... at risk are: cue selector function with *, cue pseudo
selectors with past and future
... collision avoidance with snap to line false
... and style block within the VTT file
... and cue selectors with region
nigel: the style part is a big deal
plh: why?
nigel: because video only players
like VLC would have no way to set styles
... no mechanism inside the document
gkatsev: VLC has chosen not to
implement that
... and the spec says that if you don't have a style engine you
can
pal: do the current tests
adequately represent the spec?
... that's discussion a
... and discussion b is: is the spec adequate for some use
cases?
... a) is very mechanical
... you check 2 implementations for each feature
... b) is a lot more complex
plh: my thinking is that we need
to publish ASAP with the features at risk
... if the group is OK we should give him power to do
that
... then regarding styling and accessibility, we cannot answer
before publication anyway
... but we can ask accessibility people
atai2: I agree with plh and
pal
... if a feature is not implemented it needs to be
removed
... but nigel point is also valid
... we have a lot of implementations using HLS and if there is
no way to have styles
... that's a significant issue for accessibility [if colours
cannot be used to indicate speakers]
... if it's not implemented what can we do
nigel: to respond to plh's point,
I think this group's job is to think about accessibility
... it is within our charter
... we can make the call to accept or not the features at risk
because of accessibility
... we need consensus on the at risk list
plh: the spec does already allow not to implement the style part today
nigel: I don't think that's right
plh: yes, there is a class of conformance without CSS
<plh> "All processing requirements in this specification apply, except parts of §6 Parsing that relate to stylesheets and CSS,"
<nigel> scribe: nigel
Cyril: We don't have a choice,
either we publish what is implemented or we don't
publish.
... We can't change what is implemented today, it is too late,
whether or not we like it.
<scribe> scribe: cyril
gkatsev: we can mark things at
risk that today don't meet the criteria, but we can decide
later if we remove or not
... the style block is something we can polyfill but we need
more time
... we could potential meet the 2 implementations goal
... for VLC, from what I understand, because they don't have a
CSS engine, they are not implementing the style block
... this is really CSS inside the file
pal: what's missing is a WebVTT
spec that reflects reality
... it's a reasonable plan to take the spec, identify at risk,
publish that
... if removal of a feature creates deficiencies for
accessibility, those can be noted
... and then we can decide on what we do
... I'm a pretty big proponent to have a spec that matches
reality
nigel: plh posted some text on
style
... if we mark at risk and meet exit criteria, the group would
have agreed to publish without the feature
... we need to think very hard about allowing publication
without any styling at all
... if you cannot indicate colors, I would need to think hard
about it and would probably object: it would mean that WebVTT
cannot be used to meet the accessibility requirements of the
UK's audience.
pal: if the spec does not meet all criteria, maybe that could be acceptable
plh: if you look at HTML, it does
not say you have to implement CSS
... I don't see why we should have a different approach
... I agree the experience would not be a pleasant one or
acceptable one
... but we don't require a specific profile of CSS to be
implemented with HTML
... what we are doing today is marking at risk
... we would be blocking ourselves to start discussing if we
remove it or not today
... there may be a case to make to keep the style box
... there are lots of engines out there
<nigel> scribe: nigel
Cyril: The goal is to publish
what is implemented today,
... it doesn't mean that it requires BBC to implement it, there
are other choices.
... Publication does not endorse the feature set, we can say it
reflects reality.
... It's better than not having a spec.
<scribe> scribe: cyril
nigel: Gary, please circulate a detailed proposal of what you want to mark at risk and we'll discuss again
nigel: I've been reviewing the
draft charter
... and the issues
... PR40
... plh we need to enable PR preview on this one
plh: usually we don't on small repo, but sure
nigel: PR40 is adding wording for
TTML3 and module approach
... please have a look at if that works and look at the CSS
charter for reference
... I've tried to adapt that "prior art"
... one question: there is a template section for adopting
working drafts ...
... are they required?
plh: yes if they have been published, otherwise use the ED and don't add the call for exlusions
nigel: please look at the current draft and raise issues - I'll try to open pull requests next week
nigel: we made a bit of progress
offline
... summary is that we are working out what we do with the
video resources
plh: we don't need to solve that
right now on this call
... are they BSD?
pal: Yes, they are referenced from the repo and have the same license as on the repo
plh: I'll check with Wendy
... regarding the forking, I'm ok with it
... you'll check when you want to merge
pal: let me know as soon as you can if any additional info is needed by fox
nigel: John Birch noticed a
possible error and raised an issue
... anyone wanting to take the editorial role and fix the
document?
... if so, please get in touch with me
atai2: we said the document is on
hold
... but I think I'm still one of the editor
... it's really out of date
... I'm not sure what sense it would have to fix just one
error
... not sure what use it has right now
... I did not review the issue
... I assume the fix is small
nigel: still open until 23:59,
Boston time on 2019-03-07
... but I noticed while looking at our charter that says we
will meet at TPAC
... which means at least I should arrange a meeting for
TPAC
... I raised an issue about the charter in case we need
<nigel> WBS Poll
<nigel> scribe: nigel
Nigel: I'll send a message to the
reflector - if there's anything of ours on Mercurial still that
we need to migrate, please
... let me know.
Pierre: Let's make a backup and store it somewhere
Philippe: We're going to have
access to zip files of the repos themselves.
... That's already provided. Worse case scenario is download
that zip file.
Pierre: Thanks
Nigel: That's good to know, thank you.
Nigel: I'm in process of
submitting an update to the above ITU document to bring it up
to date, to be considered in
... the March ITU-R meeting.
... For info only.
Nigel: The US is entering DST
soon, a while before Europe so I'll propose new UTC meeting
times hopefully to
... minimise disruption.
Pierre: For the meeting at TPAC,
is the goal still to determine following March 7 the final plan
based on the poll,
... regardless of the Charter?
... For those attending IBC there will be significant
international flight gymnastics and we have to set the date
soon.
Philippe: We're rechartering between now and TPAC.
Pierre: Understood, thanks.
Nigel: My plan is to agree after
March 7, yes.
... The draft Charter would need a pull request.
Philippe: I can tell you that rule is not actually enforced!
Andreas: Let's discuss this next week.
Nigel: Thanks everyone, apologies for running 5 minutes over. [adjourns meeting]