Timed Text Working Group Teleconference

09 Nov 2017


cyril, ericc, atai, pal, nigel, tmichel, glenn, astearns, florian, wdh, fantasai, rossen, hober, plinss, dbaron, wseltzer, dsinger, silvia, chris_needham(BBC)
nigel, dsinger


Agenda sweep

<nigel> nigel: Will break at 1500 and other times.

<nigel> cyril: Timeline for getting TTML2 to CR?

<nigel> glenn: Should discuss that.


<nigel> glenn: Glenn Adams, Skynav

<nigel> cyril: Cyril Concolato, Netflix

<nigel> tmichel: Thierry Michel, W3C Staff contact

<nigel> nigel: Nigel Megitt, BBC

<nigel> pal: Pierre Lemieux, supported by Movielabs

<ericc> Eric Carlson, Apple/WebKit

<nigel> atai: Andreas Tai, IRT

<nigel> flick: Chris Flick, Apple

<nigel> ericc: Eric Carlson, Apple

<nigel> scribe: nigel

dsinger: David Singer, Apple

Agenda topics

Nigel: [iterates through topics]

pal: We can probably do IMSCvNext reqs pull request #10
... On TTML2 there are some issues ongoing we can discuss.

Nigel: MediaOffset

pal: Another one is IMSC 1.1 pull request on profile signalling and resolution #267

IMSC vNext Reqs: Require profile signaling #10

IMSCvNext Pull Request #10

pal: This came from Glenn's review of the requirements document

github: https://github.com/w3c/imsc-vnext-reqs/issues/5

pal: Looking at the long thread on the PR, trying to solve the problem of signalling of profile
... in the requirements document is probably not the right place to do it. It's too complex.
... In the requirements all we need to say is that the profile signalling mechanism in TTML2
... should be used whenever possible.
... This matches a pull request already open on IMSC 1.1.

nigel: Yes, the requirements document needs to be appropriately scoped.

pal: The change now is "The profile resolution semantics and signaling specified in [[!TTML2]] SHOULD be used whenever possible."

RESOLUTION: Approve IMSCvNext requirements pull request #10

pal: Thanks! I'll merge it.

Ethics and Professional Conduct reminder

nigel: I've remembered Chairs have been asked to remind group members that we are
... working within a code of ethics and professional conduct, so Be Good People!

Code of Ethics and Professional Conduct

Updated profile signaling and resolution to match TTML2 semantics #267

github: https://github.com/w3c/imsc/pull/267

glenn: I'd caution against paraphrasing what's in TTML2

pal: That's the goal, to avoid doing that.
... §7.8: This is about signalling profile conformance in the document.

glenn: Just to check the intent is to signal the content profile and the inferred processor profile?
... I'm wondering why you chose the content profiles path. It's okay, you get both that way.

pal: Yes, the profile resolution semantics always lead to a processor profile anyway.

glenn: Because of the way the inference process works in TTML2 you may want to review
... this for any implications that are not wanted. You might want to assume something, the
... defaults, for those things that are prohibited.

pal: We'll add that in §5.4.

nigel: That's a good call - we've been tripped up by that kind of thing before.

glenn: Yes, especially when you prevent the author from making the statements.

nigel: Note a structural issue with this, referring to following sections unscoped.

atai: Maybe list the specific section numbers.

pal: Okay, I've made a note.
... OK, then if you want IMSC 1 compatibility.
... This mimics what's in IMSC 1 today.

glenn: Processing compatibility of document conformance compatibility?

nigel: What does it mean to say a document instance is compatible with a processor profile?

pal: IMSC 1.0.1 processor can successfully process the document instance

nigel: Maybe we don't need the "and compatibility with 1.0.1 processors is desired" clause?

pal: No because contentProfiles is not prohibited by 1.0.1

nigel: But if it is allowed in 1.0.1 then why don't we make it a SHOULD NOT be present
... rather than a SHALL not?

pal: We don't want to add confusion in the marketplace by permitting TTML2 syntax in
... TTML1 documents.

glenn: Propose adding a note to help a reader understand why there's a shall in one place
... but a shall not here.
... Something about the intent, otherwise it seems like a strange thing.

pal: Nigel objected to the "mutually exclusive" wording.

nigel: I don't mind stating they're mutually exclusive, but the way it was done was confusing.
... Playing devil's advocate here, we generate a state where a conformant IMSC 1.0.1
... will become a non-conformant IMSC 1.1 document if ttp:contentProfiles is present?

pal: Correct

nigel: Wasn't it one of our design goals to avoid that?

atai: I think ttp:contentProfiles is not conformant IMSC 1.0.1 because it's not vocabulary permitted in TTML1.
... TTML1 only allows content within its own model.

nigel: That flips the scenario completely - it means that the current text is correct.

pal: Glenn, is this correct that ttp:contentProfiles is prohibited in TTML1?

glenn: We have an issue in TTML1 on this, but we did not nail down the use of vocabulary
... in existing TTML1 namespaces.

atai: The schema design prevents adding arbitrary content being added to TTML1 namespaces.

glenn: That's not correct, in that the notion of validity in TTML1 is assessed after removing
... all unknown vocabulary, so we can only talk about content compliance in TTML with
... respect to the post-processing state of an abstract document instance in the infoset, at
... which point all unknown vocabulary has been removed. So you can't tie it to a schema.
... This language has an issue - w3c/ttml1#251

<glenn> https://github.com/w3c/ttml1/issues/251

glenn: It's my contention that the appearance of TTML namespace vocabulary not defined in TTML1
... should not cause that document to be non-conformant. That includes TTML2 vocabulary,
... which would simply be removed by a TTML1 proessor.

nigel: In that case can we change the SHALL to a SHOULD.

pal: Okay, let's make it a SHOULD NOT.
... Continuing: EBU-TT-D compatibility

nigel: Just an editorial tweak - it's not a single conformsToStandard element, there are
... possibly multiple, but at least one of them needs to include the 1.0.1 designator.

pal: There's a note here too.

atai: In EBU-TT-D 1.0.1 there will be a new URI for conformsToStandard so we need to update that.

nigel: Also the reference will move from EBU-TT-D to EBU-TT Part M.

pal: Need to raise issues for those please.
... SDP-US compatibility
... Not much to say here.

nigel: It's pretty simple!

pal: Now §5.4 Profile Resolution Semantics
... All the TTML2 algorithms apply including the ones in the TTML2 pull request that introduces the "override profile" term.
... The TTML2 algorithm gives you the processor profile.

glenn: Does IMSC ever specify a profile definition document?

pal: No it's inferred.

glenn: I recommend coalescing that data into a profile definition document in the appendix.

pal: That would require a new extension for every additional constraint, which is a pain.

nigel: Who would it be useful for?

glenn: Implementers and authors. I take the point that creating new extension features would be difficult.

atai: It is done this way in IMSC 1

pal: I've had no requests for a profile definition document for IMSC 1

nigel: Summarising, we did not agree to add a profile definition document for IMSC 1.1.

pal: §5.4.2 Override

nigel: Hung up on the wording of the 2nd/3rd para

pal: Yes, I need to update that to deal with there being multiple elements each with a single value.

glenn: The first sentence seems to duplicate TTML2.

pal: Those statements are not present in TTML2

glenn: There's an algorithmic approach that I think ends up with this.

pal: I could not find it - for example TTML2 is silent on how to set the override content
... profile. It just says what to do if it is set.

glenn: I see, so this is providing a mandatory link between the presence of a profile in
... the context and the override profile.

pal: Yes

glenn: Is there an ordering? What if both the statements are true and resolve to different override profiles?

nigel: We have to deal with that, they could easily both be true and different.

glenn: I would remove the "or the document interchange context".
... TTML2 § (merged this morning) deals with this

pal: That step 1 needs to additionally include the document interchange context

glenn: The way the document processing context is obtained is a black box, a processor
... might choose to use the document interchange context.
... In my mind the current language in TTML2 permits what you need.

pal: Not explicitly - in HbbTV for example the profile is set outside the document processing,
... it just says to treat the document as an EBU-TT-D document.
... Sometimes the document comes in without any inband signalling.

glenn: The semantics of specifying a content profile are useful for 2 purposes, one is
... for validation processing and the other is for inferring a processor profile.
... There's already language in the construct default processor profile that does take into
... account the document interchange context, so that means you're adding to validation
... processing, where a processor would override any consideration of content profile that
... the author may have specified.

pal: If I specify no content profile, and the document interchange context specifies a processor profile,
... then your argument is that it applies to [construct default processor profile]?

glenn: Correct. The reason I wrote this is because I didn't want to allow the processor to
... override the determination of the content profile based solely on the document interchange
... context.

nigel: Why not?

glenn: Because it would mean for determining the default only the interchange context would override the authorial intention.

pal: We can change the first sentence in §5.4.2 Override. I propose to remove it, and move
... the example to the previous section §5.4.1 General

glenn: That works for me.

pal: Just to understand, in the example, the DASH manifest sets the default processor profile
... not the override content profile?

glenn: Correct.

pal: That's all on this pull request, I have all the actions I need to close this.

<r12a> https://lists.w3.org/Archives/Public/www-style/2017Nov/0006.html

What fillLineGap does/ affects #254

github: https://github.com/w3c/imsc/issues/254

IMSC1.0.1 fillLineGap

pal: There are more examples of this in the IMSC spec now, compared to when the issue
... was raised.

glenn: This might depend on if the line area includes leading or not. In our model it does
... include the leading.
... We assume that line areas abut each other.

pal: That's how CSS works, it stacks the line areas with no gaps between them.

glenn: The issue raiser's model may differ, so it may be worth clarifying.

nigel: I think the main concern is that it could cause parts of letters or symbols to become
... effectively invisible.

r12a: I was looking at that too - need to think about ascenders and descenders, which in
... some languages like arabic can be quite long.
... I think the question is if the background definitely extends to cover those.

pal: That goes back to XSL and CSS - this section doesn't change that at all.
... It sounds like the concern does not relate to fillLineGap specifically, but to the application
... of background on span.

glenn: There's a valid point, which is can the author avoid doing something stupid or is it
... an instruction to implementers. It sounds like his concern is we could force the processor
... to do something that makes the author do something to address visibility of glyphs.
... In fact there's no constraint in any of the specs that the outline of the glyph be inside the
... em square. This is the case where the author needs to be aware of that.

pal: fillLineGap does not make this worse because it does not apply new background, it
... only extends existing background, so it can't make anything worse, only better.
... Example: white glyphs, black background, which is extended to cover parts of glyphs that
... overlap non-background.
... The line stacking strategy means the line height must be greater than or equal to the computed lineHeight.

r12a: In CSS you can set lineHeight to 0.5 and the glyphs may overlap each other.

atai: In the line stacking strategy in TTML that is prohibited.

pal: On this issue I propose to clarify that fillLineGap does not add background but extends
... existing background.

nigel: I think the point to clarify is that the line area before edge and after edge can never
... be within the content rectangle, so there can never be a case where setting the background
... to the before and after edges of the line areas makes the background get smaller
... than it would be without fillLineGap.

atai: I propose to add a note to the spec section to say that the application of fillLineGap
... does not result in hiding any characters that would be visible without fillLineGap.

nigel: I propose to add a note that the line stacking strategy for TTML means that the
... application of fillLineGap can never make the background smaller than if it were not applied.

r12a: Another way to say it is that the background that is applied will cover all parts of all the glyphs.

atai: Yes, to say after application of fillLineGap all parts of all glyphs with a background
... colour behind them continue to have that background colour applied.

pal: I'll propose text.

<cyril> what about ruby?

pal: this is IMSC 1.0.1

glenn: I'm not sure I've defined that very carefully for presentation semantics of TTML2,
... but I have the assumption that ruby glyphs are contained within the line area.

RESOLUTION: Add a note to say: Note: The application of fillLineGap does not result in hiding any character glyphs that would be visible without fillLineGap. Therefore after application of fillLineGap all parts of all character glyphs with a background colour behind them continue to have that background colour applied.

Should UTF-8 'as specified in' point to the Encoding spec? #253

github: https://github.com/w3c/imsc/issues/253

glenn: My response is "no" it should point to Unicode.

r12a: The first question is does it have to point anywhere? People don't normally reference
... a definition of UTF-8.

glenn: There are different definitions of UTF-8 so we need to nail which one we mean.
... All current TTML specs refer to Unicode for that definition.

r12a: Unicode defines UTF-8, the encoding specification defines it in terms of conversion
... between legacy encodings and UTF-8 code points, but does not define UTF-8 per se.
... Which of those do you need or want?

glenn: We don't refer to legacy encodings anywhere so we don't have a normative requirement
... to say anything. There's just UTF-8, and how it got there is outside of the scope.

atai: How does HTML5 handle this?

nigel: It seems like nobody thinks we need to make any changes here?

<cyril> regarding the previous resolution, there should be matching normative behavior that produces what the note says. You cannot simply have a note that says "does not result"

RESOLUTION: We do not need to refer to the Encoding spec and do not need to make any change.

nigel: I can't label this because the labels aren't on the repo for WD tracking.
... I've raised #282 for Thierry to add them.

Meaning of 'glyph area descendant' #236

github: https://github.com/w3c/ttml2/issues/236

Nigel: Would switching "glyph area descendant" to "descendant glyph area" help?

r12a: Yes it would help a bit - now I understand you mean the first descendant that is a glyph area.
... And that you don't mean a descendant of a glyph area.

glenn: I could add a note to the definition of glyph area to say that glyph areas have no descendant areas
... I could also add a Note to §

r12a: Would you consider "which is" before each "descendant"?

glenn: I could do that.
... I also note that the third instance of "glyph area descendant" in that section doesn't say what it is a descendant of.

RESOLUTION: Add "which is a" before "descendant".

r12a: I will review the definition of glyph area from the pull request too.
... Where the text says to count the glyph areas, what is a glyph area?

glenn: In the area tree there are a number of glyph areas, but the question is how is that
... tree constructed. This algorithm doesn't define that, it assumes it has already been constructed.
... It's viewed as being outside the scope.

nigel: Any other implementers here who need to construct the area tree?

cyril: Yes, we have done it for Japanese.

r12a: That's the easy case.

glenn: I wanted to avoid saying anything about graphemes here and keeping it on the topic of layout.

r12a: It is much less likely that there would be arabic or hindi ruby which would be a more complex case.

glenn: There may be other open issues that are affected by this too.

pal: How does this compare with what CSS does?

r12a: CSS doesn't talk about glyph areas at all.

glenn: They leave that to implementation details.

r12a: They don't have to count things.

glenn: They don't have a withBase alignment.

r12a: Correct.

flick: Or height in vertical flows.

r12a: The context here is withBase that requires counting.

glenn: The JLReq does go into this area, talking about sizing effects of 1 vs 2 vs 3 ruby
... associated with a base, which in Japanese typography there are conventions for.
... This doesn't go that far but it does start going further than CSS.

cyril: CSS talks about boxes rather than glyph areas, and the alignment is based on boxes.

glenn: They're synonyms - XSL uses "area", CSS uses "box" to mean the same thing.

cyril: Netflix doesn't use "withBase" so possibly a solution would be to defer this functionality.

r12a: We were quite surprised about withBase. My understanding is that this withBase is a
... thing that lambdaCap does so it is in the spec.

glenn: It came out of my analysis of what would be needed to support lambdaCap.

pal: If there are no lambdaCap files including it, then it would be safer to put it at risk or remove it.

nigel: We are working towards CR now so we could mark it at risk now.

flick: That would be a signal to people who are interested.

RESOLUTION: Mark rubyAlign="withBase" as at risk for CR

glenn: If it is an optional feature and our exit criteria require one implementation of each
... optional feature then this is already satisfied.

r12a: I checked my dictionary for any examples where this would apply, and could not find any.
... Either in Japanese or with Pinyin. So it was all a bit weird to me.

glenn: I'm pretty sure there's language on this in the lambdaCap spec also.

Ruby align 'withBase' semantics #248

github: https://github.com/w3c/ttml2/issues/248

cyril: Netflix doesn't use "withBase" so possibly a solution would be to defer this functionality.

r12a: We were quite surprised about withBase. My understanding is that this withBase is a
... thing that lambdaCap does so it is in the spec.

glenn: It came out of my analysis of what would be needed to support lambdaCap.

pal: If there are no lambdaCap files including it, then it would be safer to put it at risk or remove it.

nigel: We are working towards CR now so we could mark it at risk now.

flick: That would be a signal to people who are interested.

RESOLUTION: Mark rubyAlign="withBase" as at risk for CR

glenn: If it is an optional feature and our exit criteria require one implementation of each
... optional feature then this is already satisfied.

r12a: I checked my dictionary for any examples where this would apply, and could not find any.
... Either in Japanese or with Pinyin. So it was all a bit weird to me.

glenn: I'm pretty sure there's language on this in the lambdaCap spec also.
... I think withBase may be being used under the covers in the Netflix implementation without it being obvious.
... The currently defined auto semantics for rubyAlign is based on withBase when Nr = Nb.
... That encodes the lambdaCap semantics in the semantics for auto.

cyril: But we are requesting that auto be changed to center.

nigel: And that doesn't use withBase?

glenn: No, when center is used it doesn't use withBase semantics, it doesn't distribute any space between the ruby glyphs.

cyril: We'll take it offline and come back with an issue.

NR is less than NB and NB is equal to 1 #249

github: https://github.com/w3c/ttml2/issues/249

cyril: rubyAlign="auto" when the number of rubys is less than the number of base glyphs:
... when the base characters is 1, use space around, or for greater than 1, use space between.
... But when there is only one base glyph, the number of ruby glyphs must be 1 too, so there's
... no difference in that degenerate case between space between and space around.
... If we resolve to use the semantics of "center" for the semantics of "auto" in all cases then this issue goes away.

r12a: Regardless, this is still odd text.

cyril: Is there a difference between space around and space between when there is only
... one glyph area?

glenn: There would be nothing to put between, so I don't think so.

nigel: I've raised #489 for the "otherwise" applying too broadly.

<glenn> see https://www.w3.org/TR/jlreq/#ruby_and_emphasis_dots for discussion of ruby alignment

TTML2 Ruby alignment with HTML and CSS

ericc: Is there a plan to align TTML2 ruby with HTML?

nigel: I think there's a syntactic mapping from TTML2 to HTML here, but there may be some CSS issues.

cyril: That's for tomorrow - I've been discussing with CSS folk and there may be existing
... ways to achieve the ruby semantics in CSS that we weren't aware of before.

<cyril> https://www.w3.org/wiki/TimedText/CSSRequirements

CSS Requirements gaps analysis

r12a: We have concerns about nested rubys. i18n has a plan to simplify the ruby content
... model by taking out nesting for example. The default would probably be to use the tabular
... approach as opposed to the interleaved approach.
... The tabular approach is clearer and has some advantages strategically for CSS. It's only
... supported in Firefox unfortunately at the moment.

glenn: I would imagine tabular is better for parenthetic presentation too.

r12a: Yes
... If you had To kyo (to) (kyo) with the interleaved model you would end up with To (to) Kyo (kyo)
... This is a "gleam in our eye" at the moment.

Nigel: One anecdotal data point from a chat yesterday with a Japanese consultant, who pointed out
... that often the inline markup of Ruby for captions is easier to read because the ruby glyphs
... are bigger.

cyril: If we are going to make changes like this, to be applicable for CSS, WebVTT, TTML etc
... what does it mean for TTML2? Should we change the content model?

r12a: The timing is unfortunate.

pal: There could be a future version of TTML

cyril: Should we spend time working on this now though?

r12a: Go ahead with what you have. Your implementation of ruby is fairly simple anyway,
... since you're not using nesting.

flick: Are there any particularly complex ruby implementations to mark as less used and
... for solving later?

r12a: Yes there may be some, I'm not sure what they are, maybe double sided ruby where
... the top doesn't have the same application as the bottom but they overlap.

pal: I'm keen to remove features we aren't sure of. It's more harmful to include it now
... as opposed to removing it now and then adding it back in if/when we need it.

tts:fontVariant is needed to select half vs full variants in Japanese text #6

github: https://github.com/w3c/imsc-vnext-reqs/issues/6

r12a: There are no half width Unicode latin characters.

pal: Are we happy with the variations offered by Unicode alone or do we also need fontVariant?

r12a: CSS does stretch and shrink and JLReq says always make say "2017" fit within the line.

pal: TTML says the renderer should make it fit. Glenn also suggested using tts:fontVariant,
... and @ @

glenn: Sometimes fonts offer more legible versions of half and full to make ruby more readable.
... The question is do we need fontVariant when it may be satisfactory to use Unicode.

pal: Yes, and the recommendation to tell the renderer to make things fit.

glenn: In TTML2 I assumed the author would not do anything special to choose full or half
... width in tate cho yoko context, so I view that as orthogonal to the fontVariant question.
... I would ask more if super and sub are useful, because there's no Unicode solution to that?

nigel: I have an issue open about the tnum Opentype options. Would they go in fontVariant?

glenn: They could do. fontVariant doesn't include all the general font mechanisms. However
... there are arguments that it is too font specific. The CSS spec allows specification of the
... particular truetype table parameters.
... If you want to support tnum, and any of those other features, then it would drive you
... to the generic solution. If you are convinced there's only a small set of specific variants,
... then the keyword approach is more useful.
... I prefer the general mechanism rather than keywords. Then we could simplify this.

pal: Going back to IMSC 1.1, do we need fontVariant?

cyril: Netflix is not using it.

RESOLUTION: We do not need fontVariant for half vs full width or superscript/subscript

Break for lunch

back after lunch

Nigel: Those present immediately after lunch: Andreas, Pierre, Nigel, Cyril, Glenn
... and Chris
... For the first part of this afternoon we'll iterate through those style attributes in IMSC1
... that are not in TTML1 and work out the disposition in TTML2, then based on that
... work out whether to deprecate in IMSC 1.1 (if included in TTML2) or keep (if not).

Should ebutts:linePadding be deprecated? #278

github: https://github.com/w3c/imsc/issues/278

nigel: Technical issue here - if we have linePadding and padding on span then how do we
... resolve the situation when both are specified and differ from each other?

atai: Two options: 1) don't allow padding on span or 2) if you use linePadding then you
... shall not use padding in that area where linePadding applies, i.e. no padding on span.

nigel: Or you could have additive rules, or precedence rules etc.

glenn: This is about semantic not syntax (referring to the issue text)
... Right now TTML2 has no linePadding, just padding on blocks and inlines, and there are
... well defined rules for applying those in CSS and XSL. There are no implementation issues
... there as far as I know.

nigel: I don't think we've demonstrated that we can map linePadding semantic to TTML2 syntax.
... Specifically I'm not sure we have lineAreaBreak right yet.
... For example when there are nested spans with different background colours.
... Given that linePadding is syntactically simple and no more semantically complex than
... lineAreaBreak + padding on span, and we may not need padding on span, should we
... resolve this by bringing linePadding in instead of padding on span and lineAreaBreak.

atai: linePadding is used widely so there's no need to replace it.

cyril: Can we clarify the support for this in CSS?

pal: Left and right padding on span in CSS applies it to the beginning and end of the span
... whereas linePadding applies it at the beginning and the end of the line in the inline progression direction.
... That's each line based on whatever the background colour is at the beginning or end of that line.

glenn: CSS tried to define some break behaviour, clone or slice, but that turned out not to
... be exactly what we wanted - clone ended up cloning each nested background colour,
... repeating the nesting level. Secondly it didn't take the colour of the last character on the
... line, which was kind of the same thing. We defined inlineAreaBreak which gave us the
... ability to do cloning but only use the most nested.

nigel: When I went through all the permutations I didn't find one that worked for all the
... cases.

pal: There's a semantic mismatch between the two models.

nigel: It occurred to me that in CSS it would be useful to have an ::each-line selector as well
... as the existing ::first-line selector.

pal: Lots of other people have run up against this too.

cyril: Let's assume that when we talk to CSS they support ::nth-line, then that would be
... something we might target for use in e.g. TTML3. Now what are our choices. An option
... that was kind of agreed was to have ebutts:linePadding in IMSC 1.1 and deprecate it for
... the equivalent feature in TTML2 if there were one.
... Another option is to adopt ebutts:linePadding in TTML2 either with or instead of the existing padding.
... The options are to leave it in IMSC 1.1 or put it in TTML2 in replacement or not of the
... other padding feature. Are those the options?

group: [yes]

glenn: Some details on that. I'm assuming if we put it in TTML2 we would use a TTML2 namespace.
... Certainly tts:linePadding is no more complex than adding inlineAreaBreak, if you're going
... to add one anyway. And if we do that then should we add padding on content elements
... at all in TTML2, which we decided to do long ago.

atai: I opened the issue 5 years or so ago before we found the solution of linePadding.
... In EBU-TT we allowed padding on span, and then found that it was not actually a good
... solution. So EBU-TT-D deprecated padding on content elements and defined linePadding.
... Therefore from this motivation there is no longer a requirement for padding on content
... elements.

glenn: I understand Pierre's argument about complexity. My feeling is that its possible to
... include tts:linePadding and I have no serious objection to that. I agreed to fillLineGap on
... the same principle. Then the next question is do we keep content level padding in TTML2,
... and if we do then we have to define the priority for both being present. I would assume
... that the linePadding model should at least facilitate doing it in the future even if we don't
... do it now, otherwise we will need to do it in the future. My preference is to keep linePadding
... and padding.

nigel: My proposal if we wanted both is that the padding would be additive.

glenn: Yes, that matches existing behaviour for padding on block areas and inline areas.

atai: We need to discuss the namespace. Which namespace should linePadding have in TTML2?
... Secondly, my impression is that every unused feature, with no clear use case, adds more
... complication for implementers so it is better to take it out than to include it, but I will
... not argue on this.

RESOLUTION: Adopt linePadding in TTML2, remove inlineAreaBreak, keep padding on content

atai: I think the element in TTML2 should be as defined in EBU-TT and IMSC1, with the
... ebutts namespace. If we change that then all the current implementations will not work,
... and implementations have to be changed to support the new version, and the reason is
... trivial.

flick: +1 it is trivial.

pal: When we imported it into IMSC1 we kept the ebutts namespace. The advantage of keeping
... the namespace is that EBU-TT can reference TTML2 and we can have one spec for this
... worldwide.

glenn: There's no precedent for this in TTML, and EBU owns that namespace. If EBU
... decided to give it new semantics tomorrow then they would be applicable here. THis
... makes our spec non-fixed by bringing in external vocabulary. I'm fine with having
... IMSC import from non-W3C namespaces, it's been a consistent principle in TTML to have
... everything self-contained. Although we include xml: and xlink at least they are W3C
... defined core technologies. So I'm opposed to bringing in other namespaces - it will
... complicate the spec and implementations. It is dangerous for authors because it gives
... them the false sense of security that they can keep it the same and it will keep working.

cyril: Clarify please?

glenn: Authors may think there are no changes semantically, but there may be knock-on
... effects because it is happening in a different context.
... One more comment - there is a lot of code for implementations and a lot of places in
... the spec that are keyed to using a TTML namespace and keeping all the style attributes
... in the TTML style namespace. It would require a lot of processing to introduce a new
... namespace.

atai: First we should not worry too much about the pure philosophy of namespaces because
... we are continually defining new ones anyway - EBU-TT, IMSC etc. For example if we in
... EBU-TT define a style element allowing style attributes not allowed in TTML then we change
... the content model and therefore change the element. Formally it's a completely new element.

nigel: You mean like allowing padding on span?

atai: That's one example, or if we disallow an attribute on a TTML element, then we have
... defined a new element.
... There is no longer only one definition of each element.

cyril: I disagree with this.

glenn: I disagree too - we anticipated subset implementations in TTML1.
... It is true though that W3C owns the namespace and would likely not have allowed
... EBU to add things into the TTML namespace.
... Bringing in vocabulary from profiles breaks the Directed Acyclic Graph of specifications
... and creates huge problems and is unnecessary.

cyril: Two points:
... It could be problematic if the ebutts: namespace were in the TTML spec - if EBU defines
... a new feature in that namespace then people would have to know which spec to look
... in for the definition. The second point is about implementation - what are we talking about?
... Mostly adding Japanese - European TVs likely would not have to change. The only
... ones are current IMSC 1.0.1 implementations in Japan, which have to be augmented
... anyway. I'm not saying the change is free, but that it is small, it is only a matter of namespace.
... You just have to do an alias in your implementation. The pros are the spec simplicity and
... visibility (only one place to look) and in the future setting a precedent for everything being
... in the TTML spec, not having everything together.

pal: Two things:
... EBU would have to be involved to move linePadding, fillLineGap etc so they can remove
... them from their spec and ultimately create a pure subset of TTML2.
... If EBU says no then that solves that problem, we can't do it. Importing it would remove
... the risk of cyclic references and the idea of EBU removing it from their namespace.
... The second thing is that alerting people to changes in semantics is exactly what we
... don't want to do, introduce differences in semantics!
... On the issue that it is a minor change, it is a change. Every new feature is a new set of
... tests, bugs potentially etc and I don't see anyone paying for it. Who is going to be motivated to do that?
... Who is going to train all the EBU-TT-D authors?
... Assuming EBU wants to play along I don't see a compelling reason here.

glenn: Were you assuming that if we work with EBU and bring this in that we would bring
... it into a tts namespace or that we would somehow own something in their vocabulary?

pal: That we would own the element in the existing vocabulary.

glenn: But EBU owns that namespace, period.

pal: They can choose to relinquish or delegate it to W3C, this happens often.

atai: For the namespace domain thing there is no such rule for linking a name to an authority.
... It is a common assumption but the namespace could have any string that you want. It is
... not really something we need to worry about too much.
... Cyril, the impact of changing the namespace on manufacturers could be that current
... documents may not work on new implementations if they don't implement both.

nigel: Simple pattern for dealing with that in IMSC 1.1 to deprecate ebutts:linePadding and
... set precedence rule if both are present.

atai: Second point is that we are assuming some future change in CSS so that's an argument
... for using the current terminology and later doing something more CSS/HTML conformant.

glenn: Propose a compromise I could live with:
... Pre-deprecate, i.e. define linePadding in tts namespace and for compatibility allow it to
... be used as an alias for compatibility and refer to ebutts:linePadding as an alias for the
... new tts:linePadding, and deprecate ebutts:linePadding.

atai: What is the difference, you also take the authority of the TTWG and redefine the meaning
... of ebutts:linePadding. You're saying if you encounter ebutts:linePadding then map it to
... tts:linePadding. I see no difference.
... This would depend on EBU being willing for this to happen.
... It would be cleaner to move it in completely.

glenn: It would break the rule of everything being defined in TTML namespace.

pal: There's no shame in recognising that EBU did a good thing and making it available more widely.

glenn: We've been following some principles for a long time that this would break.

pal: That principle seems really restrictive.

glenn: I would probably have this argument even if it came from a W3C spec, probably.

pal: The point is that by changing it you make it rougher round the edges for everyone.

nigel: Doesn't this proposal work for all the constituents, implementers, users, specifiers?

pal: Not for implementers, they have to introduce aliasing in their implementations.

glenn: It doesn't take extra work to add aliases.

pal: It does make a difference for implementers though.

atai: Another compromise I've mentioned before is to leave out the linePadding feature
... altogether and keep it in IMSC.

nigel: Then IMSC 1.1 is not a pure subset of TTML2.

atai: Correct.

glenn: The compromise I suggested would both allow the subset and be implementable.
... I could leave with the compromise of leaving it out of TTML2 also. The amount of work
... is trivial to introduce the alias.
... One plus about my approach is it gives a path for EBU to get the extensions they've
... made migrated into a W3C blessed specification that they might feel useful and may
... provide an opportunity for more cooperation.
... I feel it is a detraction to omit it from TTML2 because it removes a useful feature for use
... globally.

nigel: Observe that there was actually formal consensus for omitting ebutts:linePadding from TTML2
... and keeping it in IMSC 1.1

cyril: I need to check Netflix position on this.

glenn: I've heard David Ronca say IMSC vNext should be a subset of TTML2 and prefers
... it all to be in the TTML namespace.

nigel: The position we have reached is to remove inlineAreaBreak from TTML2 and not add
... linePadding in.

pal: I would go back to the IMSC vNext requirements and specifically exclude those features
... that are not in TTML2 today.
... To make it obvious. If we had decided to import them into TTML2 we could have kept
... them the same, but at this point today these are the exceptions we have.

Should ebutts:multiRowAlign be deprecated? #277

github: https://github.com/w3c/imsc/issues/277

nigel: The idea here is that the TTML2 semantics of setting textAlign on nested elements
... does the same thing as multiRowAlign and therefore we no longer need multiRowAlign.
... But the mapping to CSS doesn't work.

glenn: Elika suggested using display:inline-block

cyril: CSS would like to understand the use cases and constraints rather than receiving a solution.

pal: That would be the multiRowAlign case.

glenn: I think there is no meaning of alignment in span in CSS because there's no extra
... space, unless you set width explicitly.

pal: display:inline-block only works in CSS if you have explicit line breaks.
... A question for CSS is if that is a bug in browsers or by design.
... If they say it is by design then we can ask how to proceed.

glenn: I looked at this before and concluded that the spec doesn't support the browser
... implementations.

cyril: Can we do it in two steps? Do we agree the semantics of multiRowAlign need to be in
... TTML2?

pal: This is in use

glenn: It is defined in TTML2 and implemented in at least one implementation.

cyril: Is this a case where it is defined in TTML2 with a different syntax.

glenn: It requires more content work to do this in TTML2 because you have to create
... nested spans and setting inline-block. There's a transcoding issue but no namespace issue.

cyril: So there is a way to do it. Does this fall into the category we agreed before in the
... deprecation model?

pal: I think it falls into the same category as linePadding that we just did.
... It would be a stronger argument if there were a direct mapping to CSS.
... The approach in TTML2 has a different syntax from what is in wide use in IMSC1.

glenn: And there's a question about mapping into CSS anyway.

nigel: And the TTML2 syntax is more verbose.

glenn: A useful side effect of inline block is to create horizontal and vertical struts, by
... setting ipd and bpd on inline blocks.

nigel: Can you set ipd and bpd to use all the available space?

glenn: Yes you can use allocation to use as much space as possible.

atai: I agree for authors this is more complex. Is it more complex for implementations too?
... For presentation processors it is more complex.

pal: For sure.

atai: I possibly would vote the same way as for linePadding but for a different reason, to
... exclude from TTML2 and just include in IMSC 1.1. I am not sure how often this feature
... is used in practice. multiRowAlign is widely used in legacy contexts but only works because
... of the constraints of those legacy contexts.

pal: I would agree to keep this in IMSC 1.1 and ask CSS how to do this.

glenn: It took 70 lines of code to implement multiRowAlign in TTX, which translates
... it into textAlign in TTML2 with inline block. That's fully tested.

nigel: So you would not deprecate multiRowAlign even though it can be done in TTML2?

atai: correct

pal: It is extra work, and if we think it may not be used, then we should not use it.
... I would not allow inline-block in IMSC 1.1

nigel: Is inline block needed anywhere else?

glenn: There are edge cases that need inline blocks using struts.

nigel: What are those cases? Do we expect them to be used?

glenn: I have to check but I believe I am using it for rubyReserve.

nigel: So you're mapping one TTML2 syntax to another?

glenn: Right

nigel: So there's no authorial requirement to use inline blocks?

glenn: Correct. The requirement came from SMPTE digital cinema to specify a varying
... width, which can only be done with ipd.

pal: Digital Cinema isn't driving the requirement for IMSC

RESOLUTION: Do not deprecate ebutts:multiRowAlign, prohibit inline block, leave TTML2 as is.


Add parameters to define the temporal extent #483

github: https://github.com/w3c/ttml2/issues/483

glenn: If I parse a document and find it only has a caption from 1000 to 1001s then I can
... conclude that anything blank from 0s to 1000s is blank or undefined from the perspective
... of that document.

nigel: You can't distinguish between a defined empty presentation behaviour and no
... defined presentation, since there's no way to define an empty presentation for a specific period.
... This is useful for segmentation or live delivery for example.

glenn: It could impact the display of backgrounds when showBackground="always"

group: [discusses use cases]

glenn: I have enough answers to be able to review this now.
... I had a use case for resolving indefinite duration - clipEnd could be used for that.
... That was my intent for defining mediaDuration. I could see that this could be independent
... of having a related media object.

nigel: yes

glenn: That's why I asked you to consider media duration, at least for the end point.

Add ttm:mediaTimestamp (or equivalent) attribute #125

github: https://github.com/w3c/ttml2/issues/125

nigel: We had two objections to the presence of ttp:mediaOffset but it remains in the
... specification. We need to resolve this before moving to CR.

glenn: It wasn't a recent unilateral decision. I'm not sure when.

archaeologist: tracker issue 335 and 361, raised by Courtney Kennedy and Glenn Adams respectively

pal: My objection still stands.
... This arose from a mistake. People try to reproduce a timecode based workflow.
... That timecode may be 01:00:00 for the beginning, or 10:00:00, not realising that you
... don't have to do that in TTML and that it's wrong. What goes in TTML is a time offset.
... It is not 1 hour from the start of the video.
... So the idea of negative time offsets, to offset all the TTML files by -1 hour rather than
... rewriting the timestamps arises.

glenn: You're right that being able to specify mediaOffset was intended to normalise
... documents that use that convention, for example documents that begin at 10 hours
... and you think that's the media time, then putting that offset in would reset it to zero.

pal: My point is that's bad and we shouldn't encourage it.

nigel: Mine is that it is actively dangerous.

pal: Right, they should use media timebase.

nigel: I also object because it has no practical effect - in the case of smpte discontinuous
... then it does not even apply.

glenn: Even if we don't define this I want to do a better job of defining the relationship
... between the root temporal extent and the media time.

atai: It could be metadata to say when the beginning timecode of the related programme is.

nigel: The document interchange context like an MP4 wrapper already defines this.

flick: Take 2 documents to wrap in an MP4 document. It should not matter if each is zero based.

cyril: No the time begins at the beginning of the first sample.

pal: In Part 30 for TTML the media timeline begins at the beginning of the track.
... In IMF it is the other way around.
... Each thing is independent and starts at zero in that case.

atai: So the zero sync point is different in the related media.

glenn: So you partly want to encourage authoring content that is zero based and can
... potentially be shifted around dependent on some external relationship.

pal: When you author, you get some video content and you position your events relative to
... zero being the first frame of the related video content.

glenn: In SMPTE continuous then 00:00:00:00 is the first frame, right.
... For documents beginnins at 10:00:00 now you could support that externally in the processing
... context if it has different information.

pal: Yes, for files I've seen they were wrong not only because they begin at 10:00:00:00 but
... also they have the wrong frame rate.

glenn: I think we need to support taking advantage of external media and if they want
... relative times for presentation that is not 10:00:00:00 that is not handled externally.
... We don't dictate authorial behaviour in profiles.

atai: It is not just a question of behaviour but also of workflows.
... Pierre, this relation between time based media and the related media time base. Do you
... think that the relationship between the time in the document and the time in the media
... is completely defined by the interchange context or there's no rule?

pal: Absolutely, I've seen lots of different examples.

nigel: One of my other objections is that DASH already has PresentationTimeOffset, and
... I think this mediaOffset value will be extracted and copied into that field and then
... wrongly applied twice, which is really dangerous.

cyril: +1

glenn: So in an interchange context that does not specify this do we need to define this?

cyril: No

nigel: No

glenn: This came from TTML1 N.2: " If this assumption doesn't hold, then an additional offset that accounts for the difference may be introduced when computing media time M."
... When we wrote this into TTML1 we didn't go into this in a great deal of detail at the time.
... It implies the existence of some offset and I viewed that as a potential ambiguity in the spec
... that needs to be resolved in TTML2, which is why I defined it. If we don't define it then
... we need to figure out what to do with that text in TTML1 and put something in TTML2
... that talks about the document processing context as needing to resolve this issue.

atai: Can we resolve to remove ttp:mediaOffset as it stands and as a separate issue add some guiding text?

glenn: Okay I can do that, as long as we try to resolve the ambiguity. It will probably
... need a change in TTML1 Third Edition too.

RESOLUTION: Remove ttp:mediaOffset as it stands and open a new issue to explain how to resolve media time

flick: Do mediaOffset and mediaDuration travel as a pair?

glenn: That was my intention

flick: Then we should remove that too.

glenn: I suppose clipEnd could fulfil the same purpose.
... I need to convince myself that the names clipBegin and clipEnd are appropriate.
... So our basic assumption is that time zero is the beginning of the document timeline?

pal: Yes, there is always an ISD that goes from zero to ...

nigel: I think the concept of an empty ISD should exist but I think empty ISDs would get pruned by the current algorithms.

RESOLUTION: Remove ttp:mediaDuration

glenn: This has to be tied together with clipBegin and clipEnd because we need a way to determine the end of the document.
... If you have a test process whose goal is to produce a set of ISDs then unless you have a fixed
... duration that you can resolve that to you might end up with different results in the case
... of showBackground="always" because there would be some ISD from the last time to
... infinity that needs to be covered.

Back to IMSC 1.1 issues...

Should ittm:altText be deprecated? #274

github: https://github.com/w3c/imsc/issues/274

nigel: First question: is altText application worth having a named entity rather than using a generic one?

glenn: No, we made a decision on that before, we have the generic ttm:item so we don't have to do that.

atai: Originally the idea of ttm:item was to pull in other metadata defined by EBU and SMPTE
... and in EBU we debated it a lot and in the end decided that the vocabulary is already defined
... and there was no reason to bring it to a more generic syntax so it would be better to
... remove it from TTML2 and use what is already there. I think this could be a similar
... situation where there is something already defined and there would be the option to take
... ittm:altText as is, or even put it in ttm:altText. I had a look and I think it would be much
... easier to define the element with a local name like altText rather than put the semantics
... into an attribute which makes it much harder to process. It is cleaner to define the
... element with a namespace and a name and that's what it means.

glenn: We defined an external registry and put it in the wiki so that all those SMPTE and
... EBU metadata could be defined by users and registered. We created a naming mechanism
... so they could be made unique and avoid naming collisions using URIs. We definitely
... did not decide to eliminate the element.

atai: We took out some of the named items from TTML2.

glenn: We had a whole list that were removed and went to the trouble of defining a registry
... for that. Every time you add a new element it has an overhead in additional ways for example
... in specification, testing, implementation, authoring knowledge. The HTML meta element
... has been serving for many years as a generic tool for expressing metadata and this
... basically follows that.

nigel: We need to move from the general to the specific here and consider this specific use case.

atai: My argument is to move it to TTML2 as ittm:altText or if not then ttm:altText.

glenn: There is no technical reason, so the only reason could be preference.

pal: People are used to altText and now they have to go looking somewhere else.

nigel: It is easier to hang normative language off a defined entity and also to validate
... documents based on it.

glenn: I agree that it's cumbersome to create generic elements just for this purpose. I could
... live with adding a ttm:alt attribute which would be available on almost any element
... including tt:image.

pal: would it be applicable to other things?

glenn: Yes, the spec doesn't mandate use of any metadata.

pal: Could you store a metadata element under the image element?

glenn: Yes you could have a metadata element as a child of image

pal: What if someone puts both ittm:altText as a child element of image and alt attribtue
... on image.

glenn: Since TTML doesn't know anything about ittm:altText then it could be pruned.

pal: IMSC 1 would only deprecate ittm:altText. If both appears which one should...

glenn: TTML2 would only know about ttm:alt and besides it doesn't define any behaviour
... associated with metadata. It is only for authorial purposes. An application could make
... use of it for accessibility purposes like in browsers but that would be outside the scope
... of TTML to define what that is.

pal: Would there be a new feature designator for it?

atai: There are not feature designators for metadata attributes now. So you do not need
... one. Why would you? Just use the feature #metadata.

glenn: Actually there is a feature designator #metadata that covers all the metadata vocabulary

pal: That's already allowed in IMSC

glenn: We should add a v2 designator including ttm:alt
... Can this cover backgroundImage? It can because backgroundImage takes a reference
... to an image resource, as a fragment identifier referring to an image element, which
... itself could have a ttm:alt on it and therefore the background image could be associated
... indirectly.

pal: You might put the alt on the element with the backgroundImage itself, presumably.

RESOLUTION: Add ttm:alt attribute to TTML2 and permit it in IMSC 1.1 and deprecate ittm:altText in IMSC 1.1

pal: Wording for ttm:alt should match ittm:altText now because we spent a lot of time on
... that so let's not blow it by changing that. Copy as is please.

Should itts:forcedDisplay be deprecated? #279

github: https://github.com/w3c/imsc/issues/279

nigel: Works through the example in w3c/ttml2#482.
... Pierre, you think that's too cumbersome.

pal: Maybe in the future we will find a use for condition in IMSC but we have not got
... enough interest to include it. Instead, put itts:forcedDisplay into TTML2 or just leave it
... in IMSC 1.1 and not deprecate it, and make it an exception to that subset requirement
... [imsc1.1 being a subset of ttml2]

glenn: It can be implemented by translating to the condition mechanism for presentation.
... That's what TTPE does.
... If this was the only argument for condition I would agree to make a specific
... attribute for it in TTML2.

pal: Notice that forcedDisplay is not purely a presentation, it also carries some semantic
... meaning, something that you can't easily backtrack from condition expressions. When you
... talk about forced subtitles it means something in industry.

flick: And they want to preserve the forcedness without using more complex vocabulary.

pal: Yes these are subtitles that are designed to be shown to all viewers regardless of
... whether they have opted to display e.g. hard of hearing subtitles.
... So there's an argument for having an explicit forcedDisplay attribute in TTML2 because
... of that meaning.

glenn: We did add a named metadata item called usesForced to signal that the document
... uses forced.

atai: Forced is established, has been implemented, and it is easy to discover if it has been
... applied, so the current solution in IMSC satisfies that requirement. For me it is as before
... in previous conversations, it is best to leave it in IMSC and not redefine it in TTML2 but
... continue with the established practice.

glenn: You should add this to your list of non-subset items.

nigel: We seem to have consensus to keep itts:forced and not add anything to TTML2
... We could add an informative note to say that it can be implemented by a TTML2 processor
... that supports condition using an example like the one in w3c/ttml2#482.

pal: I wouldn't object to that.

RESOLUTION: Keep itts:forcedDisplay in IMSC 1.1 and do not add anything to TTML2

Should itts:fillLineGap be deprecated? #276

github: https://github.com/w3c/imsc/issues/276

atai: My proposal is to do the same as linePadding, to leave it in IMSC 1.1 and take it out
... of TTML2. The rationale is first that we are waiting for a proper solution in HTML and CSS.
... It won't happen before we publish TTML2 so we should keep the established solution.
... From the previous discussion it is unlikely that we will be able to pull it into TTML2,
... or define it in a new namespace, so we should take it out of TTML2 and keep it in IMSC1.1.

glenn: Does Netflix plan to use fillLineGap?

cyril: We are not using it now but I think we want to use it.

glenn: I have no objection to taking it out but we should get a Netflix view.
... There was a question about if it is semantically the same.

pal: It was different. We spent a long time getting it right in IMSC 1.1 so we should copy
... it directly.

RESOLUTION: Remove fillLineGap from TTML2 and retain itts:fillLineGap in IMSC 1.1.

ttp:displayAspectRatio is prohibited #273

github: https://github.com/w3c/imsc/issues/273

nigel: Why don't we adopt ttp:displayAspectRatio and keep the SHALL note about
... centering the root container region that is in IMSC 1.1

glenn: They're not equivalent, because you can specify pixelAspectRatio in TTML2.

nigel: In the case that pixelAspectRatio is prohibited they resolve to the same thing?

glenn: Maybe.
... This wasn't about spec purity but avoiding ambiguity in TTML2.

pal: Adopting ttp:displayAspectRatio would be self-inflicted pain and will lead to implementation
... pain and documents containing both ittp:aspectRatio and ttp:displayAspectRatio for
... years to come.

nigel: It's an easier case though here to deprecate ittp:aspectRatio and permit ttp:displayAspectRatio
... since they're semantically the same. Just set a precedence order and define ittp:aspectRatio
... using the semantics of TTML2 by reference.

pal: We could keep ittp:aspectRatio and not deprecate it, but state that it is the same as
... ttp:displayAspectRatio in TTML2.

atai: But you would not remove ttp:displayAspectRatio from TTML2

pal: No.
... The use case is for 4:3 centre cuts of 16:9. For progressivelyDecodable I have no usage information.
... Here I do not know how much it is used.
... I have seen IMSC documents with ittp:aspectRatio="4 3" so I think it is used.

nigel: We already agreed a deprecation model for IMSC and TTML2 and this appears to be
... a case where we should apply that decision.

cyril: I think we should deprecate ittp:aspectRatio and add ttp:displayAspectRatio

atai: There's another option to leave ittp:aspectRatio in IMSC 1 and don't change TTML2

pal: There's a one to one mapping between the two.

nigel: So you would keep ittp:aspectRatio and add an informative note that it is the same
... as ttp:displayAspectRatio or provide a mapping?

atai: I would be in favour of that.

glenn: Would you more generally provide the mappings to TTML2?

pal: Yes why not.

cyril: Now we have diverged from IMSC 1.1 being a subset of TTML2 I can't express a view.

pal: There was an absolute objection to bringing IMSC 1.0.1 syntax into TTML2.
... That's why we are revisiting this.

atai: It is a practical compromise that we are looking for.

glenn: Raising a point about deprecation, we had one deprecation in TTML2 for a TTML1
... feature, which was the use attribute on an extension or feature and Mike objected to
... having any deprecations of TTML1.

nigel: I think we persuaded him in the end that we weren't prohibiting it and it was okay.

RESOLUTION: Retain ittp:aspectRatio in IMSC 1.1 and add a note explaining the equivalence to ttp:displayAspectRatio in TTML2

Meeting close

nigel: Thanks everyone, a very productive day! [adjourns meeting]
... I realised I didn't record one of the later resolutions that modified a previous one,
... about linePadding, which we agreed to remove from TTML2.

RESOLUTION: Remove linePadding from TTML2

trackbot, start meeting

<trackbot> Meeting: Timed Text Working Group Teleconference

<trackbot> Date: 10 November 2017


nigel: People who were also here yesterday

minutes from yesterday

nigel: Cyril, Eric, Chris, Andreas, Pierre, Nigel, Thierry

<scribe> scribe: nigel

<scribe> Chair: Nigel

This meeting

cyril: Can we spend 15 minutes preparing for the CSS joint meeting?
... Also putting tests on web platform tests.

nigel: OK, let's do that.

CSS meeting prep

cyril: 3 buckets of things to discuss:
... 1. Japanese language requirements -

<pal> rubyAlign

<pal> rubyOverflow

<pal> rubyOverhang

<pal> textOrientation

<pal> fontShear

<pal> rubyOffset

<pal> rubyOverhangClass

<pal> rubyReserve

cyril: These are things in the white paper.
... 2. Line related styling - fillLineGap, linePadding, multiRowAlign.
... and I'd like a common understanding of how ruby annotation behaves in terms of lines
... and line stacking.

pal: Another one to deal with is spurious spaces before <br> which I think is a bug in Chrome
... but it does not match the CSS spec, which leads to extra padding in the end.
... It is a known bug but we should remind them of the impact it has on subtitles.

cyril: 3. All the other properties for which mapping is not correct.

pal: Top of that list for me is textOutline. At some point there was a proposal to deprecate
... textOutline because it was not supported by browsers (it is supported only by Webkit).
... textShadow is not equivalent and not the style of subtitles that everyone is used to for movies for example.

Nigel: It would be good to check they have the information they need. They want to know
... what the desired outcomes are so I want to know if they have that.

flick: We need to establish a process for completing this in association with the CSS WG

atai: We have a limited time with them

nigel: 1 hour I think

atai: It would be good to discuss if we could join a CSS WG meeting even if we are not a part of it.

ericc: If you want to make sure it gets done someone needs to pay attention to it.

pal: I am a member of CSS WG and I can contribute.
... We should ask how we can make sure these issues turn up on the agenda.

cyril: We should make sure they are aware that in principle we would like to use these in TTML.next

pal: It is more general - the functionality should be in CSS, it might be used elsewhere, WebVTT or other places.

ericc: Captions are an important part of the web platform, so if these are important for
... the display of captions that is the use case and we don't need to go further than that.

nigel: Conclusion is we need to explain this is important and that we want to work together
... with them to get it done.

Web platform tests

cyril: The first step is to put the tests we have on the repo without changing them.

atai: You can do that without integrating them?

cyril: Yes

atai: And the goal is to test them against polyfills?

cyril: The best way to do it would be to use imscJS as a polyfill but polyfills are not
... integrated very well in web platform tests
... Pierre tells me that it's easy to get the HTML fragments so we can use the rendering of
... those as the reftest, which takes out the differences between rendering engines.

pal: Things like font smoothing can modify all the pixels so this approach works better
... than comparing with the PNGs in the reftests.

frick: Presupposing that a browser will have implemented TTML may be a difficult.

pal: That's the direction that things seem to be going at a meta level, not to put things
... in the browser core if they can be done by a polyfill.
... Where the rubber meets the road as we discussed briefly is user customisation.
... Unless there's a specific reason for implementing natively, like for example power consumption,
... then using a polyfill will be preferred.
... It's been a pragmatic process - don't implement in core browser unless ... (I could be wrong)
... All other things being equal it would be nice to have it in the browser.

atai: In a sense imscJS is not a polyfill to fill a gap in some browsers but more a bridge.

pal: A question: I think it is better if implemented in the browser but I don't think it's necessary. I'm testing that statement.

frick: Better from some perspectives but worse from others.

pal: Yes, harder to make changes, more support needed.

ericc: Implementing it could take resources. The Wednesday session is really important to
... follow up on because there's a disconnect right now about honouring the user's captioning
... preferences which is not possible with a polyfill.
... I think the answer is to define and add an API to HTML so a library can add generic
... cues to a track with enough information for the browser to be able to render it in the way
... that it was authored. Not to add another specific interface for a particular format but a
... generic interface.

pal: How can that not be the full set of IMSC 1.1 features?

ericc: Just exploring this out loud - if it is possible to render to HTML and CSS in a library
... then it should be possible to give the browser enough information to do the same thing.
... Maybe the interface makes a document fragment and gives it to the browser.

pal: With specific styles.

atai: It's really interesting to think about the details.

frick: To connect Pierre's touch points with what Eric was saying, I'm interpreting it as that
... these cues provide the background for the timing but the expression of details of how
... it renders is a combination of the HTML and sufficient CSS to allow it to be styled.

ericc: And with enough information to allow the browser to identify the parts that the
... user preferences want to override in terms of styles.

pal: Imagine the reverse approach - that the cue contains a DOM fragment and the browser
... sets some specially named styles based on user preferences, and those CSS styles are
... applied to the DOM fragment at the time of rendering.

ericc: That's what I am saying, BUT it has to become unavailable to the generating code
... after styling [to prevent fingerprinting based on style preferences].

pal: So the browser doesn't have to parse the DOM fragment, just set the styles.

ericc: That's exactly what I'm saying. I don't think there's anything in HTML that corresponds
... to this, so there may be unexpected issues with it.

nigel: As well as user preferences there are player styling things like moving captions out
... of the way of controls.

ericc: We may not be able to do everything here.

atai: We have to be able to provide enough knobs to control the presentation.

nigel: The thing providing the DOM fragments can make adjustments to those DOM fragments
... that they provide.

ericc: I don't think all CSS will necessarily be supported.

frick: 3 parts of the continuum: full browser support, intermediate support, polyfill only
... Moving along this continuum will take time, maybe starting with the polyfill and then
... eventually moving up to full browser support.

pal: All three are viable.

frick: The polyfill can prove this across all browsers.

cyril: Back to the testing discussion...

atai: The idea of bringing our imsc tests to the web platform test suite is a really good one
... to show that we have a positive approach together with our request to be more strongly
... integrated with the web platform.

nigel: I think we're all agreed - I don't think there's an easy way to bring imsc-tests repo
... contents in by reference to the web-platform-tests repo

atai: I think Philip Jagenstadt mentioned something about this.

frick: That could be a follow on conversation.

Should ittp:activeArea be deprecated? #275

github: https://github.com/w3c/imsc/issues/275

<tmichel> Tool planning specification milestones.

<tmichel> https://w3c.github.io/spec-releases/milestones/

nigel: There's already an issue on TTML2 (not sure which one) to modify the syntax
... to take position extent rather than origin extent

atai: Similarly to yesterday we have options:
... 1. Deprecate ittp:aspectArea in 1.1 and use ttp:activeArea from TTML2
... 2. Not deprecate ittp:activeArea, leaving as in 1.0.1 and take out ttp:activeArea from TTML2
... 3. Keep both and specify the mapping in IMSC 1.1 to ttp:activeArea

pal: Deprecating something that has just been added to IMSC would not make sense.

atai: I would support that, for example it has recently been adopted by DVB for implementing
... by hardware manufacturers for TVs - if they see that it is already deprecated that's not
... a good sign.

frick: It doesn't encourage trust.

glenn: What did ATSC do?

pal: I don't know.
... I looked, there's no mention of it.

nigel: This could be a good example where we informatively add the mapping to TTML2

glenn: Yes

pal: I would not have any problem with that.

atai: In this case the mapping is 1:1 though

pal: It is bizarre
... Same argument as yesterday - pragmatic approach would be to import ittp:activeArea
... into TTML2 as is, so it can be referenced by everybody.
... Having these two present is going to be confusing to implementers and is not doing a
... service to the industry.

nigel: Check that the objection to bringing in ittp:activeArea to TTML2 still stands?

glenn: Correct.

cyril: I need to confirm.

atai: Is there any objection to removing ttp:activeArea from TTML2?

glenn: Yes I want to keep it in.

atai: I made the wide review comment on the TTML2 issue that it should be the same as in
... IMSC 1.0.1 including namespace.

glenn: Agree to change TTML2 syntax so that the IMSC 1.0.1 syntax is conformant with it.

nigel: The consistent way to do this in TTML2 is to change origin to <position>.

pal: Why impose a change on implementors compared to what is there now?

nigel: Bigger context - the TTML2 spec is more general and broader. If an implementer has
... generic position processing code for CSS positions, then it's arguably perverse to limit it.
... Propose: keep ittp:activeArea in IMSC 1.1, modify TTML2 ttp:activeArea to take position instead of origin, informatively note value mapping from ittp:activeArea to ttp:activeArea

atai: I'd add if we do the informative mapping, then note that the TTML2 feature is more
... expressive and therefore slightly different, to limit confusion.

RESOLUTION: keep ittp:activeArea in IMSC 1.1, modify TTML2 ttp:activeArea to take position instead of origin, informatively note value mapping from ittp:activeArea to ttp:activeArea

Deprecation of smpte:backgroundImage in favor of tt:image #259

github: https://github.com/w3c/imsc/issues/259

pal: My proposal is deprecate smpte:backgroundImage in favour of TTML2 image
... In TTML2 image there has to be a mapping specified to smpte:backgroundImage or an
... equivalence.

nigel: It can be in IMSC 1.1 can't it?

pal: Safe harbor is on SMPTE-TT so if we use image there has to be an equivalence statement.

nigel: I need to check my notes on the call I had with SMPTE. The conclusion was certainly
... that we will add a note about the mapping of smpte:backgroundImage but I need to
... check if we need it in TTML2 or IMSC 1.1 or both.

glenn: We already agreed in w3c/ttml2#460 to add this note to TTML2

RESOLUTION: Deprecate smpte:backgroundImage in IMSC 1.1 in favour of TTML2 image

Should ittp:progressivelyDecodable be deprecated? #272

github: https://github.com/w3c/imsc/issues/272

pal: This was introduced in Ultraviolet - I've reached out to them and they've told me it is
... not useful or used and has impractical constraints such as timing being prohibited on
... children of p elements, so it is not used and cannot be used and we should deprecate it.

RESOLUTION: Deprecate ittp:progressivelyDecodable

pal: When we do that, I'm half tempted to omit the definition in IMSC 1.1 and just reference
... the definition in IMSC 1.0.1

cyril: That's an editorial thing.

pal: Yes it's a style thing, it's what I'm thinking.

cyril: Makes sense.

atai: Makes sense.

RESOLUTION: Reference details of deprecated ittp:progressivelyDecodable from source in IMSC 1.0.1

IMSC 1.1 issue wrap-up

Nigel: That's all the issues?

pal: yes

nigel: Does that mean that the blocked labels can be removed?

pal: yes I'll do that

CSS WG and TTWG joint meeting

nigel: Some quick introductions:
... Nigel Megitt, chair TTWG

pal: Pierre Lemieux, Movielabs

<cyril> Cyril Concolato, Netflix

<tmichel> Thierry Michel, W3C

<florian> Florian Rivoal, CSS-WG, Vivliostyle

<wdh> wdh: Bill Hofmann, Dolby Labs, observer

astearns: Alan Stearns, co-Chair CSS WG

<ericc> Eric Carlson, Apple

<Guest41> Chris Flick, Apple

<Guest41> nick /flick

fantasai: Elika Etemad, invited expert, editor of half the CSS WG's specs

rossen: Co-chair of CSS WG, Microsoft

hober: Theresa O'Connor, Apple

nigel: High level picture is: how do we work together to get the styling features needed
... for captions and subtitles into CSS where there are gaps?

florian: Not sure of the history here but it seems dangerous to map from TTML to CSS
... because if there are differences in semantics then it will be hard to identify.
... If the differences are subtle then it was not worth doing. If they are big then it is bad
... because there isn't a mapping.
... We need to work with you to look at the use cases we have and work out what is missing
... and add to CSS. From there we want to see is how you simply invoke CSS rather than
... define something close and map it. As long as TTML keeps defining something similar
... but not the same then we will have ongoing difficulties. Maybe in TTML3 just describe
... the minimal CSS properties and define the layout. I don't know how you get there but
... for the CSS side we need to work from use cases and look at where it's not adequate
... and go from there.

pal: Emphasise that this is not about TTML, in terms of requirements, it is about subtitles
... and captions, and it can be used for example in WebVTT. The delta is for how we
... present subtitles and captions on the web.

glenn: Agree with Pierre to focus on the bigger picture.
... In 2003 we adopted a policy of using camel casing so any CSS names we've taken have
... already changed so we can't back out of that.

fantasai: I don't think we care about that.

glenn: To the extent that we've pulled in CSS we've tried to do it without changing semantics
... but there are some edge cases where we've clarified and had to go beyond CSS. We want
... to minimise any differences. What florian said is true in the ideal world but we have
... practical constraints too such as timing.

pal: This is not the topic today! The main question is about gap filling.

nigel: I think there's recognition in TTWG that there may be input we can provide.

florian: Concern about augmenting CSS - at some point it's possible that CSS will add
... something and it won't work for TTML because it went a different way.

atai: Can we move to concrete cases?

nigel: Cyril identified 3 buckets.

cyril: The first bucket is related to Japanese subtitling, mostly described in the white paper
... I sent to the list.
... Second is line related properties, adding padding, extending background, aligning lines,
... defining lines better in relation to rubys maybe.
... Third is those where a mapping isn't clear, maybe most importantly textOutline.

nigel: In that bucket is a recognised issue about white space handling at the ends of lines.

Japanese features

<fantasai> https://lists.w3.org/Archives/Public/www-style/2017Nov/att-0006/Japanese_Subtitles_on_the_Netflix_Service.pdf

cyril: I sent the white paper to CSS.
... lists main features - boutens, rubies, slanted text.
... tate chu yoko
... We explain lambdaCap is not a standard, but we used it as the basis.
... I did not send the CSS properties to the group, please understand the context.
... fontShear - we use skewX() and skewY()

fantasai: You can fall back to oblique or synthesise it if there are not obliques in the font.

cyril: What would be the angle?

fantasai: Undefined

cyril: David Singer also mentioned font variations, I don't know how well they're supported.
... There is a slant axis.

fantasai: That would presumably be usable to solve this case.

florian: Do we slant the right way for vertical text? Oblique doesn't do that, I don't know
... what slant would do.

cyril: For the TTML ruby properties, there are more TTML2 properties than we currently use at Netflix.
... tts:ruby is strictly equivalent to what is defined in CSS.
... tts:rubyAlign is slightly different - it defines two additional keywords that TTWG is still
... discussing.

fantasai: It's worth - the Ruby spec's distribution approach is partly based on justification
... opportunities that can be controlled by the text-justify properties in CSS 3.
... auto means normally justify, or you can say inter-character or spaces only, so you can
... achieve distribution of space you can do that, and control if the spaces are on the outside
... or not through the ruby-align property.

cyril: tts:rubyPosition is very similar to the CSS property.
... At Neflix we think subtitles are better on fewer lines. For two lines, the best choice is
... on top for the upper line and beneath for the lower line.
... auto takes care of not knowing where the line breaks will be.

florian: This auto value doesn't generalise well to more than 2 lines.

cyril: The preferred behaviour is above all the lines but the last one, and below for the
... last line.

florian: That variant is not easy, but if you wanted the other way around, you could use
... the first line selector, but we don't have a last-line selector.

pal: The point is not about hard or easy but the expectation of what people expect to see.

florian: It is easy for two lines

cyril: You don't always control how many lines you get

astearns: In those cases, >2 lines, what does the "outside" value do?

glenn: The first n-1 lines would be above, the last would be below

astearns: That's what you want the auto to do?

cyril: Yes, the idea is to use "outside" instead of "auto", which we have requested as the default
... for TTML2.
... Is "outside" supported?

fantasai: No but we can add it

astearns: Seems reasonable to add

hober: Seems reasonable

astearns: Best way to do this is to open an issue on CSS explaining what you need and the
... use cases, and it would be useful info to say what usage percentage.

cyril: I'll take the action to add that

pal: How does it get added to the agenda?

rossen: We scan the issues before meetings and add an agenda+ label

fantasai: For specs in active editing they will get triaged in

florian: For others you may need to push

hober: The Chair is your escalation path!

fantasai: Ask members to tag the issue with agenda+
... The Ruby spec is temporarily to one side while other things are being worked on, but
... we can make it happen if there are things that are urgent.

cyril: Next one: rubyReserve is not yet ingested but we consider it an important feature.
... It is the ability to reserve space where there are no rubies to make sure that the line
... spacing stays consistent, we don't want the baselines to jump up and down.

fantasai: Specify a big enough lineheight to deal with the ruby

rossen: That's one of the frequent proposals is to set lineHeight >= 1.5em for Japanese so there is
... always enough space. Then you don't need anything else.

<astearns> suggestion in the CSS spec is in this section: https://drafts.csswg.org/css-ruby-1/#line-height

dbaron: The question is if there is a reliable way to do that in a way that is not font dependent.

cyril: It is not clear to me how ruby contributes to line height.

fantasai: Currently the content of the line is centered in the line box in CSS and the ruby
... needs to borrow the bottom part of the line height from the previous line, that will
... layout correctly as currently defined but if you put a background on the line box then
... that will be an issue.

cyril: How do you apply a background to a ruby?

fantasai: Apply it separately to the ruby annotation

glenn: TTML2 has that now.

fantasai: Increase the padding-top by the height of the ruby to increase the background area
... of the inline box.

pal: It's like fillLineGap

cyril: textCombine matches with text-combine-upright
... textEmphasis matches to three separate things in CSS.
... This paper doesn't mention rubyOffset, rubyOverflow

glenn: rubyOverflow deals with ruby being taller or wider than the base characters so you
... have to introduce new space. For example if it is at a line edge boundary and you have
... alignment constraints on the line do you let the overflow go beyond the block boundary
... that contains the line, e.g. to the left, or do you bring in the ruby and then push out the
... base characters by adding space after them. They are discussed in the CSS ruby spec
... but it does not provide any control mechanisms.

fantasai: Earlier drafts of rubies had some controls, but it was too advanced for level 1.
... We just said we would provide more controls for level 2.

glenn: This came up because we were trying to mimic a particular implementation's behaviour
... that is commonly used for Japanese subtitle authoring. We wanted to support the right
... thing and also the possibly wrong default behaviour in that tool. It is too advanced for level 1.

fantasai: I suggest deferring the controls for that until later.

glenn: There is only partial implemetnation in TTML2 so that may be something we
... jettison before CR or mark as at risk.

cyril: In particular overhang, is ...

<fantasai> https://drafts.csswg.org/css-ruby/#ruby-overhang

glenn: That's different, it's about deciding which classes of characters can be overhung.

cyril: The basic overhang feature is not something we have found but we want to investigate
... further so that may be something we push further out.

fantasai: There's a section on this in the CSS ruby spec, which says what you can't do,
... but mostly leaves it to the UA.
... We don't have a really clear idea what we want to do and it is more advanced and less
... critical. I recommend both of us leave it for the next level.

cyril: writingMode - there's a difference in how it is specified, to do with the inline
... progression direction.

fantasai: XSL-FO handled left to right columns in text was pretty broken and I know you
... don't have content that depends on that so if you don't use it then drop it.

pal: In CSS you have to control both writing mode and direction.
... It seems to map to two things.

florian: This is one of the bad things about mapping

atai: TTML is 15 years old - at the time they began CSS wasn't ready, and we have to deal
... with the solution as is.

plinss: Let's not revisit the past.

pal: We want to identify things that should be possible but that are not possible. So far
... I have not found anything like that for writingMode.

fantasai: Do you have a direction property?

glenn: Yes, it's basically the same as in CSS

<fantasai> https://www.w3.org/TR/css-writing-modes-3/#svg-writing-mode

fantasai: The writingMode mapping for SVG is as above. You will get better results if you
... map according to this.

glenn: writingMode as specified was an additional parameter to unicodeBidi. There's always
... the override or embed (no isolate at that time) bidi context
... There was only one option to define the default bidi level, so that's what direction does
... for a paragraph. Those are the only semantics right now.

fantasai: That's fine, it's what it should be.
... The writing-mode from 13 years ago was a shorthand that was harmfully controlling
... both direction and writing mode. I guess nobody is using writing mode for subtitles
... right now so that's not likely to be a problem.
... When we mapped to keywords I did not change the name of the property so that we
... would force implementations to change

cyril: So writing mode only sets block progression direction and direction only sets inline?

fantasai: Yes

<fantasai> s/ writing modes for subtitles on Hebrew or Arabic on Hebrew / Arabic on Hebrew / Arabic/

glenn: right now in TTML writingMode sets an "uber default".

<inserted> Cyril: We can take an action to review that in TTML then

dbaron: It's important that the direction property matches the underlying text, and where
... the logic is that embeds directionality allows implementations can work out the right way
... to display that regardless of block progression direction.

pal: So far I have not run into issues. Suggest moving on.

hober: Try the SVG mapping and let us know if you run into problems.

cyril: That's about it for the first bucket.

Line based styling

<dbaron> slide showing https://codepen.io/palemieux/pen/vyzbqW

pal: ebutts:linePadding [shows slide]

<dbaron> (although what the slide shows looks different from what I see in my browser)

pal: What you'd like is padding on beginning and end of each line, makes it easier to read

<dbaron> showing https://codepen.io/palemieux/pen/MEvVjp

pal: This is in widespread use in subtitling and captioning and is not possible in CSS today.

fantasai: Really demonstrates we can't use the box model - the padding is not just at the breaks.
... Here there is no fragmentation point, it is just the end of the block. That proves it is not
... related to the breaking controls.

pal: When I played with this I noticed there is no control of padding or styling of a line area
... after the break has happened.

nigel: These features are not layout affecting?

pal: No because padding reduces the line width available so can move the breaks.
... fillLIneGap - style dependent, strong feelings both ways, no way in CSS to guarantee
... that the entire line area is filled with background

astearns: It is undesirable to have differences in background height on a line?

pal: exactly
... [shows examples from IMSC 1.0.1 spec]

IMSC 1.0.1 fillLineGap spec with examples

pal: ebutts:multiRowAlign - lay out all the lines, pick the longest line, align that according
... to textAlign, but then align all the other lines differently relative to that longest line.

rossen: Why can't you do this with a block with alignment?

fantasai: When you wrap with a block we don't shrink-wrap to the content. We don't trim
... extra space because that requires another layout pass.

codepen demonstrating this.

pal: [describes styling and the effect]

fantasai: We have the same problem for headings and it doesn't show up so obviously
... right now because we don't have the balancing thing.
... Once you have the ability to balance the headings so the lines are equal, there's no current
... way to get a box that wraps to that balance.

pal: Unless you put an explicit br

fantasai: Exactly. As long as the max content size is larger than the containing block @ @
... We need to specify the need to shrink-wrap around the wrapped text.

cyril: Is this intended behaviour?

fantasai: It is, there may have been implementations that did shrink wrapping but its
... expensive.

glenn: We couldn't find spec language to support the implementations.

astearns: It is not straightforward if you don't know CSS layout backwards and forwards.

fantasai: There is a max-min formula that gives the result, which doesn't do what we need.

glenn: The inline block is expanded to the full containing block?

fantasai: Right. This is a problem we need to solve.

rossen: Is the intention to be able to support two different alignments?

pal: yes

fantasai: To do that you have to be able to calculate the width of the shrink-wrapped container

hober: Please file an issue

pal: Someone filed an issue for this, maybe dbaron
... Different UAs have different behaviours on spaces at the ends of lines, which is really
... annoying.

<fantasai> https://github.com/w3c/csswg-drafts/issues/191 <- shrinkwrap issue

dbaron: The CSS spec defines this but implementations don't do things right.

pal: The CSS spec is clear that spaces at the ends of lines should be surpressed - it is right
... in Firefox but not in Chrome. My read is the spec is clear, which should be confirmed.

fantasai: [looks up spec]

pal: My read is the space should be suppressed.

<fantasai> https://www.w3.org/TR/css-text-3/#white-space-phase-2

<fantasai> Step 3 : “A sequence of collapsible spaces at the end of a line is removed. ”

florian: I think so. In chrome there's a bigger thread on the handling of this and we're
... trying to get it fixed.

fantasai: The spec is indeed clear

codepen showing this issue

pal: The behaviour depends on whether the space is in a span or not
... The last issue is textOutline
... textOutline is used on basically every single movie subtitle.

fantasai: We used to have it in the text decoration spec and we were asked to remove it.
... Now we have a dedicated property text shadow and also a fill stroke module.

hober: This is controlling the stroke.

<fantasai> https://drafts.fxtf.org/fill-stroke/

pal: The stroke model grows the stroke, partially filling inside, you only want to expand on
... the outside.

<dbaron> SVG added https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/paint-order which could help here

rossen: Isn't this the only feature that we pushed to level 4 of text?

fantasai: There was a spread radius idea

rossen: Text spread is exactly the requested feature, right?

fantasai: Depends what you want to do on sharp corners

<fantasai> old text-outline property - https://www.w3.org/TR/2011/WD-css3-text-20110412/#text-outline

<pal> https://codepen.io/palemieux/pen/ZJpwxJ

<fantasai> Rossen mentioned the spread radius argument for text-shadow, which should probably be in the L4 draft

dbaron: Two solutions that could help, paint order or text shadow spread

pal: text-shadow is useful but this is also useful

dbaron: paint order controls which of the fill or stroke paints first

flick: We had some discussion - it depends on the colours being fully opaque

fantasai: stroke-align would do this

pal: That's what we really want

<astearns> file an issue to fill out this section: https://drafts.csswg.org/css-text-decor-4/#intro

pal: For stereoscopic rendering, the use case is only for those displays that are capable
... of stereoscopic presentation so you can decide how important it is. The TTML method
... is very simple, just a disparity value - render and offset the same image by some value.
... Don't do parallax or anything crazy like that, just render, offset.

nigel: That matches broadcast TV standards.

pal: And every other standard out there.
... Is that something worth adding to CSS today? I'm happy to file an issue. It's pretty
... straightforward.
... This is essential for subtitles or captions to be displayed over stereoscopic video.

<fantasai> text-shadow with spread radius will be in text decoration L4 (there's a placeholder in the draft atm, but I should get that filled out in the next month or so)

pal: .. Otherwise it is not watchable.

fantasai: Is disparity inherited?

pal: It's on a region, so effectively like a div

dbaron: This is interesting because there are other pieces of tech around and questions
... about how it interacts with 3D, VR etc.

pal: This is the minimal feature to avoid hurting brains of viewers watching movies.
... It's compatible with CTA, SMPTE standards etc.

dbaron: We just have to make sure it's compatible with other emerging things.
... We need to reach out to the right people.

fantasai: It would need to generate a stacking context.

pal: No you render individually to two planes, the left eye and the right eye

fantasai: For CSS if you set this property on an element it should set a stacking context

dbaron: File an issue and we should all pile on.

Wrap up, next steps

hober: Sounds like we have action items for every issue?

nigel: I think so.

cyril: Would be useful for Pierre to send those slides or push them online

dbaron: Or put them in the minutes and send those.

fantasai: The TTWG had filed some issues on these before and we'd asked about edge cases
... and we hadn't got clear responses but those slides really help explain all the use cases.

nigel: Great!

fantasai: Now we understand much more clearly.

astearns: Those pictures and links to more would be very helpful.

cyril: We have a way forward for the CSS properties, but the rant is still there about syntax etc

florian: When CSS has all the properties then deal with that.

nigel: Yes, not in TTML2 but we're open to it in the future.

rossen: That was a very productive session for both groups.

nigel: I think so, yes. Thanks everyone.

Break for lunch

nigel: return at 1:30 please

TTML1 Third Edition

nigel: We need editorial effort to make progress and Pierre has kindly offered,
... so as Chair I'm asking Pierre to become an Editor of TTML1.

pal: I'll try my best to maintain the tone and there will be pull requests.

glenn: We can make it work.

pal: Any concerns?

glenn: None today

nigel: Thank you for that Pierre.

pal: I think I'm going to try to make a first pass and flag the purely editorial things and make
... one big pull request and for the trickier ones make individual pull requests.

glenn: One pull request for several issues? For the test suite that would be a good case.

pal: There are a number of other informative items too.

glenn: Make your own judgement about grouping them.
... #224 and #225 can obviously go together (no begin times)

pal: There are some we may decide not to address, I don't know.

nigel: For backporting TTML2 fixes there's probably a diff you can do.

pal: That's right.

cyril: This is good, many people helps reduce the load.

Timelines for transitioning our specs

glenn: I have a hard stop for TTML2 which is Rec by July 1. I'm going to make a sprint
... starting mid-December through mid-January, focussing full time on knocking off TTML2 issues.
... I hope to drive it to zero by mid-January.

cyril: That's good to hear.

glenn: If we can go to CR let's say by 1st Feb that would be a goal I could sign up for.
... It will also depend on knocking off dependent TTML1 issues.

pal: That's pretty aggressive!

glenn: I agree, and I don't have a good track record for meeting aggressive timescales.

pal: It's hard to do that without another face to face meeting.

nigel: Any constraints?

cyril: I have hard constraints, after Feb 1 I am not allowed to leave the US
... Before that I am travelling to MPEG in Korea, 22nd-26th in Jan.

pal: I'll be in Rio 28th-31st.
... Then in Geneva from 1st - 3rd
... Conceivably I could do Munich on 5th and 6th.

Cyril: I may be able to delay the travel restriction.

glenn: It'll be hard for me to do Feb.

nigel: Okay it's clear we have support for a f2f in Jan or Feb we just need to agree the dates

flick: It's worth touching base with David Singer

cyril: So one option is 5-6 Feb in Europe.

glenn: Propose to block out 3 days to get all the issues fixed.

group: hard to justify 3 days, 2 days easier

glenn: if 5-6 I could make it ahead of time on Sunday 4th

nigel: And if not in Europe then in January in the US, otherwise week of 8-12 in the US (probably west coast)

tmichel: It could also be hosted in Sofia-Antopolis.

cyril: Can we agree the dates on the call next week?

nigel: Yes I'll add it to the agenda.

<dsinger> 5-6 feb is 3GPP meeting for me Fukuoka

IMSC 1.0.1 timeline

nigel: We're in CR, awaiting a second implementation report.

IMSC 1.0.1 Implementation Report

cyril: Does TTPE support the two features?

glenn: We could probably add to those - I think I've got both implemented, I'll check.

IMSC 1.1 timeline

pal: This should match TTML2
... Realistic to go to CR with IMSC 1.1 in early February

atai: I would like to see a timeline we are forced to follow and we really have to meet that
... goal, and if something blocks then take measures to take out features or whatever, so
... the schedule we lay out is a high priority requirement. That's the hardest part of standards
... to really follow the roadmap.

glenn: This is much more achievable for getting to CR, since we can't manage delivery of implementations

atai: TTML2 is an ongoing thing that covers a lot and we tried often to have roadmaps
... and don't usually meet the milestones. I would suggest at least for IMSC 1.1 where there's
... a specific set of features, which is more manageable, we have a really strict timeline.

cyril: Can we go to CR for IMSC 1.1 before TTML2 is in CR?

wseltzer: Yes, as you go further forward you get harder and harder questions. Going to PR
... you would want a more stable reference.

atai: That just moves the problem point further into the future. If some features are not
... ready one option would be to mark the features as at risk.

cyril: That's one option or move to v.next

atai: I would decouple a bit IMSC 1.1 from TTML2 though it is a good goal to tie them together.
... If TTML2 cannot bring in the required contributions we need a plan, for example to leave
... out the feature.

nigel: If IMSC 1.1 depends on a TTML2 feature what would you do?

<wseltzer> [[from https://www.w3.org/Guide/transitions2017?profile=CR&cr=new Does this specification have any normative references to W3C specifications that are not yet Candidate Recommendations? Note: In general, documents do not advance to Recommendation with normative references to W3C specifications that are not yet Recommendations. See Normative References Guidelines. ]]

atai: Maybe move the specification into IMSC 1.1

<wseltzer> [so it's a question the Director asks, but not a straight blocker]

<wseltzer> [see also https://www.w3.org/2013/09/normative-references#whole]

cyril: please no!

glenn: We don't identify features as at risk until we go to CR.

wseltzer: I don't know the specific details of the specs but just added above references
... to the process about what the Director will ask.
... If there are reasons of the platform that make it likely that referred things will be stable
... then that's a substitute for having reached recommendation at the same time.

cyril: Responding to Glenn, we should distinguish the features for which we think they
... are correctly specced but maybe not going to be implemented from those where we think
... the current spec text needs further work.

nigel: +1

glenn: Quick point - right now TTML2 has all the normative references pointing to final specs,
... there are no normative refs to non-final specs. There are in the informative references.
... I plan to keep it that way.

nigel: We recently learned that it is allowed to normatively reference CRs - I'm really uncomfortable with that.

wseltzer: I'm not encouraging it, the general policy is that the state at least matches.

atai: To confirm it is possible to reference W3C specs not at Rec if the Director agrees?

wseltzer: Yes. Gold standard is to reference Recs, but if you can argue instead that there
... is specific reason to believe the piece you are referencing is stable then the Director will listen to that argument.

dsinger: We've seen that in the past where we pick up stable definitions from non-Rec specs,
... where those definitions are not at all contentious.

atai: Can we set a hard deadline for IMSC 1.1. If we are setting a F2F meeting for Jan/Feb
... then it is unlikely to go to CR status in January.

pal: If we go to WR in 2 weeks then we have time for 2 months review and to meet that timescale.
... To get the feature set that's really key and we're done with requirements.

dsinger: The more gaps you leave the harder it is to document wide review completion.
... It is easier to fix before asking for review.

pal: That's the goal, but if there's a goal for an informative mapping from a TTML2
... feature to CSS it is not essential to put it in wide review.

atai: End of Feb for IMSC 1.1 CR?

pal: If the WR ends before the beginning of Feb then at the F2F you can deal with both
... IMSC 1.1 and TTML2 together.

nigel: So end of Feb for IMSC 1.1 CR works?

pal: Giving editing time after the F2F? Yes

glenn: I'd like to try to time it so TTML1 Third Edition get published same day as TTML2.

pal: Yes.

glenn: If IMSC 1.1 is also available we might try to publish all three at the same time.

atai: If possible yes

pal: Otherwise there'll be dependency issue.

Charter 2018

nigel: Our current charter expires end March 2018.
... So we need to think about what to do.

<wseltzer> Current charter

nigel: We have choices: 1. Extend - plh tells me he can extend by 6 months.
... 2. Or make a new charter that would take us further out - 2 years?

wseltzer: That's a commonly used duration
... Wendy Seltzer, W3C Strategy Lead. I look at what's next, and rechartering is a part of that,
... seeing what you might want to put into a new charter - here to help.

<wseltzer> nigel: My view, we should recharter

<wseltzer> ... active group, making good progress on specs

<wseltzer> ... foresee need over the next 2 years to keep going

<wseltzer> ... multiple drivers: work isn't done; many liaisons and external standards groups that reference this group's work

<wseltzer> ... regarding scope, think we should keep going with TTML work

<wseltzer> ... complete semantics; still work to do with audio, possible connections to WICG

<wseltzer> ... and text tracks

<wseltzer> atai: overhead of rechartering?

wseltzer: The AB has looked us generally to look for 5% members supporting work, about
... 22 members, and that there are not formal objections. I don't think we try to make that
... a hurdle if there is significant interest in the work, that's of more concern than strict
... numbers. If there are participants and implementers then the team will help make the
... case to the Director that you should continue. If on the other hand there is limited
... interest then maybe W3C should reexamine and feedback from members is part of the
... message back about if it is something the web needs.

dsinger: 5 things for the group that works on should think about over the next few years.
... Text Track Cue work and DOM - incubation first is the right answer.
... Synchronising what's on a page with behaviour, and javascript, pre-flighting etc needs
... more thought, for exact time alignment.
... We're going to have to look at issues around navigable video, VR, AR etc which are
... quite hard - where to put captions?!

nigel: Yes, BBC R&D has blogged on this

dsinger: There's CSS stuff too to meet captioning requirements.
... And if there's a need for more language support, there may be more work to do there.
... As languages move from basic through to advanced, more work will be needed.
... Those 5 are all things for the timed text community to look at over the next few years.

nigel: +1

dsinger: And maintenance - the W3C shouldn't dissolve groups that own standards that
... are complex enough to expect bug reports.

atai: I support all of those 5 things. And it helps if we provide more test material
... for different languages. On text track and text track cue and the WICG initiative, I would
... not yet make it a deliverable of TTWG yet because it is dependent on other groups and
... participants. I would not give this group the responsibility to find a solution for that.

nigel: I think the WICG work might come up with a recommendation for deliverables that
... are a good fit for TTWG or for another group, it's too soon to say.
... Recall that in Lisbon last year we resolved that if we recharter and WebVTT is not in
... CR then we would not include it in the new charter.
... My understanding is that if a group stops working on a Rec track document it gets published as a Note.

wseltzer: Yes you send it to Note.

RESOLUTION: We plan to recharter from 1st April 2018.

nigel: Any points about strategy and subject matter?

wseltzer: The questions are: Do you have the right people participating?
... Do you need team help in getting participants engaged?
... Are there other people who are likely asking for things?

cyril: We could use more browser vendors in the group - very happy to have Apple on board,
... but it would be great to have others.

nigel: +1

atai: I hope that the text track cue work will also generate more interest in the work of this group.

cyril: CSS alignment should help too.

atai: Yes. It's hard just to ask for more browser vendors!
... CSS mapping, Text track and Text Track Cue initiative, and Web Platform Tests are all
... things that could be a good sign.

<Zakim> wseltzer, you wanted to discuss WICG interaction

wseltzer: We've been hearing lots of interest from browser implementers on incubating things
... in WICG and bringing to WGs when there's proof of implementation, so good to hear
... that you're thinking about doing that. Another scoping question: are there specific of
... those incubating ideas that we should be considering to bring in, or making it easy to
... add to the charter when things get far enough through the incubation process?

nigel: Can we do that?

wseltzer: It would need a review.

dsinger: So make an advanced warning that it could happen.
... I like doing things in CGs to start with because there's a big difference in size between
... the people here and people at FOMS meetings.

atai: I would support that process, because you can start a process with the option to fail,
... and also to discover what is the deliverable, but to reintegrate into the group's charter
... is really good, more agile, if there's an easy way to do that.

wseltzer: We did something similar in the Web Platform Group to add some incubated
... deliverables and we scoped the review around only the deltas.
... Members are always free to come to us to reexamine something that's different.
... They also can do that without a charter review.
... It's good to give the group freedom to incubate. WebVR is only a CG, but I agree they
... will have fascinating requirements, and that group or elsewhere is a good place to start the conversation.

nigel: What's the timeline for getting to a Charter that begins 1st April?

wseltzer: 4 weeks AC review, 2 weeks resolving comments and questions, plus the time
... before that for review in the W3M - at least two months.

dsinger: By the end of Jan we need it ready to start review.

Charter repo for TTWG

<wseltzer> [note also the generic charter template, https://w3c.github.io/charter-drafts/charter-template.html]

nigel: I'm happy to continue as Chair, or to have other co-chairs, or if anyone would rather
... I step down, let me know!

<inserted> dsinger: We could do with a fresh co-Chair for you.

wseltzer: I'll add a link to the charter template, needs to be compared to the charter
... draft that you have.
... It mentions the various horizontal review requirements, testing good practices etc.

<dsinger> notes that the GitHub charter has an end date on 2016, and doesn’t seem to match the current charter. suggest we pull it up to date as a starting point

Action for Thierry

nigel: Who edits it?

dsinger: The Chairs and the Team

nigel: Ok, works for me.

dsinger: I suggest the group chips in with GitHub issues

tmichel: I can start doing some cleanup on the first draft

dsinger: If we do that through the end of the year then during Jan the Chairs and the Team
... should be able to do the polishing to send it out for ballot.

TTML <--> WebVTT mapping

atai: The status remains as at TPAC in Lisbon. I checked with the remaining editor,
... Loretta from Google, on that. It makes sense to revisit the mapping document when
... WebVTT gets to CR status so there is a stable reference for the mapping.

nigel: Is there any dependency on TTML2? Can the mapping be done completely based on TTML1?

atai: Yes, I would keep it scoped to TTML1. I am not sure how many people are using it.
... I would first wait on WebVTT getting to CR then check the current document for any
... errors and then discuss how to proceed and what to do.
... I remain as Editor, and Loretta is the other contributing member, since Courtney is no longer active.

dsinger: I haven't heard much about it - I think it is a fairly quiet subject with no pressing need.
... A 608 mapping to TTML would be more useful. Is there one?

pal: Yes, SMPTE has them, RP2052-10 and RP2052-11.
... (for 708 too).

nigel: Does it need to be in the new charter?

tmichel: Otherwise you can't work on it

nigel: [surprise] I don't think we need to list Notes in the charter to work on them.

wseltzer: As long as the subject matter is generally in scope you don't have to name documents.

nigel: Isn't it obvious that a WG can go and revisit a Note that it had previously published?

wseltzer: It would be possible for a Charter to specifically exclude working on anything
... not in the deliverables.
... But that would not be usual.


pal: Can we get rid of ttp:version? Glenn have you been able to consider it?

glenn: I'm assuming that it will remain.

pal: When can we come to a conclusion on that?

nigel: Do we have an objection to ttp:version in TTML2?

pal: There's an open issue

cyril: Can we add that to the agenda for next week's call?

nigel: Yes

glenn: I know it's coded and used.

cyril: Let's talk offline.

Break - return in 20 minutes


dsinger: We have 22 open issues, I would like to work through any of them where we
... can help close them out.
... The first one is on colour, which has been open since first WR

<dsinger> open issues here

<dsinger> https://github.com/w3c/webvtt/issues?q=is%3Aopen+is%3Aissue+label%3AWR-open

dsinger: Tess has joined us for issue #365
... various attempts to solve since WR1

Wide Review Comment 2017: Text color must be mandatory #365

github: https://github.com/w3c/webvtt/issues/365

dsinger: I think we may have a proposal here, we have the right people in the room.

hober: Summarising the hallway discussion - silvia if acceptable to you, that's very exciting.
... The VTT spec should say UAs that do not support CSS and wish to conform with VTT
... must support setting foreground and background color and the bit I'm unclear on is
... do we refer to the 608/708 mapping doc by reference or make the mapping in an appendix
... and do the specific class names defined require support in a stylesheet in a UA that
... supports CSS. Not sure how much I care. We need some RFC2119 language saying if
... you don't support CSS you have to support colour. THat's what we agreed on.

<dsinger> 608 mapping here https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html

atai: We agreed that they should support them as though at least part of the stylesheet were loaded.
... I would prefer the mapping as an annex rather than referencing a note.

dsinger: The note isn't even finished.

hober: Works to me, a table, which the 608 mapping document can refer to.

silvia: It makes sense to put it into the spec itself is that it is not 608 and 708 specific,
... as atai pointed out. Having foreground and background color is something everyone wants.
... Then 608/708 can reference it.

dsinger: This is the only color set well defined in the industry, true?

silvia: yes

<silvia> I meant: the 608/708 to vtt mapping spec

atai: As basic support that's what we need

hober: we have agreement on UAs that don't support CSS.
... Do we also require CSS supporting UAs to load the stylesheet?

silvia: It should be available to all.

atai: I agree with silvia

dsinger: I thought so too until a few days ago and then I thought there is an advantage
... in including the CSS styles of the colours you are using in the document so it is self-complete.
... Maybe more important for the VTT file to work everywhere.

hober: Yes much more important.

dsinger: So all UAs behave as though those classes are predefined.

silvia: So we'll put those colours plus mappings into an appendix and say they are a base

<dsinger> a) put that style-sheet into an annex (b) all UAs must behave as if that style-sheet were pre-loaded

silvia: set of classes that every UA supporting VTT needs to support?

<hober> hober: not the whole stylesheet; just the bits defining the colors

<dsinger> in section 3 of https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html

<silvia> https://github.com/w3c/webvtt/pull/395#issuecomment-341857127

RESOLUTION: we include the class Lime with a note saying that what 608 calls Green, we call Lime

<scribe> scribe: dsinger

These are formally the UA style sheet as defined by CSS

general discussion


<silvia> https://github.com/w3c/webvtt/issues/385

<silvia> https://www.w3.org/TR/webvtt1/

<silvia> wrong link: https://w3c.github.io/webvtt/

<silvia> https://github.com/w3c/webvtt/issues/384

notes that we have an authoring guide at https://www.w3.org/wiki/VTT_Concepts

Silvia: this is fundamental discussion about the structure of the spec and it seems rather late to change that

<Zakim> dsinger, you wanted to discuss the document retrieved from web platform docs

<silvia> https://github.com/w3c/webvtt/pull/398

RESOLUTION: do not address the algorithmic nature of the VTT spec at this time; but editors to improve 6.1 and its readability as much as they can
... co-chair (ds) to edit the Wiki to warn it might not be up to date, all to improve to make it up to date as they can

<silvia> https://github.com/w3c/webvtt/issues/383

<silvia> https://github.com/w3c/webvtt/issues/381

RESOLUTION: We insert a NOTE that in Cue text or Comment blocks, you cannot have a blank line or -->, and that if they are a possibility you will need to define an escape syntax suitable to what you are embedding.


<silvia> https://github.com/w3c/webvtt/issues/377



Meeting wrap-up

<nigel> nigel: Thanks everyone for a really productive positive two days of meetings.

<nigel> dsinger: Thank you Silvia for sacrificing your Saturday morning!

<nigel> dsinger: Really positive

<nigel> nigel: We'll finalise details of the next TTWG F2F in next week's call

<silvia> Thanks, I think we addressed the important open issues on WebVTT!

<nigel> nigel: Meeting adjourned!

<nigel> atai: Thank you Nigel for scribing

<nigel> silvia: Thank you, we made really good progress

<silvia> bye!

<nigel> nigel: [meeting adjourned]

Summary of Action Items

Summary of Resolutions

  1. Approve IMSCvNext requirements pull request #10
  2. Add a note to say: Note: The application of fillLineGap does not result in hiding any character glyphs that would be visible without fillLineGap. Therefore after application of fillLineGap all parts of all character glyphs with a background colour behind them continue to have that background colour applied.
  3. We do not need to refer to the Encoding spec and do not need to make any change.
  4. Add "which is a" before "descendant".
  5. Mark rubyAlign="withBase" as at risk for CR
  6. Mark rubyAlign="withBase" as at risk for CR
  7. We do not need fontVariant for half vs full width or superscript/subscript
  8. Adopt linePadding in TTML2, remove inlineAreaBreak, keep padding on content
  9. Do not deprecate ebutts:multiRowAlign, prohibit inline block, leave TTML2 as is.
  10. Remove ttp:mediaOffset as it stands and open a new issue to explain how to resolve media time
  11. Remove ttp:mediaDuration
  12. Add ttm:alt attribute to TTML2 and permit it in IMSC 1.1 and deprecate ittm:altText in IMSC 1.1
  13. Keep itts:forcedDisplay in IMSC 1.1 and do not add anything to TTML2
  14. Remove fillLineGap from TTML2 and retain itts:fillLineGap in IMSC 1.1.
  15. Retain ittp:aspectRatio in IMSC 1.1 and add a note explaining the equivalence to ttp:displayAspectRatio in TTML2
  16. Remove linePadding from TTML2
  17. keep ittp:activeArea in IMSC 1.1, modify TTML2 ttp:activeArea to take position instead of origin, informatively note value mapping from ittp:activeArea to ttp:activeArea
  18. Deprecate smpte:backgroundImage in IMSC 1.1 in favour of TTML2 image
  19. Deprecate ittp:progressivelyDecodable
  20. Reference details of deprecated ittp:progressivelyDecodable from source in IMSC 1.0.1
  21. We plan to recharter from 1st April 2018.
  22. we include the class Lime with a note saying that what 608 calls Green, we call Lime
  23. do not address the algorithmic nature of the VTT spec at this time; but editors to improve 6.1 and its readability as much as they can
  24. We insert a NOTE that in Cue text or Comment blocks, you cannot have a blank line or -->, and that if they are a possibility you will need to define an escape syntax suitable to what you are embedding.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/11/11 01:30:00 $