- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 18 Jan 2018 17:22:28 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <D6868610.52E02%nigel.megitt@bbc.co.uk>
Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at: https://www.w3.org/2018/01/18-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
18 Jan 2018
Attendees
Present
Andreas, Cyril, Glenn, Nigel, Pierre, Thierry
Regrets
None
Chair
Nigel
Scribe
nigel
Contents
* [2]Topics
1. [3]This meeting
2. [4]TTML2 Actions
3. [5]Consider aligning initial values of tts:position
and tts:origin. ttml2#551
4. [6]Remove explicit animation, styling and timing from
break (br) element. ttml2#552
5. [7]Do not default to px units in the absence of units
on a `<length>` ttml2#561
6. [8]Clarify tts:fontSize semantics ttml1#301 (pull
request)
7. [9]First Pass at IMSC2 to CSS Fallback imsc#218
8. [10]privacy and cross-origin policies not clear
imsc#280
9. [11]Clarify [associate region] algorithm ttml1#288
(pull request)
10. [12]Ambiguous definition for determination of
descendant region identifier. ttml1#194
11. [13]is tts:textShadow required? imsc-vnext-reqs#13
12. [14]Consider allowing images and text in the same
profile imsc-vnext-reqs#4
13. [15]Clarify anonymous span construction and implicit
duration semantics ttml1#318 (pull request)
14. [16]Meeting close
* [17]Summary of Action Items
* [18]Summary of Resolutions
__________________________________________________________
<scribe> scribe: nigel
This meeting
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.
TTML2 Actions
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>
[19]http://www.w3.org/AudioVideo/TT/tracker/actions/508
[19] 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.
Consider aligning initial values of tts:position and tts:origin.
ttml2#551
github: [20]https://github.com/w3c/ttml2/issues/551
[20] 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
Remove explicit animation, styling and timing from break (br)
element. ttml2#552
github: [21]https://github.com/w3c/ttml2/issues/552
[21] 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
Do not default to px units in the absence of units on a `<length>`
ttml2#561
github: [22]https://github.com/w3c/ttml2/issues/561
[22] 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
Clarify tts:fontSize semantics ttml1#301 (pull request)
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.
First Pass at IMSC2 to CSS Fallback imsc#218
github: [23]https://github.com/w3c/imsc/issues/218
[23] 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
privacy and cross-origin policies not clear imsc#280
github: [24]https://github.com/w3c/imsc/issues/280
[24] 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
Clarify [associate region] algorithm ttml1#288 (pull request)
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.
Ambiguous definition for determination of descendant region
identifier. ttml1#194
github: [25]https://github.com/w3c/ttml1/issues/194
[25] 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
is tts:textShadow required? imsc-vnext-reqs#13
github: [26]https://github.com/w3c/imsc-vnext-reqs/issues/13
[26] 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
Consider allowing images and text in the same profile
imsc-vnext-reqs#4
github: [27]https://github.com/w3c/imsc-vnext-reqs/issues/4
[27] 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.
Clarify anonymous span construction and implicit duration semantics
ttml1#318 (pull request)
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>
[28]https://github.com/w3c/ttml1/pull/318#discussion_r162199073
[28] 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.
Meeting close
Nigel: Thanks everyone. [adjourns meeting]
Summary of Action Items
Summary of Resolutions
1. [29]Make the initial value of tts:position "top left" and
remove the text defining behaviour of position when
specified on the tt element.
2. [30]Align the content model of br in TTML2 with TTML1 and
make the recommendation about animation on br stronger by
deprecating it in TTML2.
3. [31]Revert to prohibit use of `<length>` without units.
4. [32]Make no change to IMSC2 and close this issue.
5. [33]Close this pull request #288 without merging.
6. [34]Close issue with no spec change.
7. [35](updated) Don't close the issue, close the pull request
and Defer the issue to a later edition.
8. [36]textShadow is required, no spec change needed.
9. [37]Defer this requirement for the time being, absent more
detail.
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [38]scribe.perl version
1.152 ([39]CVS log)
$Date: 2018/01/18 17:21:48 $
[38] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[39] http://dev.w3.org/cvsweb/2002/scribe/
----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
---------------------
Received on Thursday, 18 January 2018 17:22:58 UTC