W3C home > Mailing lists > Public > public-tt@w3.org > October 2017

{minutes} TTWG Meeting 2017-10-12

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Thu, 12 Oct 2017 16:47:12 +0000
To: Timed Text Working Group <public-tt@w3.org>
Message-ID: <D6055A76.4BB9F%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/2017/10/12-tt-minutes.html

Following the proposal last week the group resolved:

RESOLUTION: TTWG agrees to publish FPWD of IMSC 1.1
The review period for resolutions under our Decision Policy ends on Thursday 26th October, however note that in this case the intended publication date is sooner than that, on 17th October.

Minutes in text format:


      [1] http://www.w3.org/

                Timed Text Working Group Teleconference

12 Oct 2017

   See also: [2]IRC log

      [2] http://www.w3.org/2017/10/12-tt-irc


          Nigel, Pierre, Thierry, Glenn, Mike, Cyril, David_Ronca





     * [3]Topics
         1. [4]This meeting
         2. [5]processor backwards compatibility #458
         3. [6]IMSC
         4. [7]itts:fillLineGap is unclear about what it is
            filling between exactly #263
         5. [8]What fillLineGap does/ affects #254
         6. [9]Should UTF-8 'as specified in' point to the
            Encoding spec? #253
         7. [10]TTML2 Wide Review Issues
         8. [11]SMPTE backgroundImage annotation #460
         9. [12][HTML5] reference should be informative. #461
        10. [13][SSML] reference should be informative. #462
        11. [14][WEBAUDIO] reference should be informative. #463
        12. [15][XML 1.1] reference should be removed. #464
        13. [16]Examples in section S use an unusual
            tts:displayAlign setting #459
        14. [17]Examples in section O use an unusual
            tts:displayAlign setting #254
        15. [18]Question about #background-color vs
            #backgroundColor. #455
        16. [19]Examples in section S use an unusual
            tts:displayAlign setting #459
        17. [20]Meeting round-up
     * [21]Summary of Action Items
     * [22]Summary of Resolutions

   <scribe> scribe: nigel

This meeting

   Nigel: Today, I don't think we have anything to discuss with
   TPAC today;
   ... I'd like to start running the TTML2 Wide Reviews to see if
   we have any easy dispositions.
   ... And we agreed last week to discuss publication of FPWD of
   ... And we have had some other issues raised this week on

   Mike: Request to cover backward compatibility issue in TTML

   Nigel: Ok
   ... I'm not expecting David to join to discuss WebVTT review

   Thierry: I've had no confirmation.

   Nigel: In that case I think we have a full agenda.
   ... Any other specific points to cover?

   Group: nothing else.

processor backwards compatibility #458

   github: [23]https://github.com/w3c/ttml2/issues/458

     [23] https://github.com/w3c/ttml2/issues/458

   Glenn: This may be a duplicate of #442 - anyway they are

   Mike: It's hard to summarise from the issue - lots of opinions,
   not necessarily harmonious.
   ... It boils down to how we make IMSC vNext reference TTML2 or
   TTML1, since we need
   ... a safety net for presentation processor conformance for
   IMSC 1.0.1.
   ... These things are all intertwined. Fundamentally we started
   out with what we are doing
   ... in IMSC v1.1.

   Nigel: Pierre recently made the comment that the presentation
   processor differences
   ... between TTML1 and TTML2 are already proposed for TTML1
   Third Edition. If we do that
   ... would it address the problem for IMSC or just move the
   problem somewhere else?

   Glenn: I don't think we can add features to TTML1 to resolve
   all the differences.

   Pierre: Trying to keep things simple, the first step is to
   determine if we all think that the
   ... goal of having TTML1 and TTML2 be consistent on shared
   features is a good idea. Then
   ... we can figure out how to make that happen.

   Glenn: I agree with that as a default scenario. We could
   probably add a statement to the current
   ... section on backward compatibility that says its an
   objective to achieve that modulo
   ... explicit variations or exceptions.

   Pierre: Anyone think it's a bad idea to have that as a goal?

   Mike: No, and that's where I thought we ended up last week.

   Andreas: I think it's important to make it mandatory to state
   this objective in the spec.
   ... People will look for normative statements, otherwise it
   won't help much.

   Glenn: It's different stating the objective to making a
   mandatory requirement on processors.
   ... We should separate those.

   Nigel: I think there is a problem if we let edge cases drive
   specs, and I particularly don't
   ... want us to be held back by previous specifications and be
   unable to make improvements
   ... if we find them.

   Cyril: Are we allowing for specific signalling of TTML2

   Pierre: This is only for features that TTML1 and TTML2 have in
   ... The question is if the high level goal is for parity of
   processing, as a high level
   ... principle, then we can come to the details later.

   Nigel: My understanding is this is driven by a desire for
   identical presentation processor
   ... output, so the details become important. I don't think that
   the general guiding principle
   ... is controversial, and it's easy to agree with.

   Glenn: There are layers that affect every feature - it's not
   simple than just talking about
   ... individual style features.

   Pierre: It would be bad if TTML1 and TTML2 compelled
   implementations to end up with
   ... a different computed font size on an element due to
   differing inheritance rules.

   Glenn: I recall lineHeight and ongoing discussion of this in
   TTML2 vs TTML1.

   Pierre: That's my point - these should be aligned.
   ... Again, it's the normative statements that it's important to
   make consistent.

   Glenn: We made some explicit decisions about
   lineHeight="normal" - we shouldn't go back
   ... to those decisions.

   Pierre: I'm just asking about the general principle.

   Andreas: The rendered outcome of a document only using TTML1
   vocabulary should
   ... generate the same outcome for TTML1 and TTML2 processors -
   this should be the goal
   ... of our activity. It should be mandatory for processors.

   Glenn: I certainly would not agree to that statement, in its
   entirety at least.

   David_Ronca: From my perspective the primary objective for
   TTML2 is a robust spec that
   ... will carry us into the future. Where its possible to be
   TTML1 compatible we should be
   ... but we should not preserve ambiguous or poorly defined
   features in TTML1.

   Andreas: That's a core question - how much is backward
   compatibility needed.

   Nigel: We have a mechanism via the TTML profile registry for
   systems that use it to request
   ... a specific processor type, and we should use the
   flexibility that gives us.

   Glenn: We have never had a normative requirement to have
   different implementations
   ... produce the same presentation as a general statement. If
   you throw out a lot of other
   ... variation axes, then you might say that modulo those
   variations it should be close.

   Andreas: Following the discussions, maybe there are different
   business requirements here.
   ... For our side, backward compatibility is a first priority.
   We are in the middle of uptake
   ... and adoption of the spec so it's important that current
   implementation is not blocked by
   ... a message that TTML2 is coming and may change it. That
   gives the message "wait for TTML2".
   ... At least we want to avoid that and keep TTML adoption
   ongoing including IMSC1 adoption.

   Nigel: Good point - my statement earlier was that in agreement
   with David_Ronca I think
   ... it is a stronger objective to produce a future facing spec
   than a backward compatible one.

   David_Ronca: Compare to video coders. We have to be able to
   make fixes and correctness
   ... needs to outweigh compatibility. TTML2 implementations can
   still be TTML1 implementations.
   ... It's just like encoders can still make AVC or HEVC. We have
   to be careful. I don't know
   ... if there are specific cases where we need stability of
   features, but if TTML2 gets it right
   ... and TTML1 gets it wrong then TTML2 should prevail.

   Mike: Is there an example of this?

   Pierre: I'm not aware of such a thing, and ironically many of
   those bugs were discovered
   ... while implementing TTML1, so most have been logged as a bug
   on TTML1 and fixed in TTML2.
   ... So my technical opinion is that the probability that we can
   align the two is very high
   ... via TTML1 Third Edition.

   Glenn: I would not agree - there are specific things like
   displayAspectRatio that are ambiguous
   ... in TTML1 but fixed in TTML2.

   Pierre: That ambiguity would have to remain in TTML1.
   ... The common features can be aligned.

   Glenn: If it's simply a matter of fixing prose (even normative)
   then I think we can back-fill
   ... ambiguities that don't require new features.

   Cyril: Why not deprecate ambiguous TTML1 features?

   Pierre: Some of the ambiguities are in the core layout and
   styling algorithms. So it's not
   ... deprecating a features, just correcting an ambiguity in

   Cyril: If it's ambiguous in TTML1 then noone can interoperably
   implement it in TTML1.

   Pierre: This is core, basic things like lineHeight style

   Cyril: Two choices: either it has been demonstrated
   interoperably, or it has not, in which case
   ... let's deprecate the feature.

   Pierre: You can't do that - you can't deprecate style

   Cyril: Has it been demonstrated interoperably?

   Pierre: TTPE and IMSC.js implemented it the same way.

   Cyril: Why not fix the spec to reflect it?

   Pierre: Exactly.

   Glenn: We cannot deprecate features in TTML1. There is no
   requirement for rendering
   ... interoperability, though it may have been a goal for some

   Pierre: I agree with you Cyril, we should make it work
   ... My suggestion is to fix it in TTML1 Third Edition. We could
   conceive of other ways, but
   ... that seems like a straightforward way of doing it.

   Nigel: I think if we can achieve consistency by retro-fitting
   to TTML1 Third Edition that makes
   ... it a lot easier, but does that work for IMSC 1.0.1 which
   references 2nd Edition? Would
   ... that resolve the original IMSC compatibility issues? Would
   it make TTML2 processors
   ... process say IMSC1 documents in an acceptable way?

   Pierre: We have a lot of resolutions in TTML1 GitHub issues
   reflecting TTML2 fixes, and
   ... we should capture those in a TTML1 Third Edition.
   ... The next step is to update IMSC 1.0.1, to give those
   organisations that care the opportunity
   ... to update their implementations to match the updated specs.
   ... W3C can't compel implementers to reference a particular
   version of a spec.

   Nigel: I have no problem with that - making TTML1 Third Edition
   aligned with TTML2
   ... so that TTML2 represents clean feature additions.

   Pierre: I would like to go back to the general principle.

   Glenn: If it's too general I might not be able to agree.


     [24] https://github.com/w3c/ttml2/issues/458#issuecomment-336022891

   Pierre: I proposed the text in the issue above.

   Glenn: I need to contemplate that language.
   ... When you say "features that the specs share" that doesn't
   address my point about layers.

   Pierre: "given a document that contains only TTML1 syntax, a
   processor was compelled by the TTML2 specification to process
   it differently than it would have been compelled by the TTML1

   Glenn: I don't agree with that, the way it is expressed.
   ... A clarification question: in some of my commentary on the
   issues I have pointed out
   ... that an implementor may implement a processor that adheres
   to some subset of TTML1 or TTML2,
   ... so if your objective as stated could be used as a mandate
   to require a TTML2 implementation
   ... to operate in a bug-for-bug compatible way with TTML1?

   Pierre: W3C doesn't compel implementors to do anything. Given a
   TTML1-only syntax document,
   ... the processors should not yield a different outcome on
   those features that they have in common.

   Glenn: I could accept a general objective - as soon as you
   start hinting at touching the
   ... conformance section the answer is no.

   Pierre: So do you agree on the objective of making TTMl1 and
   TTML2 consistent on the
   ... features they share?

   Glenn: Yes, and we can add that language.

   Andreas: Yes, that should be a clear objective. It is also
   important to say in the text that
   ... a TTML1 document containing only TTML1 syntax, then this
   applies, but that if TTML2
   ... syntax is present then the outcome may be different.

   David_Ronca: What's a document that shares TTML1 and TTML2?

   Pierre: No, the document would contain only features in common,
   i.e. TTML1 syntax.

   Andreas: [has to drop off]

   Cyril: Maybe a different perspective to the question: in terms
   of implementation, how do
   ... you translate your design goal? To minimise the overhead of
   implementing both TTML1
   ... and TTML2, or further, to reuse exactly the TTML1
   implementation for a TTML2 renderer.

   Pierre: That's not what I had in mind, though it would be
   awesome if one could do the latter.

   Cyril: In the worst case scenario, if I have an implementation
   that switches based on
   ... document type then it won't make any difference.

   Pierre: The goal is to avoid completely different tests, code
   paths, authoring tools etc. We're
   ... trying to make it easier for people with a limited amount
   of resource.

   SUMMARY: General agreement that there should be compatibility
   where possible, and that this may be achieved in practice by
   publishing TTML1 Third Edition being made compatible with TTML2
   where practical.

   Cyril: A practical question: did this begin with a question
   about the processing rules for tts:disparity present in an IMSC
   1.0.1 document?

   Glenn: It's not simply a matter of the document using TTML1
   features only, so we need to handle
   ... more generally which rules to follow.

   Mike: It is complicated, but we need to be clear, so if e.g.
   ATSC adopts one or two TTML2
   ... features into TTML1-based IMSC 1.0.1 we need to be sure
   that the act of doing that
   ... doesn't cause things to behave differently.

   Cyril: We could avoid this issue by back-porting the feature to
   ... Apparently it doesn't require any other changes in TTML2.

   Pierre: Conceivably we could create IMSC 1.0.2 to solve

   Glenn: We cannot add it to TTML1.

   Cyril: OK that's fine.
   ... Are there any other features coming from TTML2 that may
   land in IMSC?

   Mike: ATSC may adopt luminanceGain.

   Cyril: That would be a path to at least solve that issue

   Pierre: We could follow the same path as fillLineGap in IMSC
   1.0.1, by creating 1.0.2

   Mike: If that solves the problem it'd be fine.

   Nigel: This feels like the moment to mention that factoring out
   the style attributes into a
   ... separate specification altogether might be quite helpful,
   separate from the other spec
   ... semantics.

   Mike: Someone needs to draft the text that reflects this

   Nigel: For the TTML2 spec?

   Mike: I think that's the target.

   Nigel: Glenn?

   Glenn: I'll draft something and send it to the list for

   Nigel: I'm happy to look at that and try to make sure it
   reflects this discussion.

   Mike: [needs to drop off the call]



   <trackbot> action-507 -- Nigel Megitt to Add imsc vnext repo to
   agenda, board, github-bot etc -- due 2017-10-05 --


     [25] http://www.w3.org/AudioVideo/TT/tracker/actions/507

   Nigel: That's all done, and the TT board has been updated, so

   close action-507

   <trackbot> Closed action-507.

   Nigel: Now what about the FPWD of IMSC 1.1?

   Pierre: It's ready to go.

   Thierry: There are a couple of issues to discuss offline.

   Pierre: The pub-rules checker said it was okay.

   Thierry: I'll send you what I've found, and then request
   publication for the 17th.


     [26] https://github.com/w3c/imsc/blob/IMSC1.1/imsc1/spec/ttml-ww-profiles.html


     [27] https://rawgit.com/w3c/imsc/IMSC1.1/imsc1/spec/ttml-ww-profiles.html

   Nigel: Last week we made the proposal to publish this. Any

   Cyril: No objection, but I did raise a few issues on the
   document, mostly trying to clarify
   ... the relationship between this IMSC version and the previous
   one. It's important that
   ... people understand with simple communications what are the
   ... Pierre has responded to the issues.

   RESOLUTION: TTWG agrees to publish FPWD of IMSC 1.1


   <trackbot> action-509 -- Pierre-Anthony Lemieux to Propose
   liaison text for the imsc 1.1 fpwd -- due 2017-10-12 -- OPEN


     [28] http://www.w3.org/AudioVideo/TT/tracker/actions/509

   [29]Proposed liaison text re: IMSC 1.1 FPWD

     [29] https://lists.w3.org/Archives/Public/public-tt/2017Oct/0087.html

   Thierry: Who do we want to send this to? Should we use the same
   list as for the wide review?

   Pierre: Same as the IMSC 1.0.1 WR I would say.

   Thierry: Okay I will dig into that and come up with the list.

   Pierre: There's an MPEG meeting the week after next so it's
   important to send this soon.

   Thierry: I will update the drafts and send the final one after

   Nigel: I notice there's a deadline for comments - why is that?

   Pierre: It's arbitrary, just seems like a good idea.

   Nigel: This isn't a call for wide review so I don't think it's
   a good idea to set a deadline for
   ... comments but it would be good to indicate the proposed

   Cyril: +1

   Pierre: What about Wide Review in January?

   Nigel: Why not!

   Pierre: We could just notify that we've started work and invite

   Nigel: Perfect.

   Cyril: Yes, what about just dropping the "by 13 December 2017"

   Nigel: +1

   Pierre: I'll fix the "submits" typo too.

   Nigel: I'll take the action to update this and respond.

   Pierre: OK great.

   <cyril> [30]https://github.com/w3c/imsc/issues/263

     [30] https://github.com/w3c/imsc/issues/263

itts:fillLineGap is unclear about what it is filling between exactly

   github: [31]https://github.com/w3c/imsc/issues/263

     [31] https://github.com/w3c/imsc/issues/263

   Pierre: Were you happy with the renders Nigel?

   Nigel: Yes I think so.

   Pierre: My proposal is not to make any normative changes in
   IMSC 1.0.1 but to add
   ... informative text and those examples, as well as maximising
   the chances of using
   ... roll-up harmoniously with fillLineGap, would resolve this
   ... It was not completely intuitive to me, but since
   fillLineGap didn't exist before, just saying
   ... how to use it should work.

   Cyril: Nigel you said line areas can be generated without

   Nigel: Yes, line areas can be generated by line wrapping.

   Pierre: I agree with your interpretation Nigel, by the way.

   SUMMARY: @palemieux to attempt to exemplify this without
   substantive changes.

What fillLineGap does/ affects #254

   github: [32]https://github.com/w3c/imsc/issues/254

     [32] https://github.com/w3c/imsc/issues/254

   Pierre: I didn't understand this, but maybe the new examples
   for #263 will help.

   Nigel: Maybe!
   ... I didn't understand either.

   Pierre: If we get to a point ready to move past CR we will need
   to ping @r12a.

   Cyril: A side comment - for rubys in TTML2 would fillLineGap

   Glenn: The presentation of the ruby is an annotation on a line
   area effectively so it would
   ... be simply covered by the line gap as well. The height of
   the line gap would be predicated
   ... on the height of the line area, which would in turn be
   predicated on any annotations and
   ... the space that they need.

   Cyril: Would the line gap between the ruby and the base text be
   filled by fillLineGap?

   Glenn: Yes it's part of the line area already. It's a bit like
   the dot on an i.

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

   github: [33]https://github.com/w3c/imsc/issues/253

     [33] https://github.com/w3c/imsc/issues/253

   Nigel: I see you asked @r12a a question, @palemieux, so I think
   we're just waiting for that.

   Pierre: That's right.

TTML2 Wide Review Issues

SMPTE backgroundImage annotation #460

   github: [34]https://github.com/w3c/ttml2/issues/460

     [34] https://github.com/w3c/ttml2/issues/460

   Nigel: [describes call from yesterday that generated this

   Glenn: If we're talking about an informative note I don't see
   any issue there.

   Nigel: Yes that's it.

   Glenn: I'd probably say something like it's motivated by
   smpte:backgroundImage and
   ... extended to make it more compatible with ... whatever.

   Pierre: It's more than that.

   Glenn: It is, yes.

   Pierre: I think what Nigel said is it's important to state

   Glenn: It goes beyond smpte:backgroundImage

   Pierre: But there's a mapping from smpte:backgroundImage.

   Glenn: Yes that would be fine.

   Nigel: Yes that's a fair representation of the proposal.
   ... I think we need to say something like "The semantics of the
   ... attribute may be achieved by [whatever the equivalent is]".

   Glenn: Recall that there are two mechanisms in TTML2 -
   backgroundImage and image,
   ... serving different purposes, one for content, the other for
   background styling.
   ... In effect backgroundImage in SMPTE was ambiguous about
   whether it was for content
   ... or styling - I suspect both, but mainly for content.

   Nigel: I think it is clear it's for content.

   Pierre: It is intended to be content, that's established.

   Glenn: It's not stated in the SMPTE spec.

   Nigel: I thought you weren't supposed to have text in an
   element with backgroundImage,
   ... which settles it for me - worth checking though.

[HTML5] reference should be informative. #461

   github: [35]https://github.com/w3c/ttml2/issues/461

     [35] https://github.com/w3c/ttml2/issues/461

   RESOLUTION: HTML5 needs to be made an informative reference in

[SSML] reference should be informative. #462

   github: [36]https://github.com/w3c/ttml2/issues/462

     [36] https://github.com/w3c/ttml2/issues/462

   RESOLUTION: SSML needs to be made an informative reference in

[WEBAUDIO] reference should be informative. #463

   github: [37]https://github.com/w3c/ttml2/issues/463

     [37] https://github.com/w3c/ttml2/issues/463

   Nigel: The normative status of WebAudio may change in the
   future but we can make it
   ... informative for now I guess.

   RESOLUTION: WEBAUDIO needs to be made an informative reference
   in TTML2.

[XML 1.1] reference should be removed. #464

   github: [38]https://github.com/w3c/ttml2/issues/464

     [38] https://github.com/w3c/ttml2/issues/464

   RESOLUTION: No use is made of the XML 1.1 reference so remove

Examples in section S use an unusual tts:displayAlign setting #459

   github: [39]https://github.com/w3c/ttml2/issues/459

     [39] https://github.com/w3c/ttml2/issues/459

   Glenn: That's a simple fix.

   Nigel: Yes, I commented in support of this on the TTML1 issue

   RESOLUTION: Add tts:displayAlign="after" to examples.

Examples in section O use an unusual tts:displayAlign setting #254

   github: [40]https://github.com/w3c/ttml1/issues/254

     [40] https://github.com/w3c/ttml1/issues/254

   RESOLUTION: Add tts:displayAlign="after" to examples.

Question about #background-color vs #backgroundColor. #455

   github: [41]https://github.com/w3c/ttml2/issues/455

     [41] https://github.com/w3c/ttml2/issues/455

   Glenn: I can see that the two feature designators could be
   confusing. The background-color
   ... was added in TTML2. Pierre has pointed out that
   backgroundColor includes the same
   ... things as background-color pulled in, namely the block,
   inline and region versions. I think
   ... the resolution is to remove background-color and possibly
   add some text to #backgroundColor
   ... to say that it includes those as well, informatively.

   Pierre: In TTML1 did #backgroundColor include those three

   Glenn: Yes by implication but not explicitly.

   Pierre: That was my conclusion too. In that case I would file
   an issue in TTML1 to make
   ... that explicitly.

   Glenn: I would do this as a note in TTML2 and TTML1.

   RESOLUTION: Remove #background-color and add an informative
   note that it includes block, inline and region and raise an
   issue to do the same on TTML1 Third Edition.

Examples in section S use an unusual tts:displayAlign setting #459

   github: [42]https://github.com/w3c/ttml2/issues/459

     [42] https://github.com/w3c/ttml2/issues/459

   Pierre: It would be good to change the examples also to put the
   timing on spans rather than p elements, in S.2

   Nigel: +1

   Pierre: That might avoid people adding fillLineGap in a copy of
   the example and not understanding
   ... why it doesn't work!

   Nigel: Agreed.

   RESOLUTION: In S.2 Modify the example to put the timing on span
   elements and separate lines with `<br/>` inside those timed

Meeting round-up

   Glenn: Next week I'd like to talk about TTML2 issues #437,
   #438, #439 and maybe #435
   ... and possibly a couple of others that are editorial fixes.

   Nigel: Yes, I'd like to tackle some TTML issues next week.

   Glenn: We could also discuss #428 and #429 which are about
   activeArea and fillLineGap
   ... making them the same as IMSC 1.0.1
   ... Then the other question in my mind is what we do with

   Pierre: That's my proposal. I don't disagree that it's
   unfortunate. In the future we can
   ... maybe add new things directly into TTML2.

   Glenn: Another possibility is in 1.0.2 change to tts:

   Pierre: It would break implementations that look for the
   existing namespace.
   ... This is less than ideal, but it will cause the least amount
   of pain overall for implementers
   ... and users.

   Glenn: I'm not suggesting that we have a reference from TTML2
   to IMSC, but that we
   ... incorporate the syntax identically and the prose to the
   extent that we can.

   Pierre: I agree with that proposal.

   Glenn: Nigel where are we with #427?

   Nigel: I've made a lot of progress - the umbrella issue is
   #406, and #427 lays the structural
   ... groundwork, and that's done in the issue-0406- branch..

   Glenn: I would prefer to make the table row say "Derivation:".

   Nigel: Okay, when you see it, it might make sense. I'll remove
   the "(informative)" though.
   ... Thanks everyone [meeting adjourned]

Summary of Action Items

Summary of Resolutions

    1. [43]TTWG agrees to publish FPWD of IMSC 1.1
    2. [44]HTML5 needs to be made an informative reference in
    3. [45]SSML needs to be made an informative reference in
    4. [46]WEBAUDIO needs to be made an informative reference in
    5. [47]No use is made of the XML 1.1 reference so remove it.
    6. [48]Add tts:displayAlign="after" to examples.
    7. [49]Add tts:displayAlign="after" to examples.
    8. [50]Remove #background-color and add an informative note
       that it includes block, inline and region and raise an
       issue to do the same on TTML1 Third Edition.
    9. [51]In S.2 Modify the example to put the timing on span
       elements and separate lines with `<br/>` inside those timed

   [End of minutes]

    Minutes formatted by David Booth's [52]scribe.perl version
    1.152 ([53]CVS log)
    $Date: 2017/10/12 16:44:14 $

     [52] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [53] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 12 October 2017 16:47:50 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 12 October 2017 16:47:50 UTC