<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
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
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.
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
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 §5.2.4.2 (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
github: https://github.com/w3c/imsc/issues/254
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.
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.
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 §10.2.3.7.
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.
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.
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
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.
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
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).
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.
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.
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.
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.
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.
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
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.
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
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
nigel: Cyril, Eric, Chris, Andreas, Pierre, Nigel, Thierry
<scribe> scribe: nigel
<scribe> Chair: Nigel
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.
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.
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.
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
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
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
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
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.
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.
<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.
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
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.
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.
nigel: return at 1:30 please
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.
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
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.
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.
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.
<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
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.
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.
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
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
https://github.com/w3c/webvtt/issues?q=is%3Aopen+is%3Aissue+label%3AWR-open
<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
<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]