See also: IRC log
<scribe> scribe: nigel
Glenn: The main thing I want to do today is review #794 with a view to merging early.
Nigel: Today we have some
regrets, so let's make what progress we can.
... On the agenda is TTWG Charter, TTML2, and I'm not sure what
else we can cover.
... Aside from #794 is there anything else you'd like to make
sure we look at, or any other
... business?
Glenn: #770.
Nigel: OK
Glenn: In the remainder of the
time I'd like to go over the ones ready to go pending
... approval of recent updates to address comments, that are
marked as pending re-review
... in the pull request list for TTML2. There are a couple of
older ones with Nigel's name on
... that maybe we can do in realtime.
Nigel: OK
Glenn: #703 and #755 I think.
Cyril: Nothing more from me.
Nigel: Just to note for the minutes we are now operating under a new Charter:
Nigel: Thanks everyone for contributing to that and working on it.
Glenn: When does it go to?
Nigel: 31 May 2020.
... One other thing for the notes only given the attendees
today: there's no change in scope
... so any invited experts should _not_ be ejected and need to
request re-invitation. If that
... does happen please let me know ASAP.
github: https://github.com/w3c/ttml2/pull/794
Glenn: Summarising the changes,
there were some comments on how to factor the condition
... features and I adopted as you suggested, pretty much
exactly, and also for the rubyAlign-withBase
... I adopted your proposal. On the animate you had a question
about if animate covers
... everything, and it was ambiguous to me as well. In a
previous meeting we had discussed
... animate-related features and I said I would do some work to
tie it to the calculation mode
... and that discrete and linear would be in the minimal
features, and paced and spline would
... be separate features. I refactored animate to do that and
to make sure that the animate
... feature did include those things. I took out the
`#animate-calcMode`, `#animate-keySplines`
... and `#animate-calcMode` and added `#animate-minimal` which
includes discrete
... and linear calc modes and by virtue of that implies support
for keyTimes attribute.
... We don't need a separate feature for keyTimes since it is
in the minimal set.
... The second thing I added was `#animate-paced` for paced
mode.
... And I added `#animate-spline` which implies supporting the
keySpline attribute.
... I redefined the `#animate` feature to include all those
features plus `#animate-fill` and `#animate-repeat`.
... In my mind at this point animate is all wrapped up and
doesn't make use of any negative
... definitions.
... And then the final comment is you had expected language
about processor profiles and
... I commented that it doesn't work because there's no such
thing as prohibiting a feature
... in a processor profile. If you don't require support then
it is optional. If you require some
... superset of a set of features then it implies that all are
present, and making them optional
... does not take them out so to speak. So there's no need to
add something for processor
... profiles by my reading.
... I have a set of pulls stacked up pending this and Pierre
suggested that we merge it ASAP.
... So I need it to go out quickly.
Nigel: Thank you for that, good
summary, it's substantive, and 8 days old.
... [looks at the changes]
... Did you fix `#display-version-2` too?
Glenn: Yes, and I spotted and fixed a typo in one of the links too.
Nigel: Thank you!
... I have some concerns about merging early, because of the
nature of the changes,
... but it's reasonable to ask in the circumstances.
Cyril: I'm fine with it since it is early but not very early. It's been more than a week.
Nigel: There's a lot to review
here - I'm happy in principle with what you've described
but
... need to look at the detail - if we can close the call early
today then I will complete that
... review, but don't foresee any problems.
SUMMARY: @nigelmegitt to complete review and add updated review status
github: https://github.com/w3c/ttml2/pull/770
Glenn: The only outstanding piece
on this is the reference. My opinion is we should make
... a normative ref to the WG Note. Given the loosening of
policies from HTML5 I'm pretty
... sure that it is no longer a no-no. We can't define an HDR
feature unless we can point
... to a normative reference to a format. There's no generic
format. We either put it in with
... the WG Note as a normative ref or we don't include any HDR
PNG feature.
Nigel: Ok, @plhegar didn't get back to me.
Glenn: It's been more than 14
days and we have @nigelmegitt's approval but nothing from
... Pierre or Mike. Since this is still hanging I didn't want
to merge it without group input.
Nigel: This is also related to a
separate issue that I am not up to date on where I began
... working on a pull request and realised that we probably do
not want luminanceGain
... to apply to PQ HDR image at all.
Glenn: It sounds like we can't resolve this until that's worked through.
Nigel: +1
... I've dismissed my review.
Glenn: Does IMSC 1.1 use this?
Nigel: IMSC 1.1 will need to be updated too.
Glenn: Is it really orthogonal?
Nigel: The impact comes from the
comment you made Glenn about testing luminanceGain
... without supporting PQ PNG images.
... (also there's no way to make luminanceGain have no effect,
i.e. be unity, where it is known
... that images generate PQ pixels already).
Glenn: If we don't resolve this
soon then there's a risk of needing a CR3 which I'm wary
of
... because of the time implications.
Nigel: Yes me too, I hope to be
able to process this by the end of tomorrow so we can
progress.
... Back to this particular topic, I think we may not need the
png pq hdr feature at all,
... though we might need a processor feature that can support
identification of pq pixels
... output from image processing, as defined by the ITU spec.
That would get around the
... need to reference the WG Note.
SUMMARY: Resolve #796 and then revisit this based on the conclusion to that issue.
github: https://github.com/w3c/ttml2/pull/707
Glenn: Nigel you asked for
minimum two values in an animation-value-list and I did
that.
... I changed the * to a + in the syntax.
Nigel: Great, and I see that I
made a later comment that if you do that then it would be
... consistent to complete the resolution of the issue by
removing @style from the animate element.
... Did you do that as part of #707?
Glenn: I did it in the
schemas...
... Yes, it's been removed from both set and animate.
Nigel: Looks good to me, I'll approve the pull request.
SUMMARY: Discussed and agreed.
github-bot, end topic
github: https://github.com/w3c/ttml2/pull/755
Glenn: It's tricky - in some
places we have to use TTML without qualification and in
others
... it is relevant to qualify as TTML2.
Nigel: Yes!
... I need a bit of offline time to check through that but I
think it's fine.
SUMMARY: Review to continue offline
github-bot, end topic
github: https://github.com/w3c/ttml2/pull/769
Glenn: I made a change in the
syntax as Pierre suggested.
... Either we need to dismiss his review or wait on him for a
few days. I'm willing to wait.
Nigel: I assume he'll do that, and that seems like the right approach.
Glenn: Basically the change was
to match the CSS exclusions to syntactical combinations,
... by not allowing the excluded syntax at all.
Nigel: Makes sense to me.
SUMMARY: DIscussed in WG meeting, review to continue offline
github-bot, end topic
github: https://github.com/w3c/ttml2/pull/772
Glenn: I just did a commit last
night to address comments.
... Nigel you pointed out that the use of content element
wasn't sufficiently inclusive and
... suggested that we bring in all timed elements including
region, so I introduced the
... term timed element. I had to review all the candidates for
timed elements and decide
... what the distinguishing features were. I first thought
timeContainer, but animate and set
... have begin and end but not timeContainer, since they don't
have timed children.
... On the other hand everything had a begin, dur and end and I
picked begin as a criterion.
... Then I changed content element ref to timed element so that
should address your last
... comment and this should be ready to go.
Nigel: Sounds good to me.
Glenn: This just needs an approval - we've already passed 14 days on this one.
Nigel: OK, interesting we don't have a class that corresponds to these.
Glenn: Not in the spec - in TTV
we have an IsTimedElement that does that, so
implementations
... have to do it. I'm loathe to add another class just for
this purpose. A definition should
... suffice.
Nigel: Okay, I'll review.
... There are 16 uses of "timed element" in the spec.
Glenn: I just noticed that, I'll update to add links to it.
Nigel: Since we refer to this
before, was it deemed to be an obvious concept or did we
... inherit it from SMIL?
Glenn: I don't recall inheriting it from SMIL, but our usage would be different anyway.
Cyril: Timed Element is a concept in SMIL I think.
Glenn: It could be but the
glossary section is very weak. In any case now that we
have
... introduced timed element we should link those 16 places
back to the definition now that
... we've added a term.
Nigel: +1
... Notices we should take care with 12.4
Glenn: Yes
Nigel: Aside from that, I think this looks good.
SUMMARY: @skynavga to update to include references to the timed element term, then review to continue.
github-bot, end topic
github: https://github.com/w3c/ttml2/pull/777
Glenn: I did a commit last night in which I think I addressed Nigel's comments.
<glenn> https://github.com/w3c/ttml2/pull/777/commits/4aaf65d902fc70f374e31751074a18d26389f6f2
Nigel: [reviews in real time]
Looks good to me.
... I've approved.
SUMMARY: Pull request satisfies merge requirements.
github: https://github.com/w3c/ttml2/pull/803
Glenn: I added a comment to this.
Cyril: Can we add a link from the sentence in 8.1.5 to the process for creating anonymous spans?
Glenn: Yes, and come to think of
it we should add the same text to the span element to
... make it complete. Right now it is incomplete.
Cyril: I don't want it to look like there's a separate procedure.
Glenn: That gives me a tbd on this before you sign off on it Nigel
Nigel: OK
... Should we add a note pointing the reader to anonymous spans
beneath the new text?
Glenn: I don't want another place
where we paraphrase what the construct anonymous span
... procedure does.
Nigel: I was thinking of a note with a reference, but I take your point.
Glenn: The terms anonymous span and span already take you to the right definitions.
Nigel: Yes, if you add that anonymous span text from p to span then yes, I'm okay with that.
SUMMARY: Duplicate anonymous span text from p element into span element (for @skynavga) and reference the [create anonymous span] procedure from both.
github: https://github.com/w3c/ttml2/pull/808
Glenn: This adds `xml:base`.
Previously in TTML1 the `features` and `extensions`
elements
... admitted `xml:base` and those were unusual in that we
defined a default value in the
... element information item that specifies using the TTML
feature namespace and the extensions
... namespace respectively. Those were kind of special uses
that had a default.
... This PR and issue is for, now that we have URLs in a
variety of other places such as
... xlink:href and the source element and audio, data and
image, we potentially have some
... uses that are related to the media query support in the
condition function for media functions,
... my conclusion was we need to add `xml:base` to the core
attributes list so it is everywhere.
... Now `xml:base` is hierarchical so you can have multiple
relative levels. It can build up
... hierarchically from the most nested reference to the root
level element. You need to
... populate it everywhere (ability to populate).
... Especially if you're embedding content that has some URLs
in it you might nest that in
... another document and put a relative base on it at the
highest level node. It turns out to
... be quite useful and is supported in SVG and SMIL as
well.
Nigel: Did you fix Cyril's issue about isd:css and isd:region too?
Glenn: Yes. I know Cyril had
suggested just supporting on the root level but as you see
that
... won't quite work.
Cyril: I understand the feature,
I don't think it's a priority. You could default it to the
base
... of the document itself.
Glenn: That is the default
default if there are relative URLs in the document with no
xml:base specified.
... We don't have to say anything to support that.
Cyril: I don't have a strong preference. It's mainly useful for images and audio content right?
Glenn: Exactly.
Nigel: I don't have strong view
either, but don't have a particular use case. I don't think
it
... is especially harmful. Is there a profile feature for
it?
Cyril: There is #base and #base-version-2
Nigel: Ok
<cyril> https://rawgit.com/w3c/ttml2/0c93c4dfa88e85a61d1c2cf1bae9a530c1e7e25c/index.html
Glenn: I defined it that way
because we already had base in TTML1 but with no feature
so
... I defined in TTML2 a feature that mapped to the original
TTML1 support for base and then
... extended it with the version-2.
Nigel: Makes sense.
Cyril: I think we should move on
from this - it was opened yesterday.
... Seems consistent, not harmful, we should approve if there's
no objection. I would like
... some input from the SMPTE image users to see if they have
any views on this.
Glenn: Yes, I'm not asking for early merger on this.
SUMMARY: Offline review to continue.
github-bot, end topic
github: https://github.com/w3c/ttml2/pull/759
Glenn: Nigel you made a statement about this but did not approve.
Nigel: Yes, that was 2 weeks ago,
pending a discussion of the approach to defining features
... by reference to their TTML1 definition. We had that
discussion and agreed to proceed
... on that basis so I can now complete the review of this pull
request.
... [does a rescan] Looks good to me.
... I've approved it.
SUMMARY: Pull request meets criteria for merging
github: https://github.com/w3c/ttml2/pull/805
Glenn: I don't have any reviews on this yet.
Cyril: The reason I didn't review
it is I don't really consider it necessary. There's no
impact
... if there's a bug in this one.
Glenn: Exactly, this is a non-normative appendix.
Cyril: I can approve it if you want but I thought Nigel was best placed to do it.
Nigel: I need more time to review this.
Glenn: That's fine with me - I
just need a review. It's an editorial pull request that's only
2
... days old, so there's a day to go minimally before merge
anyway.
Nigel: OK I'll take a look.
SUMMARY: Offline review to continue
github-bot, end topic
Glenn: I've marked a couple of them for agenda
github: https://github.com/w3c/ttml2/issues/377
Glenn: Nigel, you're original
complaint was that we prematurely deprecated the use of
... the sequential time containment in smpte discontinuous mode
and you have argued that
... there is a potential interpretation of that. I argue that
even if that is the case then it
... doesn't make any sense to use it and it shouldn't be used
anyway.
... In my mind smpte discontinuous indicates that there is no
time container at all.
Nigel: I don't think there's no time containment.
Glenn: For example if you have a
span in a p and the span says begin=0s and the p says
begin=10s
... for me the 0s on the begin relates to the document timeline
not to the p.
... Any time you find a time in a smpte discontinuous document
then it relates to the
... document context. This is from markerMode. The problem with
what you're suggesting
... Nigel is that it backs out that. Under markerMode it says
that time expressions must not
... be calculated etc. in discontinuous mode. All time
expressions are interpreted as time
... events which cause a temporal interval to begin or end
accordingly.
Nigel: I don't disagree with that
but my point is that time expression calculation is
orthogonal
... to time containment, and that there is a logical processing
model for sequential time
... containment with smpte discontinuous, treating the time
expressions as events.
... I don't believe that there is any data presented to
deprecate this potential usage.
Glenn: If we take out the
deprecation, I don't really want to tweak this language or
add
... more language?
Nigel: I don't think we need to
do anything particular to the spec and I wouldn't
prioritise
... this niche use case, just back out the deprecation.
Glenn: Is this editorial?
Nigel: Although we apparently did
not have consensus for this when #647 was merged
... in February, this is a substantive change relative to CR1
unfortunately.
Glenn: Okay I can accept backing out the deprecation, I may ask for early merge next week.
SUMMARY: Back out the deprecation of seq time containment in smpte discontinuous
github: https://github.com/w3c/ttml2/issues/697
Nigel: I still have the action on this.
Glenn: To some extent #794
overtakes this because we are already backing out some
... negative feature designations. I'm not sure if there are
potential action items.
Nigel: Let me keep it and think
further on this please.
... The action on me is to demonstrate that there is a specific
problem.
Glenn: The only remark I have is
that one of the reasons we use the phrase "all defined
values"
... is that not all values are enumerable, e.g. floating point
values, and the primary condition
... expressions are infinite in their number of possibilities,
so we can't enumerate every
... value set.
Nigel: There are ways to group value sets finitely.
Glenn: In the condition
refactoring, where you suggested using "non-function"
expressions,
... there probably isn't any other way to do it.
Nigel: Ok the action is still with me.
Glenn: My point is even if you
think we'd like to do this I don't think we can
completely
... do what you're suggesting, in the case of some infinite
value sets.
github: https://github.com/w3c/ttml2/issues/779
Cyril: Glenn can you clarify that
we harmonised rubyReserve with rubyPosition using
... `<annotation-position>`? Looking at the CR spec I
couldn't find it.
Glenn: There's an optional length
component in rubyReserve.
... The set of keywords that are defined there are equal to or
a subset of `<annotation-position>`.
... We took out around and between.
Cyril: Did we change the examples?
Nigel: [checks spec] There's no mismatch between the examples in rubyReserve and the syntax.
Cyril: OK, sorry, I was looking at the wrong version.
Glenn: The example does need to be updated - around and between have gone.
Nigel: Sorry, I also looked at the wrong version.
Glenn: It looks like I just need to remove the around and between examples.
Cyril: OK, now about the
behaviour or ruby, line area and lineHeight.
... You clarified that the rubyReserve area is parented to the
line area.
Glenn: Correct.
Cyril: But I remember that the
CSS WG said that you also had to set the line-height and
that
... ruby-reserve did not affect the line height. Is that the
case in TTML2 as well?
Glenn: I avoided going into the details of this in the spec.
Cyril: so it's implementation specific?
Glenn: Yes.
Cyril: Why don't we do the same with rubyReserve?
Glenn: TTP for example increases
the line height based on the concept that the definition
... of normal under line height maps to the per inline height
rectangle in XSL-FO and that
... is defined in such a way as to increase the line height on
the per line area basis based on
... the glyph areas contained in that so that the ascender,
descender and half leadings on
... both sides of every glyph area are included in the line
height for that particular line.
... The height of individual areas in "normal" varies based on
what is inside them. The model
... there is to extend the line height to enclose the
descendants. I use the same model, if
... lineHeight="normal" (including default) it will increase
the line height of a box that has
... ruby to include the ruby annotation inline areas. I avoided
writing this into the spec at
... this point. One thing you are suggesting is that we add a
note maybe that it is implementation
... dependent what effect rubyReserve has on lineHeight?
Cyril: I'm not sure if that is
what I am suggesting. I am trying to understand how it
works.
... If I cannot understand it probably other readers cannot
understand how it works.
Glenn: Interestingly Pierre is
just mapping to CSS and letting CSS do it. What I
implemented
... is basically compatible with that. CSS doesn't define those
details. It's basically what is
... implemented in the wild is the de facto standard.
... It would take a lot of work to define those
requirements.
Cyril: I'm fine with not
specifying it and maybe in a future version doing that when we
have
... converged on a processing model.
... Pierre is saying that the length field is
over-specified?
Nigel: I think we need Pierre here for that.
Glenn: My interpretation is that
he has some issue with how we define the default value
... for length.
... We have the problem of length with lineHeight too, which is
not dependent on font size either.
Nigel: OK so now we have the
problem in two places!
... Given the time and that this issue was raised by Pierre who
is absent, we should not
... continue with this issue.
github-bot, end topic
github: https://github.com/w3c/ttml2/issues/806
Glenn: I would like to spend 5
minutes on this for the record
... The issue is lineHeight - what does "normal" mean?
... We had some language in TTML1 that said the computed value
is no less than the font
... size that applies to the element and its descendant
elements. When we recast that in TTML2
... we inadvertently omitted mention of the descendant
elements.
Nigel: No, we discussed it and decided that we didn't need it.
Glenn: Thanks for reminding me, I
need to go back to the notes on that.
... I decided to re-review the way that XSL-FO defines this,
and the CSS semantics, and I
... concluded that TTML1 semantics do not match CSS 2 or XSL-FO
and TTML2 semantics
... match none of them as defined. I marked this as a bug and
something we need to deal with.
... I was going to maybe today or tomorrow post a pull request
to deal with this. The main
... problem is that the current algorithm leads you to the
conclusion that you can set a
... uniform line height that is resolved from normal and that
it applies to every line
... irrespective of the inline areas on each line. In the
XSL-FO language it says it should be
... the minimum required to enclose the paragraph's requested
line height and the line height
... for each of the inline areas within the line area. In other
words different line areas may
... have different heights based on lineHeight="normal". The
current text does not do what
... CSS2 does or what XSL-FO says.
... We're inconsistent.
Nigel: I recall Andreas making a
presentation to us in a face to face meeting about this,
... and pointing out that the line stacking strategy we use in
TTML means that lines can
... never overlap each other.
Glenn: I dispute that, and will
have to go back and check.
... "normal" is the most used value, and I'm pretty sure that
the expectation would be the
... same as in CSS, but that is not how it is specified
now.
... I don't know if say imsc.js would be able to do what the
new language says.
Nigel: I would advocate looking for line stacking strategy and go back to where we discussed this before.
Glenn: In the case of "normal" you don't get bleed over between lines, but you might with a number.
Nigel: I thought the same line stacking strategy applies even with a number.
Glenn: If that's the case then XSL-FO would be inconsistent with CSS2. I would need to look at that.
Nigel: The line-stacking-strategy is line-height, regardless of the value of tts:lineHeight.
SUMMARY: @skynavga to continue investigating
github-bot, end topic
Glenn: We covered a lot today so
thank you for that. I look forward to the pull request
reviews.
... #794 is my highest priority if you can take that into
account.
Nigel: OK, thanks both, next meeting same time next week. [adjourns meeting]