<scribe> scribe: nigel
Nigel: For today we can dive
straight into the actions, pull requests and issues. I
propose
... to do TTML2, TTML1, IMSC, IMSC vNext Reqs in that order.
And to include the issues
... that Pierre sent links to earlier.
... Any other business or particular requests for things to
cover today?
Glenn: Could you comment on the issue regarding static files you just posted?
Nigel: [discussion of issue and reason for needing to serve images for use in the wiki]
Glenn: You could use rawgit to serve from the master branch.
Nigel: Yes, that could
work.
... While we're on build scripts, I noticed that we need the
build script to validate non-spec
... artefacts like example XML files too, and this is true for
both TTML1 and TTML2.
... I just sent some stats around - it is clear that we will
not be able to close the
... currently open TTML2 issues within our current process and
have a CR ready by the
... end of the month. So we have to defer issues or allow
ourselves a couple of weeks of
... slippage of the CR.
... Can I just check with Editors if there is any likelihood of
a change in the rate of
... progress in tackling issues compared with what you've done
in the last few months?
Cyril: I'm travelling but plan to contribute.
Glenn: I hope to increase my rate
over the next couple of weeks. We have the option to
... agree to merge pull requests in meetings ahead of the
review period.
Pierre: I count 6 non-editorial issues which I believe we can resolve by the end of the month.
action-508?
<trackbot> action-508 -- Thierry Michel to Check if there are editorial/substantive labels for ttml2 issues and add if not. -- due 2017-10-12 -- OPEN
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/508
Glenn: There are already
editorial and substantive labels, plus a third "no change"
which
... I added, where I anticipate no change to the spec, e.g.
changes to build process files
... so I think you can close 508. It's no longer an issue.
Thierry: I didn't go through it but I'm fine closing it.
close action-508
<trackbot> Closed action-508.
Glenn: By the way I tend to put
those labels on issues when they first get posted based
on
... my anticipation but sometimes they change in actuality
based on the implementation.
... I review those labels when closing issues off.
github: https://github.com/w3c/ttml2/issues/551
Cyril: I added it to the agenda
but expected some internal feedback and have not had any
... yet so I propose to defer it. Does the group have any
position on this issue?
Glenn: If we defer it we end up with two different initial values as apply to region.
Pierre: This is not a big fix.
Nigel: Are we all agreed that the
initial value of position should be "top left" to align
with
... the initial value of origin, for regions?
Glenn: I think it makes more
sense to have "center center" but it introduces the
disparity.
... Since users can add an initial element it is easy to change
so I'm happy with making
... it "top left".
+1
Nigel: Do we need to qualify this for regions and have a different treatment for the root element?
Glenn: There is some normative
language in the spec that applies it to tt but on
reviewing
... it recently I noticed it was not applicable to tt, so there
is that discrepancy to deal with -
... does it apply to tt or not? Does it position the root
container region within a positioning
... area such as the related media object region or some other
positioning area.
... There's also the applicability of it to backgroundImage and
image with respect to the
... extent of the padding area. With regard to the question of
initial value semantics we
... need to have an answer that can apply to all contexts of
use but we may actually end
... up saying there is an exception based on the content of
use.
Nigel: It doesn't apply to image
because that has the tts:backgroundPosition attribute.
... So I propose if we want a position to apply to tt then we
call it something different.
Glenn: I don't like that idea - there are three similar position things in the spec. It is possible I admit.
Nigel: We possibly do not have
the requirement to explicitly position the root container
... region anyway.
Glenn: IMSC1 makes the normative
statement of positioning the root container region
... centered relative to the related media. That's where this
feature comes from.
Nigel: Does anyone need to specify any option other than "center center"?
Glenn: There's a concept we
started to discuss one time - frequently I find in
letterboxing,
... especially in some of the really wide formats, the
captioning is in the letter box area
... outside the active video. Right now other than using
position we don't have any way
... to achieve that. We did not thoroughly discuss this
issue.
Nigel: For now can we agree on
position for region and open a different issue for
positioning
... the root container region?
Glenn: The easiest thing to do is
remove the two paragraphs and a note beneath the Percentage
Based Positioning
... diagram under tts:position, after reviewing if there's
anything that applies to region.
... If anything does apply to region I would leave that
present.
Cyril: Regarding the initial
value I'm fine. Re the use on the tt element, how does
this
... relate to the alignment we discussed with the related media
object that is also in IMSC 1.1?
... Is it configurable in IMSC 1.1?
Pierre: No the root container
region cannot be configured within IMSC 1.1. Maybe a
container
... like ISOBMFF might allow it to be specified.
PROPOSAL: Make the initial value of tts:position "top left" and remove the text defining behaviour of position when specified on the tt element.
RESOLUTION: Make the initial value of tts:position "top left" and remove the text defining behaviour of position when specified on the tt element.
Glenn: Where we remove functionality I have been marking as ttml.next. That applies here.
github-bot, end topic
github: https://github.com/w3c/ttml2/issues/552
Nigel: If we do this, then will
it cause any incompatibilities with TTML1 documents that
... use the syntax?
Pierre: Will the prohibited content be pruned prior to validation?
Glenn: I'd say this is borderline.
Pierre: We have already
disrecommended the syntax in TTML1 Third Edition.
... We can disrecommend it from TTML2 and prohibit it from a
later version of TTML.
Glenn: Ok.
Cyril: I'm not sure how to
implement this. Is it correct to match TTML1 and remove
things
... introduced in TTML2?
Pierre: Change the disrecommendation to a deprecation.
Nigel: +1
Glenn: +1
Cyril: TTML1 did not talk about styling, just animation and timing.
Pierre: Styling and timing were added in TTML2 and need to be removed to match TTML1.
Cyril: No TTML1 has styling.
Pierre: It doesn't have timing.
Cyril: What should we do with style?
Glenn: We don't need to do
anything because no style attribute in TTML1 applies to
br.
... Whether the attributes are present or not is academic.
Pierre: I agree with Glenn - the only thing is to remove timing and deprecate animation.
Cyril: That's fine by me, I can do that.
Glenn: We need to check if any style is now applicable to br.
Cyril: Okay I'll check and add it to this issue if there are any.
RESOLUTION: Align the content model of br in TTML2 with TTML1 and make the recommendation about animation on br stronger by deprecating it in TTML2.
Glenn: Specifically we are removing animate, begin, dur, end, region and timeContainer.
github-bot, end topic
github: https://github.com/w3c/ttml2/issues/561
Glenn: We had introduced a
default unit in TTML2 to match what was in SVG. You make
a
... case for not using it because it makes the potential use of
a `<number>` as a syntactic
... element problematic in the case that some property admits
both length and number as
... values. I don't think we have any of those right now but we
could do in the future.
... TTT implements this but I'm not wedded to it strongly
enough to insist on it staying in.
... We don't use `<number>` with lineHeight for
example.
Nigel: This issue has 2 thumbs up.
Glenn: It will be a substantive change [adds the label]
RESOLUTION: Revert to prohibit use of `<length>` without units.
github-bot, end topic
Pierre: This is awaiting a review from Glenn after the changes I made following our discussion last week.
Glenn: Okay I'll get that done today.
Pierre: Thanks - it matches TTML2 and what we discussed.
github: https://github.com/w3c/imsc/issues/218
Pierre: Thanks to the work done
in TTML2 a lot of this is moot. My proposal is to close
this
... but I think you're suggesting there be some text in IMSC
1.1 to cover the features not
... described in TTML2.
Nigel: That's correct.
Pierre: Some of those are present
because there is no mapping to CSS. Is it worth saying
that,
... especially since work is happening to introduce them in
CSS?
Nigel: I see your point, I could live with omitting them.
RESOLUTION: Make no change to IMSC2 and close this issue.
github-bot, end topic
github: https://github.com/w3c/imsc/issues/280
Nigel: There's been similar work on TTML2 here.
Pierre: Exactly, I want to check we're addressing w3c/ttml2#405.
Cyril: I submitted a pull for
that issue - I wasn't aware of this so I'll check this text
and
... take it into account.
SUMMARY: Continue with this when the TTML2 issue resolved.
github-bot, end topic
Pierre: I thought I'd add this to
the agenda not because I have a good solution but because
... I think it is becoming increasingly risky to try to solve
this within the timeframe we have.
... As we have known for a year this goes to the heart of the
ISD construction algorithm.
... The benefits of solving it are minimum because most
implementations don't trigger this
... behaviour. I'm getting close to suggesting that we defer
this.
Glenn: I agree. The original
intent was to resolve a potential ambiguity about
interpreting
... a particular point 3 in the current TTML1 spec. I'm no
longer convinced that there's an
... ambiguity there in any case. I'm not happy with the
proposed change - going from 5 steps
... to 8 steps is the wrong direction.
... I would keep it the same in TTML2.
... We could address the potential ambiguity with a Note but I
don't think it is really
... necessary. The trail of the thread documents it pretty
well. Let's do nothing right now.
Andreas: I marked the original
issue with a heart because that was a mechanism used at
... one point to mark issues that people wanted to discuss. It
doesn't carry any particular meaning.
Glenn: The proposed language in
the original issue is what we ended up implementing
... in TTX, so we've already basically implemented that
recommendation.
Nigel: That's the one part that is not in the pull request!
Glenn: That's true. Part of the
problem is that we have not agreed on the overall outcome
... we are trying to achieve.
Pierre: Exactly, and this has in practice hardly any impact.
Glenn: I've never had a bug report on this.
Pierre: Me neither.
RESOLUTION: Close this pull request #288 without merging.
github: https://github.com/w3c/ttml1/issues/194
Nigel: See also discussion on #288 (pull request).
RESOLUTION: Close issue with no spec change.
Pierre: That's the only thing we can do now.
Glenn: Close this without prejudice.
Pierre: We should defer it - characterise it as to be fixed later.
RESOLUTION: (updated) Don't close the issue, close the pull request and Defer the issue to a later edition.
github-bot, end topic
github: https://github.com/w3c/imsc-vnext-reqs/issues/13
Pierre: It sounds like textShadow
and textOutline have different sweet spots and don't
conflict.
... textShadow is supported by CSS so my plan is to support
both in IMSC 1.1.
Nigel: It's a small point, but do we need to point out in the spec in an informative note why both are needed?
Pierre: Good examples as in TTML2 will show the difference. They're really different effects.
Cyril: I definitely don't want to remove textOutline because we're using it.
Pierre: I've also heard the same for textShadow.
RESOLUTION: textShadow is required, no spec change needed.
github-bot, end topic
github: https://github.com/w3c/imsc-vnext-reqs/issues/4
Pierre: A reminder that this is IMSC 1.1 requirements.
Nigel: Right so some other version of IMSC in the future could support both image and text simultaneously.
Pierre: Exactly.
... Specifically on this issue, it is supported in TTML2, the
question is if it is a requirement for IMSC 1.1.
Nigel: Playing devil's advocate
here, our goal is to produce a global subtitle standard,
and
... there's a concrete use case in existence already, in use in
Japan, so we should support that feature.
Andreas: I'm not sure that an informal conversation is enough to add this to the requirements list.
Nigel: This may not be the most
diplomatic approach - it was a genuine conversation from
... someone who came to me as Chair and asked for a feature to
be requested.
Cyril: We would need to know more
detail about the precise layout requirements - is it
needed
... in vertical layout for example?
Pierre: It is reasonable to ask for more information.
Andreas: What does the
requirement list mean? Is it the list of requirements we agree
to as
... group members, or those collected from other
organisations?
Pierre: It is the consensus list of requirements to drive IMSC 1.1.
Nigel: +1
Andreas: Then we need to ask if this is needed for the next version of IMSC.
Nigel: [scans ARIB-TT spec] - it
looks like they're building this functionality based on
SMPTE-TT.
... Shall we defer this then until a future version of the
spec, assuming we have more information?
Pierre: Yes please go ahead.
RESOLUTION: Defer this requirement for the time being, absent more detail.
github-bot, end topic
Nigel: I've added the other issues to the 1.1 milestone but not this one.
Nigel: My question is why we
replace contiguous anonymous spans with single ones?
... Does it make any difference?
Pierre: Note this has been in the spec forever.
Glenn: To the extent that we
defined semantics for timings on anonymous spans, I took
the
... non-collapsed spans to be equivalent to the collapsed spans
from a timing perspective.
... As long as you do that I think you end up with the same
semantics whether you do it
... before or after time resolution.
... Efficiency was a large consideration in collapsing the
spans but I cannot rule out off the
... top of my head that there wasn't something else. I suspect
there isn't.
... It is also about testability though - should we have a
normative wrapping to a concrete
... representation of an ISD used for testing purposes then
this makes a difference.
Nigel: My concern is that this refactoring has accidentally introduced a change that we did not intend.
<pal> https://github.com/w3c/ttml1/pull/318#discussion_r162199073
Glenn: I am pretty sure the contiguous span collapsing can only occur before pruning inactive elements.
Pierre: That's how imscjs does it.
Glenn: My implementation would not do it either.
Pierre: In the clarified Third
Edition it is not a possibility to do it, so the question is if
it
... was possible before. Since it happened in style resolution
before, that was after timing
... resolution, then it's pretty clear that...
Nigel: If you resolve timings
first and then do this process then you would end up collapsing
the
... two anonymous spans.
... Is there ever any difference in presentation between two
contiguous anonymous spans
... containing some text and the same text in a single
anonymous span?
Pierre: As children of a seq container they have no implicit duration so they never display.
Nigel: Agreed.
Glenn: XML representations can
generate as many text nodes as they like.
... There are lots of processing features that are not
specified that could lead to a change in
... interpretation based on the anonymous spans, for example
being treated as possible
... word breaks or segment boundaries.
Nigel: I feel as though we are
not going to resolve this and should move on.
... It's clear to me that we are introducing a change that
could make it a requirement to
... generate contiguous anonymous spans, and that it is
possible that could trigger some
... bugs not previously seen. However we have not got enough
clear information to block
... progress on this pull request, and it is not even
completely clear that this behaviour
... would not have happened before, so I'll remove this from my
list of points to block my approval of the pull request.
Nigel: Thanks everyone. [adjourns meeting]