See also: IRC log
<nigel> scribe: nigel
Glenn: Regrets from me for the next two meetings as I'm travelling, unless I'm in a connected location.
Nigel: Today we have the usual
order of agenda items: TTML1, TTML2, IMSC, CSS,
... I'm not sure if there's anything on IMSC requirements or on
WebVTT and don't
... expect to cover those unless attendees want to.
... Any particular topics anyone wants to cover, or "Other
business"?
... We have at least one agenda issue for TTML2 so they are
already on the agenda.
group: [silence]
Nigel: Okay let's proceed.
Nigel: Do we have any agenda
points for TTML1?
... Is it worth looking at action-513?
Action-513?
<trackbot> Action-513 -- Pierre-Anthony Lemieux to Look at ttml2 backporting to ttml1 3rd ed to see if we can change the ref from ttml2 to point to 3rd ed. -- due 2018-07-05 -- OPEN
<trackbot> https://www.w3.org/AudioVideo/TT/tracker/actions/513
Pierre: We're still making (editorial) tweaks to TTML2 so we should port those to TTML1 too.
Glenn: My key concern is timing.
Philippe's tool says the earliest date we could go
... to Rec for TTML2 on 13th Sep. If we are to do that then we
also need to go to a
... final CR on TTML1.
Pierre: Can we go to a final CR
on TTML1? Is there any change to TTML2 for CR2
... that can't be done non-normatively on TTML1?
Glenn: I see, could we track TTML1 and TTML2 editorial changes together?
Pierre: Exactly.
... Is there an easy way to see the substantive changes from
TTML2 CR1 to CR2?
Glenn: The change document is fully up to date now.
Nigel: That's from the published
CR2
... It's pretty detailed in terms of the technical changes.
Pierre: Glenn, do you know any
that would have an impact where we changed our mind,
... things we did between CR2 and CR1 that should be reflected
in TTML1 3rd Ed?
Glenn: I can't do that in real
time, I would have to review them.
... The only one that might would have to do with lineHeight.
I'd rather keep hands off
... on that. My general view is that none of the changes we've
made in CR2 must
... necessarily go back in TTML1 at this point.
Pierre: Can we look at
tts:lineHeight right now? To see if they are incompatible or
if
... TTML1 3rd Ed is bad here?
Glenn: I don't see a necessity to
backport anything. Whether it is desirable or not is a
... different story. I'm not ready to say either way on that
right now.
Pierre: So if today we referenced
TTML1 3rd Ed from TTML2 would you be happy?
... Assuming both go to PR together.
Glenn: I wouldn't say today but
would be prepared to make a decision before July 26.
... Between now and then I will have a chance to review.
Pierre: I think it's desirable,
right, because we know 2nd Ed has some incompatibilities
... with TTML2.
Glenn: My only concern is there's
a finite risk in doing that. Say for example we go to
... PR with both on the same day, and for some reason TTML1 3rd
Ed fails to have support
... to go to the next step, e.g. the AC votes for TTML2 but not
for TTML1 3rd Ed.
Pierre: There's an equal risk
that the AC votes down TTML2 because it does _not_
... reference TTML1 3rd Ed.
Glenn: We don't have an objection so far.
Pierre: I think both scenarios have comparable really low risk.
Glenn: I agree, I just don't want to make a decision today.
Pierre: I propose to make a
tentative decision today to ref 3rd ed and unless someone
... comes up with a reason not to do it then we can revert.
Glenn: I'm not comfortable to
make a firm decision today without reviewing.
... I suggest Pierre opens a PR milestone issue on TTML2 that
proposes updating the
... reference.
... That way we can track it. If we make that change then we
can say we have a comment
... asking for that.
Pierre: I'll do that.
Nigel: I would be in favour of
changing the reference to TTML1 3rd Ed. Actually I would
... take some persuading _not_ to do that. My understanding of
our work on 3rd Ed has
... always been that the goal is to reduce the delta between
TTML2 and TTML1 so it has
... been my working assumption we would do so, and it looks
like an oversight that we
... have not already made the change.
<nigel_> Action-513: Pierre to raise issue on ttml2 to change reference to TTML1 3rd Ed; all to review to check this does not cause any problem.
<inserted> scribe: nigel_
<trackbot> Notes added to 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..
Nigel: Anything else on
TTML1?
... We're still waiting for tests I recall.
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-07-05 -- OPEN
<trackbot> https://www.w3.org/AudioVideo/TT/tracker/actions/443
Glenn: I haven't been able to get
to that yet. I can draft something really short without
... substance in it that we can pass on to ARIB telling them
that TTML2 has features that
... intersect with ARIB-TT and offers support for some of the
functionality; we're in CR2
... taking further comments for editorial changes etc
etc.
... If the purpose of this is simply to notify ARIB folks that
they might want to look at it
... I'd rather put the onus on them than continue to bear the
burden to describe how
... TTML2 could possibly be used in their context. That would
require me to go heads
... down reviewing a Japanese document which is time consuming
for me.
Nigel: They do have an English translation.
Glenn: In any case I'd rather put the onus on them - I have a lot on my plate.
Nigel: That's fair, if you can do that please then I will get that to them as soon as possible.
Glenn: Okay.
Action-443: Glenn to prepare non-detailed message for use as a liaison message; Nigel to send.
<trackbot> Notes added to Action-443 Prepare a document showing mapping arib ruby extension features to ttml2 for use as a liaison document to arib..
Nigel: Glenn, please could you
give us a quick status update on the TTML2 tests that
... you've been adding lately?
<inserted> scribe: nigel
Glenn: I've been focusing on
making sure there are minimally adequate tests for use
... in validation processes with both positive and negative
validation results for the new
... features. Once I've done that I'll do the same for
presentation semantics.
Nigel: Thanks, can you give us a sense of how far through that work you might be?
Glenn: I've got tests for most of
the tests but have to go through and tweak them to
... make sure they are self-consistent with each other in scope
and are correct, so the
... verification process is about 30-40% complete for the
validation tests right now.
... In some cases I'm adding new validation tests when there's
something lacking.
... If I can do 4 hours a day on this I can usually knock off
10-20 features. Since we only
... have 255-114 = 141 new features I can probably knock them
all off in a week of
... focused work. Depends how much time during my holiday I
will have!
Nigel: Do you want to delegate any of them to anyone else?
Glenn: I'm working behind the
scenes with Cyril who is doing the same with Netflix
... internal representations however he will be out for most of
July too. Obviously it
... needs to be done by August 9th for sure.
Nigel: Yes, and obviously people need time to run the tests and report on them.
Glenn: That's true.
... I'm also marking features on the spreadsheet Cyril
circulated on green. I've not yet
... augmented that spreadsheet to show which tests go with
which features however it
... is fairly self-evident which tests go with which features
if you look in the repository
... right now.
Nigel: Any other questions or
comments on that?
... Thank you by the way!
... We have 3 open issues marked for the agenda.
github: https://github.com/w3c/ttml2/pull/866
Glenn: This doesn't need
Andreas's review in my opinion, it is just a typo fix to
change
... "extended area" to "extended rectangle" which is the term
used in XSL-FO and was
... intended.
Nigel: I'd still like to give
Andreas a week to review it - if he hasn't managed to by
... then then I will go ahead and approve it.
Glenn: Ok
github: https://github.com/w3c/ttml2/issues/860
Glenn: Nigel you don't want to
comment there at all and I want to address my original
... issue, which is that absent a comment some readers might
incorrectly assume that
... it is possible to change ECP or EPP over the lifetime of
document processing, and the
... semantics of validation processing assume constancy.
... applies to document transformation and processing.
... The assumptions are there and we don't document those very
well, and at this point
... an informative note is the least I could do about
that.
... In order to address one of your concerns (maybe) I tweaked
this last night by adding
... another note that goes in the top of the conformance
section and says the conformance
... requirements are scoped to implementations that operate on
a static instance.
... Processors that modify documents are not governed except
that a final document
... should satisfy conformance (paraphrased).
... During the interim stages of authoring and editing all bets
are off basically.
... The second thing is for the two notes I added I qualified
them to say "for the purpose
... of complying with generic processor conformance ..." to
scope those informative
... statements to generic processor conformance processing.
Nigel: I haven't had a chance to
review those recent changes, but my position is that
... the issue simply doesn't exist.
... I don't see what problem this is solving, it seems too
complicated and unnecessary.
... I think we should simply say nothing.
Glenn: Most of the comments fall
in the category of "it's obvious or wrong" and there's
... no requirement that all notes are correct. You're stating
that it could be wrong is in
... my opinion based on some generalised fear that we're going
to say something wrong
... that is premature. Most notes are "for the avoidance of
doubt take note..." but here
... we have two important assumptions that are not so obvious
at all. The fact that we
... only perform document validation once and abort if
unsupported profile once, for some
... readers it would not be obvious that the parameters used
can not change. They may
... make the wrong assumption like maybe you have that they can
change within a single
... processing session. In our scope we have some assumptions
that they are constant
... because if they are not then all bets are off. All the
semantics assume that if it is
... valid once it remains valid. I don't know how you can say
it is obvious or wrong. Not
... adding the note does not address the concern I have raised
even if you don't think
... it is an important concern. When I read the spec recently,
I saw there are a number of
... paths in the spec to those procedures. One might get the
wrong impression that they
... might be evaluated multiple times and come up with
different answers. I wanted to
... make it documented that that is not the intention.
Nigel: I agree that it is not the attention.
Glenn: How do we document it in a way that addresses your concerns?
Nigel: If you're insisting on
adding some text then we need to add some scoping text
... perhaps like what you have done (I need to review)
essentially creating the abstract
... concept of a validation session within which everything is
held constant and the
... outcome does not change on re-evaluation (and indeed such
re-evaluation is unnecessary).
Glenn: Not just a validation
session but also scope of computing the results of the
... processor profile effect on the document, e.g. abort
semantics. You cannot decide
... not to abort at one point because all required features are
satisfied and later on
... decide that you should abort.
Nigel: There are different reasons for aborting.
Glenn: The only cases are to do
with validation and lack of support for required
features.
... Those are two different use cases with different paths to
those at different points in time.
Nigel: Okay, anyone else have comments on this?
group: [silence]
Nigel: In that case the action is with me to review and potentially propose further changes.
SUMMARY: @nigelmegitt to review recent commits.
github: https://github.com/w3c/ttml2/issues/881
Glenn: If we're open to changing
the animatability status of properties as non-normative
... changes I'm certainly okay with this and if we do that then
I would like to radically
... reduce the set that is continuously animatable.
... There's also another problem that we use the terms discrete
and continuous right now
... in each property. Previously we had discrete or none in
TTML1 since we did not have
... any form of continuous.
... There are actually 2-3 kinds of continuous animation
available, linear, paced and spline.
... The paced animation limits the application in SMIL and SVG
to a tight set of potential
... features that have reasonable interpretations under those
semantics. We have not
... so far attempted to delineate what continuous means in our
property definition tables.
... For example linear-spline, linear-paced and linear-spline.
In fact discrete is a
... calculation mode in animation as well. In retrospect we
have not done a very good
... job in specifying the animatability of these
properties.
... One of the difficulties of implementing them is whether or
not it triggers relayout.
... For instance fontSize can be animated in implementations,
and some CSS and SVG
... implementations do that, however whenever you do font size
changes the content
... needs to be relaid out. It complicates the
implementations.
... To the extent that we rely on CSS and SVG implementations
supporting this as opposed
... to requiring TTPE or IMSC.js to perform multiple layouts
along discrete time events
... for example on every frame, that's definitely going to
impact performance and other
... factors. If we are going to change any of the animatability
of properties I would
... propose that we scale back to only a few properties for
continuous animation namely
... color, opacity and position.
... The other one is potentially for gain and pan, which have
reasonable interpretations
... for continuous animation and don't require relayout.
... I would also be okay to go out the door today.
... We have not defined any features that tie the animatability
of specific features to their
... animation calculation mode.
Nigel: We have already marked
`#animation-verion-2` as at risk, so we could argue that
... removal of some animation semantics is reasonable as a
result of implementation
... feedback when we go to PR.
Glenn: I like that approach.
Pierre: Works for me.
... I was reviewing the Process document and there's no way to
make substantive
... changes between CR and PR. Given our timetable, unless it
is fatal we should capture
... those issues and proceed with a 2nd Ed immediately.
Glenn: There is an exception as Nigel mentioned.
Pierre: Absolutely. I would rather deal with stuff that can be dealt with as at risk, that's better.
Glenn: This would be a case where
we can address a comment as somewhat short of
... full removal of a feature. I don't think there's anything
that deals with this nuance so
... it's probably worth Nigel running it by Philippe.
Nigel: Okay I'm happy to that.
SUMMARY: @nigelmegitt to check with @plehegar if partial removal of at risk features might be okay.
Glenn: Otherwise we could always
deprecate or clarify or both in TTML2 2nd Ed.
... By the way writing-mode was already excluded from animation
in CSS.
Nigel: It's discretely animatable.
Glenn: That's ok.
... In my perspective we should review all the continuous cases
and scale some of them
... back to discrete. We should also add a note that continuous
means linear, paced or
... spline depending on the property and in some cases paced
may not apply.
Nigel: Makes sense.
Glenn: The alternative is to
remove continuous and simply list all the possible
... calculation modes depending on the case. That would be more
explicit.
Nigel: Agreed.
... I just want to come back to the point about audio gain and
pan properties - it is
... almost completely pointless from an audio description
perspective to have gain or
... pan that cannot be continuously animated. The only possible
get-out is if implementations
... are given the freedom to process discrete animations as
continuous, but that's not ideal.
Glenn: Of the 4, we've said gain,
pan and pitch are continuous and speak is discrete.
... That's what we have right now.
Nigel: I'm not so bothered about pitch as I don't see a use case.
SUMMARY: Several style properties probably are marked as continuously animatable but should not be.
Nigel: Does IMSC 1.1 allow for any continuous animation?
Pierre: It does not.
Nigel: Okay then it is not affected.
github: https://github.com/w3c/ttml2/issues/883
Glenn: Right now @spoeschel and
myself are having a dialog. We have `#opacity-block`
... and `#opacity-inline`. The problem is that we have tied
those to content elements
... and in our definition of content elements in the
terminology they are tied to the
... content class which does not include image right now.
However image does describe
... itself as defining block and inline areas depending on the
context of use.
... So we have a discrepancy. My plan is to editorially change
the definition of the
... term "Content element" in the terminology section to add
the image element to the
... set of content elements.
Pierre: What is the consequence of the current text?
Glenn: Right now content element as defined points at the content module...
Pierre: Imagine it were published
as is today, what would be the consequence of the
... issue that Stefan raised, practically?
Glenn: There's no way to require
specifically the combination of opacity and image
... unless we make this minor tweak.
Pierre: I don't think that's fatal.
Glenn: I agree and that's what I
suggested to Stefan, it is arguable whether we need
... a combined feature in the first place.
Pierre: I would log this as an issue to be deferred to 2nd ed and move on.
Glenn: That works for me.
Pierre: I'm concerned with tweaking the definition of content element.
Glenn: Right now table 5-3 in section 5.4.1 core catalog defines the modules.
Nigel: Changing that feels normative and I'd be concerned about the impact.
Pierre: A change to core
definition, and how set and timing is applied are all
intertwined.
... My inclination is to say move to 2nd Ed.
Glenn: One of the problems if we
don't do anything is there are many cases where we
... use content element as a phrase and we really mean it
includes image as well and
... we have failed to note that.
... One way to handle it is to add an informative note that our
intention is also to include
... image without making it normative text.
Pierre: As you know the layout,
style inheritance etc have specific conditions based
... on content element and we would have to review.
Glenn: In many cases they mention image.
Pierre: We spent a lot of time
reviewing it in the past. If the only consequence is
there
... is a bit of ambiguity about the application of opacity on
image that does not sound
... like a blocker to me.
... It's fine to defer it and even open a pull request for 2nd
ed. Unless it is fatal I think
... it sounds super-risky, even to add a note.
Glenn: I intended to make the
`#opacity-block` and `#opacity-inline` features to
... include image but did not explicitly check that the
definition included it.
Nigel: I'm with the view that we
should not make a change now here, for two reasons:
... 1. If anyone really needs a feature designator they can
extend a current one, if we
... have not already introduced it in a future edition.
... 2. Introducing the proposed change now puts us at high risk
of accidentally making
... a substantive change with very small benefit.
... I also think it is very unlikely that anyone will request
this feature designator.
Glenn: Okay.
PROPOSAL: Defer this until ttml.next
Glenn: Ok
Pierre: I'm fine with that too.
RESOLUTION: Defer this until ttml.next
github: https://github.com/w3c/ttml2/pull/880
Glenn: This changes "any
attribute" to "any attributes" inside curly braces where
we
... mean any one or more attributes.
Nigel: I expect that's all the clarification that is needed.
Glenn: As an FYI this syntax
comes from the XML schema specifications.
... For the curly braces. There's also some usage in CSS to
refer to a collection of
... characters, that we use in a couple of places. Just a
historical note.
Nigel: I will get around to reviewing that in the course of things.
Pierre: I think it's an improvement.
Pierre: I reviewed this and think
the only thing is the interpretation of
lineHeight="normal".
... I think the text today in TTML1 3rd Edition is incorrect
because it talks about the
... computed value being considered to be no less than the
largest font size of the element
... and all its descendants in the ISD.
Glenn: That is in direct
contravention of CSS that says the computed value of
... line-height: normal is normal. That's why I had to make the
change in TTML2.
Pierre: The bigger issue is the text in TTML2 does not mention descendants whatsoever.
Glenn: That was intentional because it is wrong.
Pierre: Exactly, right, so the
text in TTML1 3rd Ed is bad today and unfortunately there
... is a must there so that really has to be corrected in 3rd
Ed.
... That is the only change I know of.
Glenn: By the way this language
originated in CSS and XSL-FO, the discussion of
... descendants in line-height, at least partially. If you look
at the CSS 2.1 or 2 definition
... of lineHeight there's a phrase or sentence [UAs may
determine the line height according
... to the largest font size], but an element can only have one
font size so it can only
... really mean the largest among descendants, or among
children.
Pierre: or the largest glyph size.
Glenn: Needless to say it is
highly ambiguous and we already have statements from CSS
... folk is that it's at least partially wrong.
Nigel: We need to come to what we do about it in TTML1.
Glenn: The problem is the word "must".
Pierre: We could start a CfC today.
Nigel: Can someone open a pull request first?
Glenn: What would that do to the
timeline for TTML1 going to PR? If it requires going
... to CR again that would be a problem.
Pierre: Why?
Glenn: It would reset the date on the timer for the 3rd Ed.
Pierre: We don't need a CR3 on
TTML2 I think.
... We need a CR2 for TTML1 because it is a change on
TTML1.
Glenn: If you do that it will alter the timing and we cannot update the reference.
Pierre: I'm fairly certain that we will not need a new CR for TTML2
Nigel: I agree.
Glenn: I'm saying to go to Rec on
TTML2 with a reference to TTML1 3rd Ed would be
... delayed until TTML1 3rd Ed goes to Rec.
Pierre: There's a 2 week difference right now.
Nigel: I feel that there may be a
way (depending on Philippe or Thierry) to finesse this
... so that there is no adverse effect on the Rec publication
date for TTML2.
Pierre: I think we should explore
trying to be more efficient with Philippe and/or Thierry.
... Even if there is a delay it is procedural between PR and
Rec.
Glenn: My understanding is
there's a 60 day exclusion period that gets reset when
you
... do a new CR.
Pierre: We just did CR2 for TTML2.
Glenn: From what I hear from
Philippe, one substantive change to a CR triggers a new
... 60 day exclusion period.
Nigel: What's the problem with that?
Glenn: A new CR today would put
TTML2 Rec into October. I've made commitments
... to go to Rec in September so I'm not prepared to agree with
a delay.
Pierre: There would be no change
to the document, this is just procedural.
... I encourage you to check with your clients.
... TTML2 referencing an obsolete spec is bad.
Nigel: As mentioned earlier in this meeting that does itself represent a risk.
Glenn: I am going to have to object if there is one day delay to TTML2.
Pierre: I encourage you to check
with your clients to see if that is really a blocking
issue
... and would be happy to talk to them about that.
Glenn: Based on my current
commitment that is my position right now.
... If we can agree that the 60 day period does not apply, for
example noting that it is
... an error not to match XSL-FO or CSS, with Philippe, then
that could help.
... I think our long-standing goal is to publish TTML1 3rd Ed
and TTML2 at the same time.
Nigel: A concrete proposal in the
form of a pull request on TTML1 3rd Ed would be
... very helpful in terms of the discussion with W3 staff.
Pierre: I will do that immediately and recommend we start a 2 week clock today.
Glenn: I'm okay with that pending the PR being merged.
Pierre: I will copy the exact text from TTML2 minus the non-applicable text.
Glenn: It's not a must-have for
me to fix it.
... You could put an informative note in saying it should be
"may".
Pierre: Let's first check what our optionsare.
Nigel: I think that's as far as we can go on this right now.
Nigel: A reminder we are mid-way through the CfC.
Pierre: There are 2 pull requests
awaiting approval.
... One has been approved by Cyril but it touches on an issue
close to your heart Nigel
... so you might want to look at it.
... The other I think is good to go but is missing an
approval.
Nigel: I will prioritise those so they can be merged.
Pierre: I don't think they are controversial.
Nigel: Anything else to raise on IMSC 1.1 for the CfC?
group: [silence]
Nigel: If there are comments then
please raise on the repo.
... Do we need to cover the pull request on the
imsc-vnext-reqs?
Pierre: No, I think I just need to make a small change as per your suggestion Nigel.
Nigel: okay.
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
Nigel: CSS has been discussing
shear and I added a reference to the CSS issue on
... fonts-4 in the agenda.
[css-fonts-4] oblique angle for synthesis in vertical text
Pierre: I have not done anything on this yet. Is there an urgency?
Nigel: Only for getting CSS support for things that will end up in IMSC!
Pierre: The two fundamental
issues for IMSC 1.1 are:
... 1. Only Firefox has good support for Ruby.
... 2. Arabic rendering does not work across spans in
WebKit.
... In practice that is probably a much bigger issue.
... But yes I have to file those things.
Nigel: I imagine CSS WG has been
meeting this week because there has been a burst
... of activity. It's worth keeping your eye on.
Nigel: We've completed our agenda today so I'll close the call. Thanks everyone! [adjourns meeting]
<scribe> scribe: nigel_