See also: IRC log
<cyril> scribe: Cyril
<scribe> chair: Nigel
<scribe> Agenda: https://github.com/w3c/ttwg/issues/61
nigel: we have webvtt, imsc, tpac
and aob, including charter status
... with the absents, I'm not sure we'll cover everything
cyril: I'd like to review the timelines for our deliverables, to set some goals for TPAC
nigel: the first point is action 51
https://github.com/w3c/ttwg/issues/51
<nigel> Minutes relating to #51
nigel: it's to make sure the comments raised during the first CfC were raised as issues
gkatsev: I checked all tests that
did not have 2 or more passes and created an issue
... marked with [IR] and there were 7 of them
nigel: I see that was done on July 3rd
<nigel> Issues created with [IR]
nigel: is that done then?
gkatsev: yes, I think we can close that
cyril: was this the only comment during CR
gkatsev: yes
summary: issue can be closed
<nigel> github-bot, end topic
<calvaris> Xabier
<calvaris> calvaris@igalia.com
<nigel> github: https://github.com/w3c/webvtt/pull/460
gkatsev: there is a bunch of
changes in the snapshot
... I wanted to go through and categorize them according to the
W3C Process document
nigel: which one is the right list?
gkatsev: changes.html
<gkatsev> list of changes
nigel: normally the technical changes would be the substantive one
gkatsev: we can review the at-risk ones
nigel: I'd be interested to a staff view on that
gkatsev: the "make vtt lines be a long" one is changing the WebIDL for the lines property from an unsigned long to a long
nigel: it has 2 GitHub issues
gkatsev: one is the PR and the
other one is the issue
... 457 is the issue
... and 461 fixes 457 as well
nigel: the change document lists the github issues, so you might want to change the first one to 457 and remove the editorial dup
gkatsev: yes, I'll do that
nigel: that is indeed substantive
gkatsev: from a process
perspective, that is a correction that does not add new
features
... next one is "Update region lines parsing to round to +/-
MAX_VALUE"
... it's based on the current implementation in Safari
... the mozilla people are on board with that change
... it is a correction that does not add new features
nigel: yes, that is not a new
feature
... but it is definitely substantive
... it's worth pointing to the issue 467
gkatsev: I'll do that for the at
risk ones also
... next one is changing editors
nigel: obviously editorial
... then you have the at risk ones
... and the last was a dup, we discussed it
... so there was no change made for the [IR] issues?
gkatsev: a lot of them are already covered by these changes
[going through the IR issues]
<nigel> I'm on #465
gkatsev: Safari for this one, the region parser is correct, but the way you interact is not
nigel: are they going to fix that?
gkatsev: I hope so
nigel: I mean during the CR
period
... you could get stuck in CR because of this
... one route out could be for Safari to remove the
prefix
... another route is to mark it at risk
... another one would be to tweak the test
... on the last one I'm a bit uneasy because we would not be
testing the spec
gkatsev: if it's parsing
correctly, that means the test should pass
... but it's failing after it's parsing
nigel: we have members from apple
in this group
... we should be going to them
... Eric would be a good person
... asking: is this something they might fix in the developer
preview
gkatsev: I'll reach out to
them
... 463 is similar, weird implementation in Safari
nigel: the resolution for this
one is not marked at risk
... so what's our exit plan
gkatsev: we should talk to
Apple
... we could mark regions at risk but removing it would not be
good
nigel: depending on their
response, we may need to tweak the spec or just wait until they
are done with it
... the last one is 464
... entities test failing
... we don't have an exit plan for this issue
... if this continues, do we have any other implementation that
would pass?
gkatsev: I think vtt.js may
support it
... also we can try doing what we discussed the lines
attribute, split up the test in 2 portions
... and say the core part passes
... but the first thing is to see how vtt.js fares
... I could tweak it
nigel: we have a clearer
understanding about the snapshot
... there is some action needed because we don't want to go
back to CR again
Xabier: when you speak about regions, are they CSS regions?
gkatsev: no, WebVTT regions
nigel: it's a good question, what's the relationship between the 2
calvaris: is there are relationship?
gkatsev: I don't think so
gkatsev: we just answered it,
more work is needed before that
... and worst case we can talk to Apple about that
nigel: is it just Apple? or could it be that support from Firefox or Chrome would help
gkatsev: Chrome just started
implemented inline styles, maybe we can convince them to work
on regions
... or Microsoft with Chromium+Edge
nigel: anything else on WebVTT?
nigel: we have a number of
sub-parts to that agenda item
... the meeting with the Chinese IG
<nigel> github: https://github.com/w3c/ttwg/issues/60
nigel: I requested this at the
proposal of
... Fuchao got back to us and suggested Friday afternoon
... they want us to join because they are a larger group
... Andreas initially suggested Thursday but that got
deleted
... this is to discuss Danmaku
cyril: Is it ging to be the last session on the Friday afternoon
nigel: not clear yet
... the meeting will be in chinese and the essential points
will be translated by volunteers
cyril: I would prefer if we would wrap our meeting not with a joint meeting
nigel: so maybe after lunch
... the action is back to me
SUMMARY: the group would like to meet the Chinese IG in the afternoon, preferably not at the end of the day
<nigel> github-bot, end topic
gkatsev: this will be my first TPAC and I'm interested in the Media WGwhich is also Thursday and Friday
cyril: me too ...
nigel: there are clashes with
other groups (accessibility, ...)
... it's difficult to schedule the meeting
... I can't resolve your clash Gary!
github: https://github.com/w3c/ttwg/issues/52
nigel: the list as it stands has
a bunch of CSS issues and one TTML one at the moment
... the TTML one is about text-combine
... then shearing
... then equivalent of multiRowAlign
... then about background area with fillLineGap
... and for that one there is a proposed solution
... then padding at start and end of line
... but the issue is closed
... and last one is images with layout information, like Apple
Pay logo
... I think there is another one about accessibility
... there is a CSS WG issue which concerns making something
invisible on a visual presentation but visible to screen
readers
... there seem to be quite a few requirement on this
... CSS WG issue 560
nigel: and that is connected to
an IMSC issue that I raised recently
... to expose burned-in narrative text to a screen reader
... sighted people can see it but we want to put that in a ARIA
live region
pal: we also issue 44 from IMSC
nigel: it is in the GitHub
list
... about TPAC planning, I have an email from Alan, one of the
CSS WG chairs
... proposing at 9:30 on Tuesday morning
... I'm going to say yes
... regarding the M&E IG, they listed 2 topics
... but there are lot more topics we could talk about
... live, karaoke, danmaku, ...
... and we could think about MSE and text tracks
... because MSE only supports audio/video
... those are my suggestions
... but we have a limited amount of time
... are there other topics or prioritization views?
cyril: when will the new text track api be discussed
<nigel> M&E IG agenda
pal: on wednesday
nigel: there is a request for
break out sessions and a request for demo
... do we want to raise the text track api with the M&E
IG?
cyril: no
gkatsev: we need to check what is the overlap between the M&E IG, the Media WG and the TTWG
nigel: that's exactly the sort of thing that the M&E IG should discuss, I'll ping Chris
nigel: Cyril raised goals at the beginning of this meeting
<nigel> scribe: nigel
Nigel: Did you have something in mind Cyril?
Cyril: We initially wanted
heartbeat publications of our spec and we deviated from
that.
... We still have a goal to publish regularly so we should aim
to publish soon
... TPAC should be the opportunity to really wrap up and work
towards publishing as soon as possible.
Nigel: Makes sense to me
Cyril: Maybe a good goal is to agree to publish FPWDs of the specs after TPAC.
Nigel: Yes, there is a publication moratorium around TPAC, but that shouldn't stop us making a resolution.
<cyril> scribe: Cyril
nigel: we have a list of topics
but an empty schedule
... I want to know if there are other topics not listed
... and if there are any constraints
pal: the only constraints I have
is that I have to leave at 6pm on Thursday
... I won't be available at all on Friday
<calvaris> I have to leave now! see you next time (if my agenda allows it)
pal: the embedded font feature should really be closed either before TPAC or at TPAC
nigel: so we should try to do as
much as we can on Thursday so that we can join the other groups
on Friday
... we could also move WebVTT on Friday
... action on me and gary to come up with an agenda
<nigel> Issue for Nigel and Gary
nigel: there is an option for
demo
... andreas asked for a joint demo from the TTWG
... any question on this demo topic?
github: https://github.com/w3c/imsc/pull/485
nigel: we resolved to support OTF
only
... since then a couple of things have come up
... where to list the supported types in a way that can be
referenced
... one idea was to use some sort of feature designation
... another is a registry of type
... if we do the feature designation, the question is where
would it be
... I suggested that we could do a module for that
glenn: I like that option
... we have already a feature designation for PNG
... in TTML2
nigel: we could potentially move
that out of TTML2 and put it somewhere else
... it's a feature at the moment not an extension
nigel: now that we can pull in
media of different types
... one way to constrain what a processor supports is to have a
feature designation for that
... it's not core to TTML itself
cyril: are we going to define a feature request for all audio codecs?
nigel: I was suggesting to do it
on requests, not pro-actively
... but we can discuss it
pal: my vote is to keep it simple
and constrain the list of supported mime types in IMSC
... I don't object to create a module or registry
nigel: so just say in IMSC the following formats are supported
pal: yes
nigel: that makes sense
glenn: even in IMSC you need
feature designation that match capabilities
... if you were to add support for OTF to #font feature that
would be going beyond what #font defines
... either you stick with what we have today or diverge
... right now all features in TTML or IMSC are attached to
feature designations
pal: are you saying that the #font feature in TTML2 is purely syntactic support, parsing the font element?
glenn: right now it only requires support for the syntax, no requirement for any font decoder
pal: I'm happy to not define any
extension in IMSC and just say the font format we support
... or to define an extension in IMSC that signals specific
font support
... or to define an external module
... or to define an external registry
... but we need to make a decision
<Zakim> nigel, you wanted to add an option for a ttp:types element with a ttp:type child (1..*) under profile
glenn: in my opinion, the best option is to use feature designation
nigel: we could add a new element to the profile element, adding a ttp:types attribute
glenn: you're suggesting a new element
nigel: yes, following the same pattern we have today
glenn: it's worth thinking about
it
... in some way it introduces yet another mechanism for
defining functional support
... we have feature and extension and we would have a 3rd
thing
... but for IMSC there may be shorter options
nigel: the easiest path is simply to list it in the IMSC spec
cyril: I would favor this option
nigel: let's keep discussing that
point
... on the topic of formats, compressing fonts is an important
features
... we should allow for WOFF
... I'm proposing to add support for WOFF
cyril: my point is that OTF is
broad, it includes TTF, CFF, SVG outlines
... and also WOFF has a new version WOFF2
pal: I'm happy as long as we can feedback from implementers
cyril: is there an option where we do not specify in IMSC and let applications specify it
pal: maybe a minimum
... and not preclude other types
glenn: we could also mandate support for specific open source fonts
<inserted> Nigel: Please remind your AC rep to vote. When is the deadline Atsushi?
<atsushi> > The deadline for responses is 23:59, Boston time on 2019-09-10.
nigel: we will not have a meeting next week, our next meeting will be at TPAC
<nigel> scribe: nigel
Nigel: Thanks everyone, we got through a lot today. See you in Japan! [adjourns meeting]