See also: IRC log
<scribe> scribe: nigel
Nigel: Agenda for today - I
suggest we go through TTML1, TTML2, IMSC vNext Reqs,
... IMSC 1.1, CSS actions. Will that work?
... Any other business or something to make sure we cover?
group: [silence]
Nigel: Okay let's go.
Nigel: I think the status is we are awaiting tests for the implementation report?
Pierre: Yes, no bandwidth to deal
with this recently. There are some changes made
... recently in TTML2 that should be backported to TTML1.
... The line stacking strategy text in TTML1 3rd Ed probably
needs fixing.
... I should raise an issue now...
... [raises issues on GitHub]
Nigel: Does that mean we need to make normative changes and aim for a TTML1 3rd Ed CR2?
Pierre: I don't know.
Glenn: Reminder that TTML2 CR2 references TTML1 2nd Ed and that's what I expect to go out the door with.
Nigel: Ooh.
Pierre: That goes back to the question of whether we reference a dated or undated version.
Nigel: My expectation was that
TTML2 would reference TTML1 3rd Ed, and the reason
... we are working on TTML1 3rd Ed is to reduce the delta to
TTML2.
Pierre: TTML2 #806 needs backporting to TTML1 3rd Ed. Clarify Meaning of Font Properties applying to a paragraph.
Glenn: We added some language in
TTML2 that documents that previously implicit
... usage of some style state data as an input to the line
height normal calculation.
Pierre: Do you think that's necessary to add to TTML1?
Glenn: It wouldn't hurt to add a note.
Pierre: That's TTML2 #785.
Nigel: There's clearly some work
to look at the backporting tasks and work out if anything
... substantive needs to change.
<scribe> ACTION: Pierre to look at TTML2 backporting to TTML1 3rd Ed to see if we can change the ref from TTML2 to point to 3rd Ed. [recorded in https://www.w3.org/2018/06/28-tt-irc]
<trackbot> Created ACTION-513 - Look at ttml2 backporting to ttml1 3rd ed to see if we can change the ref from ttml2 to point to 3rd ed. [on Pierre-Anthony Lemieux - due 2018-07-05].
Glenn: If that delays TTML2 going
to Rec that would be a problem. If TTML1 3rd Ed
... can be a Rec before TTML2 then that would be okay.
... Have we made any substantive changes to TTML1 3rd Ed
CR?
Pierre: No
Nigel: No
Glenn: That would mean we may be
able to make non-substantive changes in notes,
... which I would have no problem doing.
Nigel: Agreed.
Pierre: I thought you had said
that the TTML1 line height normal calculation text was
... wrong - if you have some time to look at this today that
would be great.
Glenn: It's my opinion you can
fix any semantic problem to some extent with an
... informative note as a fallback. Syntactic changes - that's
a problem. We have
... latitude on how we craft non-normative notes.
Nigel: That's a good call to action for looking at TTML1 3rd Ed again. Any more for TTML1?
Glenn: Pierre, when you published TTML1 3rd Ed CR did you tag it as a release?
Pierre: Yes, I did.
Glenn: Okay, good. I've just today created a release on TTML2.
Pierre: TTML1 3rd Ed CR1.
Nigel: Thierry thank you for your
work getting us to CR2 and your announcement to
... the group earlier today.
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-06-15 -- OPEN
<trackbot> https://www.w3.org/AudioVideo/TT/tracker/actions/443
Glenn: I will pick this up again, it's on my work list.
Nigel: Can we do this so we can send it before the deadline for comments has closed?
Glenn: Okay, make the deadline next week.
Nigel: [adjusts the action]
Glenn: By the way I will be absent 12-19 July.
Nigel: I will be absent from 10 August for 2 weeks.
Pierre: I will be absent from 15 August for 1 week.
Cyril: I will be absent in July except for 16-20.
Nigel: Glenn, I see you merged something into the ttml2-tests repo.
Glenn: Yes I started populating
tests from those that we produced for TTV. I've already
... switched TTV over to use the contents of that repo live so
whatever changes I'm making
... in the ttml2-tests repo will impact TTV in real time.
... I'm starting to go through the list of all the new features
in TTML2 and verifying that
... there are both positive and negative tests related to
validation. I'm focusing on
... validation tests to start with. It's going pretty quickly,
I'll probably get through that
... in the next week or two before I go on holiday. Then I'll
be populating it with
... presentation tests from TTPE and creating new tests as
well.
Nigel: That's good.
Glenn: Other people can begin to
review them. Until I give the signal that I've reviewed
... them all and tweaked them to check they're in a state
others can use you might not
... want to spend much time on it unless you're really
energetic. I wouldn't file issues
... against tests in there until I give the all clear
signal.
Nigel: Okay, then after that signal we should go into a more pull request controlled mode.
Glenn: That was my thinking, I
don't want the standard protocol yet while I'm
experimenting
... with the structural organisation etc.
Nigel: Is that okay with everyone?
group: [silence]
Nigel: OK let's proceed like
that.
... Thank you.
Glenn: I should mention I'm also updating TTV along the way to get it back in sync with TTML2.
Nigel: There have been some
updates on issues but there's nothing marked on the
agenda.
... There are no open pulls.
Glenn: I just closed CR2
milestone by the way.
... There are 8 issues open assigned to the PR milestone. 2 are
questions from Andreas
... that may only result in editorial clarification changes.
I'll be starting processing those
... probably today and put some pull requests in place if there
are editorial changes needed.
... I'd like to ask about the two issues assigned to Nigel that
are related to wide review.
Nigel: Yes, this is really bad of me not to have completed them.
Glenn: As far as I can tell they can be closed after the memos have been drafted.
Nigel: The memos need sending
too.
... I'm aware, I just haven't got around to them. I may be able
to manage them on
... Thursday morning next week before this meeting.
... By the way they are ttml2 #443 and #460.
... Anything else for TTML2?
Cyril: I've started looking at
the wiki page for the TTML2 implementation report but it
... is hard to edit with 200 features so I started doing a
spreadsheet. The idea is to
... fill that in first and then when we're confident it won't
change too much we can
... convert it to a wiki page for the report. I'm still in the
process of building that for
... Netflix.
Glenn: Its a Google docs
spreadsheet.
... I'm sharing it with Nigel and Pierre at the moment. Should
I add Andreas too?
Nigel: Yes, and Thierry too please.
Glenn: Right now there are four
or five colums, two for TTPE and TTVE and similarly for
... Netflix internal implementations and a penned-in IMSC.js
column in case Pierre is
... likely to implement any TTML2 features even in the context
of IMSC 1.1
Nigel: Sounds good, I'll review offline.
Cyril: I just shared it.
... It's to make it more convenient for editing especially at
the beginning.
Glenn: By the way in that
spreadsheet all the TTML1 feature rows are present for
... completeness but hidden.
... I'm going down the TTV column and updating it as I verify
test suite materials so I
... expect there to be quite a bit of updating going on over
the CR2 period?
Cyril: Can you put the legend of the colours somewhere?
Glenn: Yes I'll do that.
... Right now the TTV cell has information on the colours.
Nigel: Thank you all, that sounds like good progress.
Pierre: We need to decide on blurred for text shadow.
Nigel: If we can look at rw and rh too that would be good.
github: https://github.com/w3c/imsc-vnext-reqs/issues/27
Nigel: Last time we discussed I
was going to look for supporting use cases and I haven't
... had chance to do that yet, which is not ideal.
Pierre: It's supported by CSS and
in the worst case an implementation that does not
... support it can not use it and the fallback is not so bad.
This was more for completeness
... to match textOutline. If there's any doubt I would close
this issue and move on.
Nigel: Makes sense to me, close with no change because textShadow blur is currently permitted.
Pierre: Yes, I don't have any data point that says it is a huge burden to implement.
Nigel: It's not the same functionality as blur on textOutline.
PROPOSAL: Close this issue with no change.
Nigel: Any other views?
Pierre: I think it is enough
justification that one member thinks it would be useful and
that
... there is a small implementation burden.
RESOLUTION: Close this issue with no change.
github-bot, end topic
Nigel: I've closed the pull request too.
github: https://github.com/w3c/imsc-vnext-reqs/issues/30
Pierre: I've implemented
space-around in imsc.js and it works in the sense that it is
no
... worse than any other alignment feature, in that only
Firefox supports it properly.
... Supporting space-around is no harder than supporting
center.
... I've received feedback from Japanese contacts that
space-around is a must so my
... recommendation is to add it.
Nigel: Any counter-views?
Cyril: When you say "supported" I
think at least in CSS it has the capability to do spacing
... on the base text also so if the ruby annotation is bigger
than the base text then the
... spacing is added to the base text. Is that something you
support?
Glenn: That behaviour is
implementation dependent in TTML2 at the moment. We don't
... say what an implementation should do at this point.
Pierre: I did not try that but I can try it right now.
Cyril: I don't know if this is the right behaviour but the CSS spec has diagrams showing that.
Pierre: No, it doesn't happen in
Firefox I don't think.
... Oh no, it does add spacing, that's correct.
... We could put it as at risk. I'm told under no uncertain
terms that when the base text
... is long and the narrow ruby annotations then not having
space-around is bizarre.
Cyril: I'm fine with that.
PROPOSAL: Support `tts:rubyAlign="spaceAround"` in IMSC v1.1
Nigel: Any objections?
RESOLUTION: Support `tts:rubyAlign="spaceAround"` in IMSC v1.1
github-bot, end topic
github: https://github.com/w3c/imsc-vnext-reqs/issues/33
Nigel: I think the trade-off here
is between implementation cost and the strategic
... advantage of adopting rw and rh which should help remove
some sources of errors.
Cyril: We have reviewed this and would like support for rw and rh.
Pierre: On everything or only on fontSize?
Cyril: Certainly on fontSize.
Pierre: What about extent, position, origin, lineHeight...
Cyril: 3 buckets:
... 1. Exactly as % - extent, origin, position - just replace %
with rw/rh.
... 2. Those related to fontSize - lineHeight, linePadding,
rubyReserve, textOutline, textShadow.
... - that bucket should be the same as fontSize.
... 3. padding - where % is related to the region size.
... 4. the position property - I tried to look at the spec to
understand how those units
... would work and had an email exchange with Glenn. What
confuses me is that the
... tts:position does not mention rw and rh units and all the
semantics and diagrams
... use %. If you follow the position type then you find
mention of the rw and rh units
... but it's not clear how it works.
Nigel: Is it clear to you how a pixel value would work?
Cyril: No, anything other than % is unclear.
Glenn: This goes back to how
XSL-FO documents units, and they only called out
... % because it's the only one that is contextual.
... The problem is not the interpretation of %, but the
intepretation of the position
... property at all. I only understand it with the diagram that
uses %, and it's the same
... value. What does a fixed length value mean?
... If it is pixels then, say, a "top 10px" ...
Nigel: I know what you mean, is
it positioning the top of the box by 10px or something
... inside the box.
Pierre: For me it is offsetting the named edge.
Glenn: You have to take the size
of the reference enclosing region and the height of
... the object being positioned and 10px would be offset from
the remaining difference.
Pierre: That's not what I have today.
Glenn: In other words a zero
value always aligns the top of the thing being positioned
... with the top of the enclosing region.
... It doesn't allow you to move the positioning thing outside
the enclosed region.
Nigel: The spec for this is CSS.
Glenn: The original language in
TTML2 was lifted from CSS3 Backgrounds and Borders
... with some text.
Cyril: A diagram for absolute length based positioning would help.
Pierre: I think that's a good
idea.
... Just to confirm an offset in pixels from the bottom would
be...
... Imagine an offset in pixels from bottom. To compute the
position of the top of the
... object you subtract from the height of the containing box
the height of the object and
... the offset.
Cyril: Ok
Nigel: So if you say bottom 0px then you'd subtract nothing.
Pierre: that's correct, the top
position would be the height of the root container minus
... the height of the object so the bottoms would be
aligned.
Nigel: Okay then that
understanding helps with rw and rh because they are
effectively
... absolute units in this context.
Pierre: That's right.
Cyril: Is it the right time to
open an editorial issue on TTML2 showing the postioning
... with absolute units?
Glenn: Perhaps we just need an informative note.
Nigel: This is different.
Glenn: We already have an issue opened in TTML2 that we can add this to.
Cyril: "Add example fragments and images"?
Glenn: Yes, w3c/ttml2#359
Cyril: I will do that, thank
you.
... That clarifies the spec, then the question is should we
support it on position?
Pierre: It is a pretty extensive
code change to support it on everything.
... Not to be taken lightly.
... As last time, somehow folks have found a way to work around
this in TTML1. So
... it is a nice to have not a fatal bug.
Cyril: What about adding it and marking it as at risk?
Pierre: Adding it only on some
will be even more work.
... This is only for authors.
Nigel: No it's for users and the
whole ecosystem because it makes it more likely that
... content will have the right size text. By the way if I
wanted to use this I would likely
... consider requiring non-use of % for fontSize.
Cyril: In the Netflix UI you can
adjust the font size. If you designed your document
... without rw and rh then the layout will change if you use
%.
Pierre: No you use c. You can do
exactly the same but it is less intuitive.
... You can set cellResolution to 100 100 and then c is exactly
like rw and rh.
... It is literally syntactic sugar.
Cyril: So it is not hard to implement then?
Pierre: It changes lots of code
paths because now everywhere there is a length rw and
... rh have to be implemented.
Cyril: How do you make the difference between a horizontal value using rw and c?
Pierre: For fontSize it is always relative to the height.
Cyril: We had a use case where we were using it in a horizontal direction based on the rh value.
Pierre: You would set a font height based on rh? That would be weird.
Glenn: Actually a lot of the test
material in TTPE uses that for specifying fontSize.
... Both rw for horizontal and vertical text, for fontSize and
lineHeight.
Pierre: Don't get me wrong, I
wish rw and rh were in TTML1, right.
... I want to move forward so I'm happy to add it as at risk
and move on.
... It can be implemented it's just going to require a lot of
testing.
PROPOSAL: Permit rw and rh units in all length expressions.
Nigel: All agreed?
Cyril: Yes
Pierre: Yes and our goal is to go
for IMSC v1.1 CR CfC today to get by the publishing
moratorium
... so I'm happy to implement that today.
RESOLUTION: Permit rw and rh units in all length expressions.
github-bot, end topic
Pierre: Just to confirm this will
only be in the text profile, right. Nobody has requested
... it for image profile. I don't want to add it to image
profile.
Nigel: What if you don't have pixels?
Pierre: You always have pixels in
image profile.
... I will open an issue against imsc right now for this.
Nigel: Thank you
Nigel: We have no issues or pull
requests on the agenda but there are a number of
... pull requests without reviews.
Pierre: Yes, I would suggest we
open the CfC today. I don't expect the pull requests
... to be contentious but I want to suggest one I opened this
morning.
github: https://github.com/w3c/imsc/pull/395
Nigel: There are various comments on these.
Pierre: There's only one not addressed.
Nigel: That's mine, and it's the only one left from me - I reviewed against all the other issues.
Pierre: I liked your suggestion,
I'll go ahead and implement it on this pull request.
... Do you agree that's editorial?
Nigel: It's in a normative section but I guess so.
Pierre: I'd rather deal with it as a separate issue, because that avoids breaking other pulls.
Nigel: OK
... I've approved this on that basis.
... [summarises the editorial problem]
Pierre: I like the proposal, I think it's the right balance.
Glenn: As we've seen in TTML2
combinatorials quickly become a big problem. The
... origin of features was never intended for prohibiting the
use of content, simply for
... defining conditional support for something and have content
be selected if the
... implementation supported the feature. The other thing was
to list the supported
... features for the process. We've moved away from that and
now we're feeling the pain.
Nigel: Yes.
... I still think it's the right thing to do.
SUMMARY: Pull request approved, further changes moved to another issue.
github-bot, end topic
github: https://github.com/w3c/imsc/pull/408
Pierre: Today it is unlimited, I
think in IMSC it would be good to limit it. I just picked
... 4 as a reasonable value, if someone has a reason for adding
more then we can do that
... but it should not be infinity.
Nigel: I don't have a view but 4
seems like a reasonable max. I don't have a particular
... expectation to use this.
Cyril: I don't know of any use of textShadow by Netflix.
Nigel: Does 708 have a limit?
Pierre: Yes, 1.
Nigel: So fewer than 1 would be
bad, too many is unnecessary.
... Is there any CSS support limitation?
Pierre: I've never tried seeing
what happens as you go towards infinity.
... 4 certainly works.
<cyril> https://en.wikipedia.org/wiki/Lebesgue_measure
Glenn: What is the Lebesgue measure on that?
NIgel: That's to be answered another day.
PROPOSAL: Limit number of textShadow values to 4
Nigel: Any objections?
RESOLUTION: Limit number of textShadow values to 4
github-bot, end topic
Nigel: There are 9 open pull requests right now.
<tmichel> 1st summer publication blackout July 9-13
<tmichel> 2nd summer publication blackout July 30 - August 3
<tmichel> IMSC 1.1 Publication timeline
<tmichel> -----------------------------
<tmichel> June 28th Pierre sends IMSC 1.1 CR2 stable editor's draft for review
<tmichel> June 29th Nigel sends IMSC 1.1 CR2 CfC (14 days period)
<tmichel> July 13th end of CfC
<tmichel> July 16th Pierre sends IMSC 1.1 CR2 final document
<tmichel> July 16th Thierry sends IMSC 1.1 CR2 Transition request to director (needs about a week for approval)
<tmichel> July 17th Thierry upload document at final destination on TR and checks IMSC 1.1 CR2 against validators
<tmichel> July 24th Thierry sends IMSC 1.1 CR2 Publication request to webmaster (needs 1 or 2 days ahaead of publication)
<tmichel> July 24th Thierry sends IMSC 1.1 CR2 annoucement draft to com team
<tmichel> July 26th IMSC 1.1 CR2 Publication
Nigel: Thank you, so I can send
the CfC tomorrow based on the pull requests being merged today
and a version being prepared.
... The request is to merge the open pull requests early and
then run their
... effective review period simultaneously with the CfC for
requesting transition to CR2.
... I will go through the pull requests to allow them to be
merged so this can happen.
PROPOSAL: Merge currently opened IMSC pull requests early
Nigel: Any objections?
RESOLUTION: Merge currently opened IMSC pull requests early
Nigel: Thank you I'll go ahead
and do that.
... And I will issue the CfC tomorrow.
... Looking at the open issues the only other changes we're
expecting to include
... in this resolution are the ones shortly to come that
improve the dependent feature
... boilerplate text and add (at risk) support for rw and rh.,
#409 and #410.
... Just checking #82, we have a resolution there, so that's
okay.
... The aim here is, barring CfC review comments, to have as
stable a document as
... possible to review.
Pierre: I'll merge those pull requests early then.
action-512?
<trackbot> action-512 -- Pierre-Anthony Lemieux to Raise an issue with css wg requesting support for lineshear -- due 2018-07-05 -- OPEN
<trackbot> https://www.w3.org/AudioVideo/TT/tracker/actions/512
Pierre: No activity to
report.
... There's an outstanding bug against WebKit where it does not
process Arabic
... text properly across spans, and that's pretty bad.
Glenn: It goes back to KHTML, the
original source of the code for WebKit. The problem
... was they subdivide their text by spans into objects and
don't consider context across
... those boundaries for computing the glyphs. I looked into
changing that once upon a
... time and decided it would require a huge rewrite of the
entire WebKit layout system.
... Backporting that is well nigh impossible. It's never going
to get fixed unless they
... throw out their code and start anew.
Pierre: That means you're really limited in styling of Arabic text in WebKit.
Glenn: You can't put a span in the middle of a word, that's all.
Pierre: Any news on the scheduling?
Nigel: There's no movement as far
as I know, but I have it on my list to circulate the
... proposed topics for discussion in a joint meeting on the
Monday with the Media and
... Entertainment IG.
... Please let me know if there are any topics to raise.
... For example they are interested in requirements for media
timed events such as
... synchronisation and data packet tunnelling from MPEG into
browsers.
Glenn: I'm going to be out of town from 7th-23rd July, not just those Thursdays mentioned above.
Nigel: Thanks everyone! [adjourns meeting]