See also: IRC log
<scribe> scribe: nigel
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.
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> --> 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.
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> 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.
TTML1 3rd Ed Implementation Report
Pierre: This is on my to do list (to contribute tests generated in the course of IMSC work)
Nigel: OK thanks
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: 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
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> 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.
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> 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.
github: 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
Nigel: We published https://www.w3.org/TR/ttml-imsc1.1/ - well done and thank you everyone!
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> 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
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.
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.
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.
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.
Nigel: That's all the agenda for today, thanks everyone. [adjourns meeting]