See also: IRC log
<cyril> scribe: Cyril
nigel: we'll talk about charter,
and as sub-point, explainers
... on the ttreq, we have 3d reqs on the agenda
... webvtt
... in terms of TTML2 and TTML3 nothing on the agenda
... we have one item for the profile registry
... AOB I duplicated the event
... from last week
pal: do you have issue 1043 on
the agenda?
... also I would like to make progress on fonts and embedded
font files, IMSC issue 472
nigel: on 1043 I took the agenda off last week because we said we'll talk offline
pal: on 472, it's about how to prevent somebody from going crazy here
nigel: we don't have plh yet
[later update: he joined a few minutes later]
... is everyone happy to send the draft to W3M for review in
order to submit it to AC
... any objection to it?
pal: we spoke a lot about it and we're all happy
RESOLUTION: forward the current draft charter to W3M for review
nigel: next one is we set a
deadline for explainers
... there has been some work which is good
... not everything is there
... we have 2 explainers on the wiki
<nigel> tt-reqs wiki
nigel: one on audio description and one on karaoke
cyril: I have 2 explainers left: responsive timed text and advanced japanser
nigel: I had to do an explainer
on live
... I'm waiting for some elements from EBU
... it's good to have some progress
... it would be good if people could have a read and send
feedback
<nigel> scribe: nigel
Cyril: I wasn't sure exactly how
to write the explainer, and am not sure if it's what was
expected.
... It seems to be a living design document.
Glenn: I think we're overblowing
process. We should not mandate these explainers.
... On the point about karaoke, I have to say I'm not on board
with the proposal in terms of the approach
... and need to discuss an alternative way that does not
introduce a new element type.
Cyril: I'm open to discussion.
Glenn: I have some ideas about
how to do it. I think we should avoid prematurely
documenting
... design choices that might make the explainer
misleading.
<cyril> scribe: cyril
nigel: I don't see a problem with
having a living document
... describingg the design
... it's a tool to try and reach consensus
... we should try to produce them
plh: it will take a week or two
to get feedback on the charter
... I don't expect to receive much feedback given that the
document is light
nigel: do you need anything more regarding deliverables
plh: I would expect the charter
to be approved by the director by the end of june
... since there is no change of scope, we can go ahead with
working drafts
... I'm not even sure we'll send a new call for
participation
nigel: one goal of the charter
revision was to make it clear that the audio description would
be in charter
... members of the audio description cg might join
... it was unclear that we had audio description on the
charter
plh: then I will issue a call to join and you will have 45 days to rejoin
<nigel> scribe: nigel
Cyril: On the Karaoke proposal
I'm trying to implement a renderer for the new features
... I'm trying to represent quite complex examples and try to
make sure that it is simple for simple
... examples. I also have a draft specification but it might
completely change depending on the outcome.
... I wrote it as an extension to TTML2 in the sense that it
defines a new feature, just one at the moment.
... It is an extension in the sense that it defines some
vocabulary that is added on top of TTML2.
... It doesn't mention modules.
Glenn: Just to let you know what
I'm thinking is that instead of an element type have a
new
... attribute tts:marker with some values. We should discuss
this further.
Cyril: Yes, I'm open to discussing it. I would like to conclude soon to move to a FPWD.
Glenn: Let's schedule some discussion time
Pierre: I'd like to be part of those discussion
Philippe: I don't know how this relates to the old CSS aural properties
Glenn: I don't think it's related
at all. I'm familiar with those.
... The new audio properties intersect with those but not the
marker concept.
Philippe: I don't think those old
CSS properties were implemented largely.
... I wanted to add that Explainers are wanted by the TAG for
example.
... It's not just for the purpose of a WG conversation. It will
be useful further down the line.
Cyril: I agree to write these
explainers especially for that purpose.
... Otherwise I'm of the opinion that it adds a burden as
Glenn.
<cyril> scribe: Cyril
nigel: explainers will be helpful for others
plh: to determine if they want to review the specification
nigel: any other comment on the explainers?
atai2: I wanted to give an
update
... there are 3 things we need to consider
... 1 reqs have been submitted
... 2 liaison sent to MPEG
... 3 discussion on going with broader community
... for the requirements, after discussing with stakeholders,
we need some more discussions about the scope
... one main question is if it should be just for subtitles in
360 or omnidirectional media or should it be applicable to VR
and AR
... first reaction is always yes
... but then for AR and VR it's much more complicated because
the viewer is moving
... we need to discuss if we want to limit the scope
... MPEG liaison is only 360
... from the draft from MPEG, it's really another area we need
to work in
... we need to see if need to specify additional information
items, positioning ...
... or if we have a complete different environment that we need
to work with
... we could review how fonts are handled
... I think we should just discuss MPEG draft deeply
... on the broader discussion, the immersive web always asks to
open an issue before they decide to work on it
... Peter filed an issue there
... some discussion on-going
... I tried to get attention from accessibility groups
... I spoke to Alan Sterns from CSS
... we need to have a broader spectrum of people looking at
it
... there will be a call on May 21st, 10 am PT, to discuss this
in the Immersive CG
... everybody can join
... I hope we can have a discussion on the TTWG meeting next
week before the call to see how the grgoup handles this
issue
gkatsev: last night I submitted a
PR to add in a couple of file tests missing
... I've always started thinking about what to say in the IR
and should be able to produce it soon
nigel: the Web Platform tests
have not been rerun
... are they run nightly?
... possibly not every day
plh: are they run automatically?
gkatsev: I think so
... are you talking about wpt.fyi ?
... because a lot of the tests are rendering tests, my
spreadsheet is probably most up to date
nigel: ok so we expect the IR in the coming week
nigel: about issue 71
<nigel> github: https://github.com/w3c/tt-profile-registry/issues/71
cyril: the request is to add a
substantive change in the IANA section that defines the
combination operators
... mike is not on the call for a while
... but he does think that it ought to be there
... my recollection is that it should be defined and compliant
to RFC
<nigel> glenn: we have to qualify what you mean by "define"
cyril: it is not defined in the body of the media type registration
nigel: at the moment it is defined what it means
<nigel> scribe: nigel
Cyril: The syntax is defined but
absent from the IANA registry.
... It seems odd to have an informal definition when the rest
is formal.
Glenn: The only issue previously
was if we should trigger the IANA review process.
... If everyone is happy with that then we can go ahead.
Pierre: I'm not objecting to
going through the IANA process but noting that we have
trouble
... getting this out so I'm concerned about our level of
resource.
Glenn: We have updated our
document and IANA references our document so we have
formally
... updated it.
<cyril> scribe: Cyril
cyril: I will prepare a PR
nigel: I don't share the concern about resources given that we don't have a hard deadline
github: https://github.com/w3c/ttml2/issues/1043
nigel: last time we said that we would deal with this offline
pal: given that we are all here, we could have a shot at closing it
glenn: let's spend 5 min
pal: my homework was to review
Glenn's PR
... there are 2 subtle points: text nodes being ignored and the
applicability of styles to containers
... the PR that Glenn had proposed adresses both
... I'm happy with the way the PR adresses the first
point
... not found a better way of doing it
... on the second part, I'm less happy
... it's buried in a note
... and it does not address specifically if a propery applies
or not
glenn: it's my opinion that if we
define that LWSP is ignored in that context, irrespective of
white-space attribute, for presentation
... and if we say that LWSP is forbidden
... we just need to add text for the error case
pal: look at the example I posted
in 1043
... there are 2 underlines that appear underneath hello
nigel: I did not notice that before
pal: my question is do we actually want text decoration to apply to the text container, ever
glenn: you can construct an
example that does not even involve ruby
... with outer spans and inner spans
... the intent of the specification is to not apply to all of
them
... also similar to XSL FO
pal: for div and p, this is
obvious that it does not apply
... what I have not tried is the difference between inline
block vs inline
glenn: the semantic model for
decoration in TTML is that it only applies to the most deeply
nested text characters
... you don't have decorations applied to upper level
... ttpe does not do the behavior you are describing
... it may be an artefact of CSS or IMSC.js
pal: I'm of hte same
opinion
... that it does not apply to text container
... but I want it to be clear
glenn: I'm not happy to have the
same text in all properties
... I can tweak the note
pal: that note is not
sufficient
... it does not cover the case we are looking at right now
nigel: Pierre's proposal very
clearly is to add a clause to apply to to the various style
attributes
... to add unless text container or ruby container
... any objection to that?
glenn: we decided to avoid repetition
nigel: you can refactor that to
avoid repetition
... for example defining a term for a class of span
glenn: on this text decoration, I'm not sure that an interpretation of TTML2 can lead to that
nigel: my reading of this is that
you can interpret it that way
... if you think adding a normative statement is a no-op
... there should be no problem going ahead
... we are over time, we'll adjourn to same time next week
<plh> regrets for next week