W3C home > Mailing lists > Public > public-tt@w3.org > January 2018

{minutes} TTWG Meeting 2018-01-18

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] http://www.w3.org/

                Timed Text Working Group Teleconference

18 Jan 2018


          Andreas, Cyril, Glenn, Nigel, Pierre, Thierry





     * [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
         7. [9]First Pass at IMSC2 to CSS Fallback imsc#218
         8. [10]privacy and cross-origin policies not clear
         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


   <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


     [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.

   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".


   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

   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

   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

   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

   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

   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>`

   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

   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

   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

   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

   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

   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

   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

   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.


     [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

   [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/



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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:44:30 UTC