- 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]W3C
[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
Attendees
Present
Nigel, Pierre, Thierry, Glenn, Mike, Cyril, David_Ronca
Regrets
None
Chair
Nigel
Scribe
nigel
Contents
* [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
IMSCvNext
... And we have had some other issues raised this week on
TTML1/2.
Mike: Request to cover backward compatibility issue in TTML
Nigel: Ok
... I'm not expecting David to join to discuss WebVTT review
today.
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
related.
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
behaviour?
Pierre: This is only for features that TTML1 and TTML2 have in
common.
... 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
TTML1.
Cyril: If it's ambiguous in TTML1 then noone can interoperably
implement it in TTML1.
Pierre: This is core, basic things like lineHeight style
inheritance.
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
inheritance.
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
implementers.
Pierre: I agree with you Cyril, we should make it work
consistently.
... 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.
<pal>
[24]https://github.com/w3c/ttml2/issues/458#issuecomment-336022
891
[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
specification."
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
TTML1.
... Apparently it doesn't require any other changes in TTML2.
Pierre: Conceivably we could create IMSC 1.0.2 to solve
disparity.
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
practically.
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
discussion.
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
discussion.
Nigel: I'm happy to look at that and try to make sure it
reflects this discussion.
Mike: [needs to drop off the call]
IMSC
action-507?
<trackbot> action-507 -- Nigel Megitt to Add imsc vnext repo to
agenda, board, github-bot etc -- due 2017-10-05 --
PENDINGREVIEW
<trackbot>
[25]http://www.w3.org/AudioVideo/TT/tracker/actions/507
[25] http://www.w3.org/AudioVideo/TT/tracker/actions/507
Nigel: That's all done, and the TT board has been updated, so
closing.
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.
<pal>
[26]https://github.com/w3c/imsc/blob/IMSC1.1/imsc1/spec/ttml-ww
-profiles.html
[26] https://github.com/w3c/imsc/blob/IMSC1.1/imsc1/spec/ttml-ww-profiles.html
<pal>
[27]https://rawgit.com/w3c/imsc/IMSC1.1/imsc1/spec/ttml-ww-prof
iles.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
objections?
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
differences.
... Pierre has responded to the issues.
RESOLUTION: TTWG agrees to publish FPWD of IMSC 1.1
action-509?
<trackbot> action-509 -- Pierre-Anthony Lemieux to Propose
liaison text for the imsc 1.1 fpwd -- due 2017-10-12 -- OPEN
<trackbot>
[28]http://www.w3.org/AudioVideo/TT/tracker/actions/509
[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
publication.
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
timeline.
Cyril: +1
Pierre: What about Wide Review in January?
Nigel: Why not!
Pierre: We could just notify that we've started work and invite
contributions.
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
#263
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
issue.
... 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
`<br>`s?
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
apply?
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
issue]
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
equivalence.
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
smpte:backgroundImage
... 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
TTML2.
[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
TTML2.
[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
it.
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
too.
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
things?
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
spans.
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
namespaces...
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:
namespace?
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
TTML2.
3. [45]SSML needs to be made an informative reference in
TTML2.
4. [46]WEBAUDIO needs to be made an informative reference in
TTML2.
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
spans.
[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