<nigel> Log: https://www.w3.org/2019/06/20-tt-irc
nigel: we have WebVTT
… for TTML we don't have the right people
… profile registry
… Mike declined for this meeting
… progress on PNG PQ
… update on charter
… AOB: karaoke
nigel: gary has done a snapshot
gkatsev: it's marking 4 things at risk
… text combine upright, text wrap balance, line and position alignment
… the last 2 are probably supported in Firefox and vtt.js but it's safer to mark them at risk
nigel: what are we doing with unsigned long?
gkatsev: silvia mentioned that there is not int in WebIDL?
… we can use the regular long, it's the right range but allows negative values
… however the spec says that negative values should throw
… for now I've split the test into an int range that passes
nigel: [does some binary maths] your change should work
gkatsev: I should update my PR to remove the second test
nigel: In a way it was a weird thing for the spec to say that it should throw for neg values when they were not possible
gkatsev: I'll update that today
nigel: to see the snapshot what do we have to do?
<gkatsev> current at-risk snapshot
nigel: we'll review that
nigel: the summary for this week is you made tests, we approved but they are not merged yet
… could you review them?
gkatsev: yes they pass in Safari and Firefox
… there was the issue regarding the cue box sizes
… and it seems a reasonable change
… but I probably don't want to do it now
… yet another moving part
… Is make such change just before CR ok?
nigel: It can be done but it depends on the impact of the change
… I'm not clear on the impact for this one
… I would like to have PLH's input on this one
… If you can demonstrate 2 implementations
… is it related to writing direction?
gkatsev: if you have text alignment left or right, the position is correct
… but if start or end, it won't be aligned properly
nigel: so it's a bug
gkatsev: start and end were added a bit later
nigel: the implementations do what the spec says?
gkatsev: yes
nigel: so if you fix the spec, the implementations will have to change?
gkatsev: yes
… making a normative change feels that it would take longer to get the CR out
… I will ping PLH on the issue directly
nigel: yes that needs more thought
… the impact is that for right to left if you rely on start or end it won't work
… so there is a work around?
gkatsev: yes
nigel: it doesn't sound that the impact is massive if we don't fix it now
gkatsev: yes, the workaround is use right or left instead of start or end, depending on the writing direction
nigel: anything else on VTT?
github: https://github.com/w3c/ttml2/issues/1117
Cyril: The context is that I started discussing internally at Netflix
… with teams who implement HDR on games consoles, asking how to render luminanceGain.
… People looking at the spec for the first time were confused by the term "gain".
… It's an absolute luminance but called a gain. Initially they thought it was gain relative to graphics white.
… You can discuss with the TV to know what its graphics white luminance is. They interpreted it
… as compared to that and not compared to 18 nits which the spec says.
… The spec is not unclear, but they had an assumption.
… We agree with what is written in the spec and Fox proposed this clarification. We think
… it is a good one.
Nigel: Will you propose a pull request?
Cyril: Yes, it will be a Note saying that the gain is relative to 18 nits and not to a relative value
… corresponding to the device graphic white, or something along those lines.
Nigel: Ok, looking forward to seeing the pull request for that.
github: https://github.com/w3c/tt-profile-registry/issues/71
Nigel: It's been a while since we opened this and we haven't managed to get to it.
Cyril: I haven't had a chance to work on it.
Nigel: Comment from 11 April, we need Cyril, Mike and Glenn on the call. Let's move on for today, since we don't have all those people.
github-bot, end topic
cyril: this seems purely editorial
nigel: yes
… I have changed the link on the repo, as requested on the repo
… and I have created a PR to add link to the editor's draft in the readme
<nigel> Pull request #9
Cyril: I have made a first editor's draft of the Karaoke module.
… For the record, I'm uneasy with the term Module, and have had lengthy conversations with Glenn.
… My position is if we promote the term Module to a bigger state, to be more visible, we will have
… terms like Specifications (TTML), Profiles (IMSC), Features (feature designators),
… and my view is the term is only in TTML in the two tables in §5 which list the modules as a collection
… of elements or attributes. I think it is confusing for a new specification to say it is a module.
… What people will care about is the module defines one or more features, which a profile can then
… include. That's the only thing that is needed.
… I'll follow what the group decides but I think it's confusing.
… I know CSS uses the term Module so maybe people are familiar with that.
… It is related to the text in TTML3 that talks about public/private modules and the module registry.
… To me this is too much, we don't need to introduce all these notions to define a new specification.
… I called this an extension not a module, with reference to HTML5 MSE and EME.
… Glenn noted we have extension designators already in TTML so the term is used.
… I'm open to a different terminology.
Gary: I agree there are a lot of different names and limiting the terminology is a plus.
… I'm not sure the best direction.
Nigel: I agree that we don't need the additional terminology in TTML3, and have made that pretty clear
… in a comment on TTML2 pull request 1066
Cyril: We merged the change to TTML3 though?
Nigel: Yes I feel we were pushed into that and I don't like it.
… So I agree about using less terminology where we can.
… Where I think I do agree with Glenn is the word "module" to be a specification that defines some
… additional features seems fine to me, especially since those features are grouped by some
… technical theme.
… If using Module means less change to TTML that's a good thing.
Cyril: You would say the new spec is the Karaoke module but don't introduce internal/external,
… and just remain silent. We don't need to define what the module is?
Nigel: Yes
Cyril: Okay I could live with that.
Nigel: I think we just can say in the Karaoke module that it is a specification that defines some TTML2
… features. We don't need anything more.
Cyril: I won't define any profile.
Nigel: That's clean
Cyril: My intention is we would add a new profile elsewhere, IMSC1.1K or whatever (don't know the name)
… I tried to define this module by adding the minimum number of elements and attributes.
… There are no new elements, only 3 attributes.
… One of them is a styling attribute tts:imageEmphasis, building on the semantics of textEmphasis
… but replacing the text by an image when textEmphasis is set to "auto".
… Initially you could have thought about changing textEmphasis to add a URL but that would have been
… backwards-incompatible and existing implementations would break.
… So I preferred creating a new attribute. If it is ignored the emphasis will be a text not an image,
… so there is graceful degradation.
Nigel: I like the sound of that!
Cyril: Glenn asked if an attribute should be a parameter or a style attribute, saying we only put
… parameter attributes on the root element so it should be a style attribute.
<cyril> Karaoke module
Nigel: I see, ttp:karaoke to define a _section_, no, I agree that doesn't look like a parameter attribute.
Cyril: Styling properties have a notion of inheritance and applicability, but that doesn't apply here.
… A karaoke section allows the presentation processor to override the semantics for the relevant section.
… For example a song inside some other content that is used for karaoke
… I wanted to raise the general question - what is the philosophy behind a parameter attribute?
Nigel: My understanding is that a parameter attribute sets up the processor with some settings or
… constraints that apply when processing the entire document, so it only makes sense to have them
… on the root element.
… This karaoke attribute does not feel like a parameter attribute.
Cyril: Ok, I'll change it.
Nigel: But what to?
Cyril: A styling attribute, applicable only to body and div
Nigel: That works, or you could use a new namespace
Cyril: No, we have enough of those!
… The last thing is the general philosophy of the spec is that you could do limited karaoke with TTML2
… today, because you have a set and animate element.
… Two problems:
… 1. When the processing engine sees an animation it does not know it is karaoke, so no semantics
… associated with it. The engine cannot apply its own settings on the basis that it is karaoke.
… We want to detect if content is karaoke.
… 2. TTML2 is limited - the bouncing ball above the text cannot be specified.
… This spec adds semantics to identify where the karaoke content starts and animations can be
… overridden, and adds more animation types.
… karaokeMode allows the emphasis to be applied with text emphasis or with colour.
… Please read, open issues and I will propose changes.
Nigel: We should find a way to get the word out on this.
Gary: Maybe Crunchyroll?
… I know a lot of people in anime community do karaoke for the opening songs. They might be interested.
Nigel: It would be good to get input from this as soon as possible.
Cyril: Glenn said this should be TTML1 applicable not just TTML2. Nigel what do you think?
Nigel: If you need textEmphasis you have to depend on TTML2, it isn't in TTML1
Gary: Maybe say "if textEmphasis available then this applies" rather than the direct dependency on TTML2.
Cyril: Yes
Nigel: Good idea, if that can work
Cyril: I may define one feature for emphasis based karaoke and another for colour based and in TTML1
… only the colour based karaoke could work.
Nigel: Good idea
Cyril: Please open issues and we can discuss that.
Nigel: OK, thank you!
Nigel: Thanks everyone, we couldn't discuss the charter etc because Philippe couldn't make it - he tells
… me by IRC that he is in the thick of some deep discussion. So we'll adjourn for today. [adjourns meeting]