- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 3 May 2018 15:45:53 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <D710ED05.5B3F8%nigel.megitt@bbc.co.uk>
Thanks all for attending today's TTWG meeting. Minutes in HTML format can be found at https://www.w3.org/2018/05/03-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
03 May 2018
See also: [2]IRC log
[2] https://www.w3.org/2018/05/03-tt-irc
Attendees
Present
Philippe, Andreas, Cyril, Glenn, Mike, Pierre, Nigel
Regrets
Thierry
Chair
Nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]This meeting
2. [5]TTWG Charter
3. [6]TTML1
4. [7]Clarify default value of blur radius ttml1#351
5. [8]TTML2
6. [9]TTML2 publication dates
7. [10]TTML2 textShadow direction
8. [11]IMSC
9. [12]IMSC publication milestones
10. [13]IMSC vNext Requirements
11. [14]WebVTT
12. [15]IMSC vNext Reqs license
13. [16]Meeting Close
* [17]Summary of Action Items
* [18]Summary of Resolutions
__________________________________________________________
<scribe> scribe: nigel
This meeting
Nigel: TTWG Charter, TTML1, TTML2, IMSC, IMSC vNext
Requirements, that's about all I'm expecting.
... Any particular topics to cover, or other business?
Pierre: Specifically on TTML2 it would be good to discuss
schedule for CR2 because that
... will also drive the schedule for IMSC 1.1 CR2.
Nigel: Yes, we discussed that recently but let's return to it.
Pierre: Admin q re IMSC "master"
Nigel: OK let's bring that to the IMSC agenda item.
TTWG Charter
Nigel: I'm not aware of any development on the two open issues
over the last week.
Philippe: Nothing more - I'm aware of the decision timeline
issue Nigel raised and the
... timeline before CR that Pierre raised. Otherwise we are on
track.
... Pierre you might want to look at the alternative proposal
that Nigel made on GitHub, either
... now or offline. I just want to close the loop by May 17.
Shall we try offline and if necessary
... discuss it.
Pierre: Nigel, what was your end point?
Nigel: I was really trying to address all the concerns raised
in the issue thread with a solution
... that might meet everyone's needs, so I'd be happy with it
as is, or with the optional parts
<plh> -->
[19]https://github.com/w3c/charter-timed-text/issues/28
[19] https://github.com/w3c/charter-timed-text/issues/28
Nigel: (though both the optional parts would be needed)
... [describes the issue comment and rationale]
Pierre: The minimal change would be to change the must to a
should.
Nigel: OK
Pierre: I also really want to prevent people thinking they have
3 months before making comments.
Philippe: Alright, I'll open a pull request to track the
changes we're looking at making.
Nigel: A question for you Philippe, if the call for review has
comments asking for these
... issues to be resolved, are you able to make the changes
without going round a new
... review cycle?
Philippe: Yes, we would not need another review cycle.
... As it is I'm expecting to get approval for the new Charter
after the AC meeting in May.
... I'll create a pull request and put Nigel and Pierre as a
reviewer - others interested can
... ping me or follow the pull request.
TTML1
Nigel: I'm not aware of any issues to discuss. Obviously we
will need some work for the
... implementation report.
Philippe: Did I start work on superseding TTML1?
Pierre: You mean for IMSC?
Nigel: I think TTML1 3rd Ed superseding 2nd Ed?
Philippe: That did happen automatically.
Nigel: OK let's return to the IMSC superseding at the IMSC
agenda topic
<plh> [20]https://www.w3.org/TR/2013/REC-ttml1-20130924/
[20] https://www.w3.org/TR/2013/REC-ttml1-20130924/
Philippe: Because you followed the revised Rec process, by
publishing the CR you automatically
... outdated the previous version which was the Rec.
Nigel: The implementation report page is currently empty of
tests.
[21]TTML1 3rd Ed Implementation Report
[21] https://www.w3.org/wiki/TTML1-3ED_implementation_report
Pierre: This is on my to do list (to contribute tests generated
in the course of IMSC work)
Nigel: OK thanks
Clarify default value of blur radius ttml1#351
Nigel: One issue was raised recently, to clarify the default
value of blur radius
... Just to check, are we in agreement that the default value
of blur radius should be zero?
Glenn: That's what it is in practice, it was just an omission
that we did not specify that.
github: [22]https://github.com/w3c/ttml1/issues/351
[22] https://github.com/w3c/ttml1/issues/351
RESOLUTION: WG agrees the default blur radius is zero, and it
should be clarified.
github-bot, end topic
TTML2
action-443?
<trackbot> action-443 -- Glenn Adams to Prepare a document
showing mapping arib ruby extension features to ttml2 for use
as a liaison document to arib. -- due 2018-04-26 -- OPEN
<trackbot>
[23]http://www.w3.org/AudioVideo/TT/tracker/actions/443
[23] http://www.w3.org/AudioVideo/TT/tracker/actions/443
Glenn: I'd like to push out the due date to approximately CR2
publication date.
... Say mid-late June.
... By the way that is my working target for CR2 right now, for
publication, which means
... having it for the group around 1st June.
Nigel: I've updated the due date for action-443 to 15th June.
Glenn: Thank you.
TTML2 publication dates
Glenn: I used Philippe's tool to check on schedules and,
originally, I was hoping for
... completion earlier than is now going to be possible
according to that tool.
... To get to Rec by August 1st would require CR2 publication a
week from today, which is
... not possible. So if I push it out a bit and try to get to
PR by August 1st then that would
... be a publishing date of June 26 for CR2.
Philippe: That goes to August 7 for publication
Glenn: I put in a date for PR and it came back with June 26.
Philippe: You could be right, will check.
Glenn: Or July 31st may be what worked.
<plh>
[24]https://w3c.github.io/spec-releases/milestones/?pr=2018-07-
31&noFPWD=true
[24] https://w3c.github.io/spec-releases/milestones/?pr=2018-07-31&noFPWD=true
Philippe: June 19 CR2 for July 31 PR (for publication)
Glenn: We need CR2 around 3rd week June for CR2.
... So I think that's feasible though aggressive. I'm going to
be full time on TTML2 starting
... Monday, so I'll get a lot of things done over the next few
weeks and try to drive to a
... reviewable copy of the document by end of May which would
give us a few weeks to get
... to a publishing date.
Philippe: You need a transition date of June 12 to publish on
June 19 and because you
... have a 10 day decision review period, you need the call for
consensus sent no later than
... June 2, which is a Saturday. So you need to decide to
publish CR2 on May 31.
Glenn: That gives 10 days review by the group after that.
Philippe: Yes
Glenn: It's definitely aggressive, but achievable. The issues
are fewer and less complicated
... than what we dealt with in the ramp up to CR1.
Cyril: Glenn, as a 2nd Editor I can offer to edit if it speeds
the process, or to offer an Editors
... meeting if we need, to speed up the editing. Let me know if
you need that. Any others
... could join also.
... Secondly, solving all the issues for CR is one thing, but
if we get more implementation
... feedback that requires substantive changes we may need a
CR3.
Glenn: We can remove at risk features in PR directly.
Cyril: We should encourage implementation feedback soon to
reduce that risk.
Glenn: We're seeing implementation activity, but I think tests
would be helpful, so one of
... my priorities is to start pushing tests to match the
features.
... I need to take action on that quickly.
Nigel: +1
Glenn: I have a fairly large suite of validation and
presentation tests so we'll get those
... posted starting next week.
... Then additional tests may be needed and I expect more to be
added as we drive to CR2.
Nigel: Will we put the tests in the ttml2 repo or in a separate
one?
Glenn: I plan to put them in the ttml2 repo like we did with
ttml1
Nigel: Should we raise an issue per feature for adding the
test?
Glenn: Please no
Cyril: Too many issues
... We can list them on a wiki page with a table so we can see
progress.
Glenn: I don't mind an umbrella issue.
Nigel: I'm not going to force it, but I think you're missing an
opportunity to track work in
... a better way, with a pull request for each test being
added.
Glenn: I expect a big batch to be submitted. After that, then
per test type issues might work.
Nigel: OK
... Thanks for the editor's meeting offer Cyril, if you do go
ahead with that please let
... us know so if anyone wants to dial in then they can.
TTML2 textShadow direction
github: [25]https://github.com/w3c/ttml2/issues/723
[25] https://github.com/w3c/ttml2/issues/723
Pierre: Just to explain how I found this issue and why I raised
it...
... TTML2 tts:textShadow allows multiple shadows to be created
and each shadow has a
... positional offset with respect to the text. That offset as
it stands today is not specified
... with respect to horizontal and vertical, but relative to
the block and inline progression directions,
... the writing mode. That came as a surprise to me for a
couple of reasons.
... 1. It doesn't match what CSS does, and I was mislead by the
spec saying it does match CSS.
... On careful review I realised that is not the case.
... That's not necessarily fatal, but it is surprising and a
pain.
... 2. The shadow direction seems completely unrelated to the
writing direction from an
... aesthetic perspective. At a high level I would expect it to
be placed the same for all text
... on view regardless of the direction of writing. As it
stands today you'd have to create
... different styles to deal with the different writing modes,
if they are mixed in a document.
... 3. writing direction needs to be propagated when computing
the shadow so you know
... which actual absolute offset needs to be calculated. In
TTML1 only padding had that
... characteristic, but it only applied to padding, so it was
only a little awkward. This is more
... awkward. For all those reasons I thought it was surprising.
Also border-radii is like this.
... To me, those properties are unrelated to the writing
direction, so I want to discuss if we
... really want to do this in TTML2.
Glenn: My only surprise is that Pierre is surprised, for a
couple of reasons.
... 1. propagation of writing mode - that is true for other
reasons than textShadow, for example
... every paragraph needs to use writing mode to determine the
default directionality for bidi
... and in general bidi resolution requires propagation of
writing mode down the tree. That's
... a presupposition of XSL-FO implementations, for example.
Pierre: That's propagated through tts:direction which is
inherited so it is not comparable.
Glenn: We can dispute that separately.
... 2. text-shadow in CSS and other word processing programmes
and captioning systems
... in the field (that I'm familiar with) treat it as a
typographic effect not an image processing
... effect. Pierre's comments are relevant if you think of it
in terms of a shadow deriving from
... a light source shining on the root container. On that basis
then Pierre has a good argument.
... My contention is that text shadow like text outline, font
style etc is a typographic property
... and is specific to individual text not globally applied.
... 3. One reason we are different from CSS, not just here, is
we followed XSL-FO to make
... use of writing mode relative properties for directional
semantics, which we did consistently
... across the board. CSS did not do that from the beginning.
We consciously and explicitly
... in early TTML days made the decision to use writing mode
relative properties. This is
... not different in any way from my perspective.
... We could make an exception in this case and do something
different. That would require
... authors to think about it and implementers too.
... Pierre's arg is that the difference with CSS creates
confusion. I'm more interested in
... maintaining internal consistency with TTML than with
semantic consistency with CSS.
Cyril: To clarify, how would an author create the second
example with the current spec?
... How do you produce the right hand image in the issue?
Pierre: Just change the 10% to -10%.
... The author needs a different style for tblr vs tbrl.
Andreas: Two questions. 1. The pictures you're showing - the
left one for vertical text,
... is this how text shadows should be applied?
Pierre: My understanding is the left image is how it would
apply.
Glenn: That's how it would look today on a word processor that
does shadows.
... A positive offset for the tbrl line would be the standard
positive interpretation of offset.
... It is offset from the before to the after direction of the
line. And towards the end in this case.
Andreas: 2. Pierre, so what is the alternative or the counter
proposal?
Pierre: To do what CSS and XSL do, to calculate the offset
always wrt the horizontal and vertical
... directions. Positive vertical is towards the bottom and
positive horizontal is towards the right.
Andreas: What is the negative impact of Pierre's proposal? If
it is closer to CSS, that is also
... the direction we want to go.
Glenn: [reviewing the XSL, which was based on the CSS2
definition]
... I guess I was incorrect and Pierre has pointed that out,
thinking that it was writing mode
... relative in XSL but it looks like they did not make that
change there, unlike border and padding and some other things.
... So there's an argument to be made for consistency with XSL
we should do as suggested
... by Pierre. The impact is minimal at this stage of
implementation. Pierre is probably
... further ahead in terms of presentation implementation. If
we leave as is then we need
... at least a note pointing out this issue and warning the
reader of it. If we adopt Pierre's
... position we also need a note for those who assume the
current way.
... I would not object to following XSL and CSS and making it
non-writing-mode relative.
Nigel: Does anyone prefer the current approach?
Glenn: I prefer it because there's less editorial work. We
should also look at border-radii
... as well.
Cyril: I checked the text, and only border-radii is affected.
... Is any other property dependent on writing mode?
Glenn: Padding maybe?
Pierre: The ship has sailed on padding, I'm not suggesting a
change there.
Cyril: I would agree with changing border-radii also.
Glenn: border-radii is not in XSL. It was introduced in CSS3.
Cyril: There's font shear but it makes sense to link that to
writing mode.
Pierre: Everything else is text related it seems that border
radii is the only one.
Glenn: I reviewed this yesterday and was surprised there were
not more places where
... writing mode relative directions are referred to. Nowhere
do we call out the set of
... properties that are writing-mode relative. Under the
definition of writing mode it might
... be useful to add an informative list pointing readers to
that, or as part of the prose.
RESOLUTION: Change tts:textShadow to be writing mode
independent
<inserted> .
RESOLUTION: Change border-radii to be writing mode independent
github-bot, end topic
IMSC
Nigel: We published [26]https://www.w3.org/TR/ttml-imsc1.1/ -
well done and thank you everyone!
[26] https://www.w3.org/TR/ttml-imsc1.1/
Pierre: Nigel can you approve the 1.1 CR pull request?
Nigel: Will do.
Pierre: I verified this is what has been published.
Nigel: Thank you I've just approved it on that basis.
Pierre: Thank you.
... We've just published IMSC 1.0.1 Rec and IMSC 1.1 CR so we
ought to decide which one
... should be master. Arguably we are working on 1.1 so it
makes more sense to have that as master.
Philippe: That's perfect timing, I'm currently writing a page
on errata management at W3C
... and I would like to use GitHub for that. Ideally what I'd
like to see Pierre is that you keep
... the master as 1.1 and a separate branch for 1.0.1 and use
labels to indicate errata for
... issues and pull requests.
Pierre: We already do that.
Philippe: I would like to be able to generate a page
automatically based on GitHub labels
... to indicate the errata for each publication, and not have
to update a separate page every time.
Pierre: So the end result is there will be 3 branches: master
(1.1), IMSC 1.0.1 and IMSC 1.0?
Philippe: We are about to supersede IMSC 1.0 - I sent the
transition request but didn't get
... it in front of the Director, so I'll do that today or
tomorrow and it should happen in a
... month or so. You can keep the branch but we should stop
tracking errata for IMSC 1.0
... at this point.
Pierre: That's good for me. Will errata reflect open pull
requests or issues with a label?
Philippe: That's what I'm planning to write.
Nigel: Seems like a good idea to me, and I think it answers
Pierre's question.
Philippe: I'm writing a separate document so I'd like your eyes
on it Pierre.
Pierre: Excellent. In the short term I'll arrange the branches
as we just discussed, and look
... out for that document.
... Thanks.
Nigel: Another approach on gh-pages would be to use CI to copy
the different branch versions
... to separate sub-folders and make the index page contain
links.
Pierre: Sounds super-complicated, we should just update the
github repo README page
Philippe: Would you like me to do that?
Pierre: Yes please do.
<plh> [27]https://www.w3.org/TR/ttml-imsc/all
[27] https://www.w3.org/TR/ttml-imsc/all
Pierre: The only other thing is I've started adding IMSC1.1
tests to the imsc-tests repo
IMSC publication milestones
Philippe: What is the milestone for IMSC? Is it linked to
TTML2?
Pierre: IMSC 1.1 should be published as a Rec on Oct 4.
Philippe: A month after TTML2?
Pierre: Yes. My goal would be to synchronise with TTML2 so
having a week or two between
... the two is reasonable. In my mind IMSC 1.1 schedule is
TTML2 + 2-3 weeks.
Philippe: OK
Pierre: What's good is IMSC 1.1 does not introduce any feature
not already in TTML2 and
... not also in IMSC 1.0.1, only constraints, so to the extent
that IMSC 1.0.1 Rec is already
... published and TTML2 will have a full set of tests, there's
minimal risk on IMSC 1.1 from
... a transition perspective. If TTML2 passes transition then
from a testing perspective there's
... no risk for IMSC 1.1.
... From an IPR standpoint for example the risk is all in
TTML2.
IMSC vNext Requirements
Nigel: I would like to defer publication pending some editorial
work.
Pierre: A good time would be after CR2 or with CR2 transition
because there may be some
... fine tuning needed especially with Ruby.
Nigel: Makes sense.
WebVTT
Philippe: I sent the transition request just now, so I'll get
the approval tomorrow, targeting
... publication on May 10 if everything goes well.
Pierre: What happened with the GitHub repo?
Philippe: The problem is it is used both by the CG and the WG
which is pretty unique in
... the consortium. I need to talk with Wendy on the best
course of action here.
Pierre: One simple solution is to fork and have an upstream
repo.
Philippe: I don't know, I wanted to get past the transition
request before checking with Silvia.
Pierre: I understand.
IMSC vNext Reqs license
Philippe: The IMSC vNext Reqs has the permissive licence - did
you mean to do that?
Pierre: That's an omission, I'm not sure if I care.
Nigel: I'm not sure if I care either.
... I don't think it's a bad thing to allow the world to be
able to take those requirements
... and reuse them as they see fit.
Pierre: Let's leave as is.
Philippe: If noone has a strong view, let's not change it.
Meeting Close
Nigel: That's all the agenda for today, thanks everyone.
[adjourns meeting]
Summary of Action Items
Summary of Resolutions
1. [28]WG agrees the default blur radius is zero, and it
should be clarified.
2. [29]Change tts:textShadow to be writing mode independent
3. [30]Change border-radii to be writing mode independent
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [31]scribe.perl version
1.152 ([32]CVS log)
$Date: 2018/05/03 15:44:41 $
[31] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[32] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 3 May 2018 15:46:25 UTC