- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 13 Jun 2019 18:14:01 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <D9284F04.464A3%nigel.megitt@bbc.co.uk>
Thanks all for attending todays TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2019/06/13-tt-minutes.html
We made one resolution regarding WebVTT:
Resolved: Mark any remaining features with tests that don't have at least 2 passes as at risk
We also resolved in the course of the conversation that the proposal to request transition to PR cannot go ahead at present due to the presence of at least one mandatory feature with a referenced source that is not at the appropriate maturity level and appears to have no implementation or tests. The CfC to request transition to PR is effectively cancelled pending removal or implementation of the affected features.
The intent of the group here is to reduce the scope of the specification down to what can be recommended according to the W3C Process and consider re-adding such removed features into future versions.
The next steps are to work on tests and implementations and mark as at risk any features that cannot be demonstrated to pass the CR exit criteria following that work. My understanding is that this means publishing another CR prior to trying to go to PR again.
Those minutes in text format:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
13 June 2019
[2]Agenda. [3]IRC log.
[2] https://github.com/w3c/ttwg/issues/42
[3] https://www.w3.org/2019/06/13-tt-irc
Attendees
Present
Andreas, Cyril, Gary, Glenn, Nigel, Pierre
Regrets
Chair
Nigel
Scribe
Cyril, nigel
Contents
* [4]Meeting minutes
1. [5]this meeting
2. [6]WebVTT transition to PR
3. [7]Clarify use of 'applies to' in style property
definition tables (ttml2#1088).
4. [8]text-decoration
5. [9]text-emphasis
6. [10]font selection strategy
7. [11]font variant
8. [12]text combine application
9. [13]Emphasize null style semantics in context of ruby
container spans
10. [14]Meeting close
* [15]Summary of resolutions
Meeting minutes
<nigel> Log: [16]https://www.w3.org/2019/06/13-tt-irc
[16] https://www.w3.org/2019/06/13-tt-irc
this meeting
nigel: 2h meeting today
we've got comments/questions following CfC on WebVTT
a bunch of issues on TTML2
an outstanding profile registry issue
and an outstanding question for Philippe about the ICC
profile
lastly update on charter status dependent on Philippe
in AOB we could discuss Karaoke
and live and audio description
if time allows
WebVTT transition to PR
nigel: plh sent a CfC last week
one more week to go
people have been looking at it
queries have been coming regarding failing tests
1st one is text-wrap: balance
<nigel> [17]Thread re text-wrap: balance;
[17] https://lists.w3.org/Archives/Public/public-tt/2019Jun/0020.html
nigel: I noticed that there is a must requirement in the spec
but there does not seem to be any implementation nor tests
I'm struggling how we can progress on this one
Cyril: What is the policy re referencing other docs not at CR
stage? text-wrap: balance is at WD.
nigel: in the past we have avoided from TTWG specs normative
references to documents that are not in PR
we haven't normatively referenced something that is at WD
stage
glenn: we definitely have not referenced WD or ED
CRs are questionable
would require justifications
there have been some CRs that have become the status quo
part of the problem is that membership of W3C has not given
its opinion before PR
cyril: either we do an exception or change it
gkatsev: I've been working under the assumption that if WebVTT
does not proceed to PR it will be removed from the charter
I would not have any problem removing it and going through
another CR if it would be kept in the charter
pal: that seems the logical thing to do
gkatsev: removal from charter is my major concern
pal: your concern is that if remove this feature, it would
delay publication and risk being removed from the charter
gkatsev: yes
pal: where did we say that?
nigel: it's a WG resolution
that said, the tone that we've had from Philippe is that we'd
rather delay the charter to have WebVTT in
the charter update is more for the scope update
we could delay the charter update
pal: the current charter expires May 2020
nigel: yes, but we've decide to proceed with documents that are
not currently in charter
so that would be annoying to have those documents delayed
pal: so the concern is about a resolution that we passed
<nigel> [18]TTWG Charter repo
[18] https://github.com/w3c/charter-timed-text
nigel: the resolution was passed long before Gary joined
there was no active editor, ...
pal: my preference is to treat WebVTT like any other spec, no
more no less
and to proceed along those lines
atai2: the goal should that we don't make our life harder with
our own decisions
if we can amend/interpret our decision
then that leaves enough time to proceed and remove any
feature that is not implemented
and follow the usual process
nigel: 2 things going on
concern about the charter
<Zakim> nigel, you wanted to check if we have consensus to
remove the text-wrap: balance; feature
nigel: and text-wrap: balance
do we have consensus about text-wrap: balance ?
there is no indication that I'm aware of that the CSS module
will move on
we could get input from CSS
or we could remove the requirement and replace with something
that is implemented
gkatsev: it would be nice to know from the CSS WG what the
state of the text module is
but even if they start implement it, the best choice is to
remove it
and add it in a new version
nigel: the proposal I would make is to ask CSS WG (Philippe)
and simultaneously to prepare a PR to mark it at risk
any other proposal? objection?
glenn: I just noticed that the text module was modified in ED 3
days ago, so there is active work on it
nigel: that may be a good sign, the last WD was a long time ago
nigel: so we have consensus on what I proposed
we have then 2 actions: one on Philippe and one on Gary
glenn: what is the dependency on the Text module?
nigel: if you search for "text-wrap" you'll find it
level 4
glenn: we should definitely not reference level 4
<nigel> [19]Issue for marking this as at risk
[19] https://github.com/w3c/webvtt/issues/455
glenn: hasn't been modified since April, that's not too long
ago
glenn: balance is defined by the user agent
tex has an algorithm
but even you had support for it, it'd be hard to test
it would be reasonable for an implementation to say that its
implementation of balance does not do any balancing
nigel: filing the line until no more character can fit would
work?
glenn: yes
<nigel> [20]Issue for plh to liaise with CSS WG
[20] https://github.com/w3c/ttwg/issues/50
nigel: next one is about text-combine-upright
<nigel> [21]Email from Pierre about text-combine-upright
[21] https://lists.w3.org/Archives/Public/public-tt/2019Jun/0025.html
nigel: I haven't checked the status in WPT
gkatsev: it is available in most browsers
pal: but it's not demonstrated in the context of WebVTT, right?
gkatsev: the test that is using this property is failing across
all browsers currently
pal: my concern is that in the past the group has gone through
great lengths to make sure that every feature was implemented
by 2 implementations
we should apply the same principle to all specifcations
we should have one set of criteria
if there is no 2 implementation, we should remove it and add
it later on
<nigel> [22]WPT for text-combine-upright
[22] https://wpt.fyi/results/css/css-typed-om/the-stylepropertymap/properties/text-combine-upright.html?label=master&product=chrome[experimental]&product=edge&product=firefox[experimental]&product=safari[experimental]&aligned
gkatsev: for me, the way it is in the spec it is not a feature
in itself
it is a property of the CSS feature extension
and there are tests demonstrating the CSS feature extension
to me the CSS feature extension is working and missing just
an extra property
pal: but the test is failing
nigel: could we ask Apple to have that in a dev build?
gkatsev: I can have a look
nigel: on WPT the text-combine-upright is only passing in
Chrome and Edge
so we might struggle to see 2 independent implementations
that pass it
that might be another reason to mark it at risk
gkatsev: I think the prefix versions are fine
are we ok with grouping the standard version and
vendor-prefixed one?
nigel: I don't know
if an implementation would map the standard version to the
vendor-prefixed one to make it pass, that should be fine
what wouldn't work would be to use the vendor-prefixed one
and testing that because that is outside the spec
gkatsev: I'm not positive on that
the way that CSS has been working
is that once it's get closer to the standard version, it's
equivalent
it's up to the group to decide
but all decisions would be correct
personally, I would prefer to allow vendor prefixes
nigel: it actually depends on the vendor commitment to replace
vendor prefixes
I would have to dig a bit more to see what's acceptable
pal: does the W3C even have rules or guidelines on vendor
prefixes?
nigel: there is an accepted practice
I have not seen anything written down
I've seen implementations behind flaggs
pal: my personal take is to say that if you had to use vendor
prefix to demonstrate interop is awkward
because a user would have to magically add the prefix for a
given implementation
nigel: that would be demonstration of non-interop
a single document would not work
pal: because the CSS is embedded in the document
pal: do the prefixes hold up for ever?
do they go away after a while?
you wouldn't want somebody to create documents that work
today with prefixes but not in 5 years
gkatsev: what you do in WebVTT is the same as in CSS
you put both: standard and prefixed
pal: got it
pal: caniuse.com does not show results for text-combine-upright
my recommendation is to get an initial version of WebVTT out
and put at risk things that don't pass tests
when browsers implement the feature, just update the spec
that's simple, less risky and closest to reality
nigel: it looks like marking it at-risk is simple to do
pal: and easy to add back
nigel: from an alignment perspective, we would have something
in IMSC1.1 and not in WebVTT
pal: yes, but that was not in IMSC1.0
gkatsev: the plan is to have all features that are marked at
risk and removed be put in a new WD so that browsers can
reference that
nigel: your proposal Pierre is to mark text-combine-upright at
risk?
pal: yes
nigel: any objection?
we do have consensus
I'm creating an issue and assigning it to Gary
<nigel> [23]Mark text-combine-upright as at risk
[23] https://github.com/w3c/webvtt/issues/456
pal: as a follow-up question, are there any other feature that
failed to have 2 implementations?
gkatsev: as far as I remember there are no other features who
all of their tests are failing
pal: what's setting position?
gkatsev: I think it's vertical or horizontal
pal: the IR shows only one implementation
gkatsev: that is probably passing in vtt.js
pal: I would suggest doing the same thing for tests that don't
pass
if you go through that table and it says 1, if you can tweak
vtt.js then we would be fine
nigel: there was an action from last week
we had discussions about long and int
gary you were to make a test for int
how are we doing with that
gkatsev: it's on my list
nigel: it's in progress
nigel: I don't think that the CfC can go ahead
we have to in the CR loop again based on the discussion today
pal: it can be fast
nigel: yes
cyril: can we get an agreement that everything that's red
should be marked at risk?
pal: yes
nigel: I agree
gkatsev: marking everything red at risk is simple
pal: if later on it works, you can remove the 'at risk'
gkatsev: not sure about the int vs. long
cyril: what's the likelihood of having 4 browsers change when
they are already interoperable?
nigel: I think we should adopt Cyril's suggestion
because the requirement for long was not very strong
gkatsev: there is an issue of alignment with other specs
cyril: the proposal is to mark at risk all the features that
are red in the IR
nigel: we also need to change the line attribute to be unsigned
int?
gkatsev: unsigned int would pass
nigel: any objection to changing to unsigned int?
no objection, we should resolve to do that
I'm creating an issue and assigning it to Gary
<nigel> [24]Change line attribute to unsigned int
[24] https://github.com/w3c/webvtt/issues/457
nigel: the second proposal is to mark at risk everything that
does not have 2 passing tests
any objection?
none
ok, we'll do a new CR publication
Resolved: Mark any remaining features with tests that don't
have at least 2 passes as at risk
nigel: that's everything on the WebVTT agenda topic
Clarify use of 'applies to' in style property definition tables
(ttml2#1088).
github: [25]https://github.com/w3c/ttml2/pull/1089
[25] https://github.com/w3c/ttml2/pull/1089
nigel: this one is about 'applies to'
we're looking at pull 1089
this PR adds a note
pal: that should be part of the broader discussion
in isolation it makes sense
the real issue is what do we write in "applies to"
glenn: are you asking us to approve or not the whole
collections of PR? as a whole?
the intent was dividing them because they are orthogonal
nigel: if we can't agree on what 'applies to' mean, we cannot
move on
pal: depending on the context of applies to the meaning might
change
nigel: if we know what 'applies to' should mean, then we can
put it
the current proposal says make it say what CSS does
nigel: are you agreeing?
pal: I think we should assume that that's the case and move
forward
let's not merge now
glenn: I think the chair needs to make a determination on how
to move forward
nigel: we have agreement can we move forward?
glenn: Pierre has put a blocker for process reasons and I don't
agree with
nigel: moving forward means having a common ground
is there any objection to adding this text?
hearing nothing, we have agreement in principle
glenn: before you move on, we have 2 approvals on this PR but a
blocker
we need Pierre to remove his blocker
nigel: I'm sure Pierre will remove his blocker
github: [26]https://github.com/w3c/ttml2/pull/1079
[26] https://github.com/w3c/ttml2/pull/1079
github: [27]https://github.com/w3c/ttml2/pull/1089
[27] https://github.com/w3c/ttml2/pull/1089
github: [28]https://github.com/w3c/ttml2/pull/1079
[28] https://github.com/w3c/ttml2/pull/1079
text-decoration
github: [29]https://github.com/w3c/ttml2/pull/1079
[29] https://github.com/w3c/ttml2/pull/1079
pal: I have the same position as on the previous PR, the
proposed text is fine
in fact I integrated it in 1071
same as before for me
nigel: any objection to this text change?
none
we resolve to accept this change
text-emphasis
github: [30]https://github.com/w3c/ttml2/pull/1081
[30] https://github.com/w3c/ttml2/pull/1081
nigel: my comment there was on 1080
I was worried that inline areas that are not glyph areas
would be affected
but you convinced me
so I don't have any objection on this one
anyone objects to this?
none
we've all agreed to this
glenn: can you remove your blocker?
nigel: let's work out removal of blockers later
github, end topic
font selection strategy
github: [31]https://github.com/w3c/ttml2/pull/1083
[31] https://github.com/w3c/ttml2/pull/1083
pal: same as before
nigel: any objection to adding this text?
I think not
everybody is happy with this in principle
we agree to accept that change
font variant
github-bot: [32]https://github.com/w3c/ttml2/pull/1085
[32] https://github.com/w3c/ttml2/pull/1085
<github-bot> cyril, Sorry, I don't understand that command. Try
'help'.
github: [33]https://github.com/w3c/ttml2/pull/1085
[33] https://github.com/w3c/ttml2/pull/1085
pal: same for me
nigel: I don't have an objection
anyone has an objection?
none
we're happy to accept this
text combine application
github: [34]https://github.com/w3c/ttml2/pull/1087
[34] https://github.com/w3c/ttml2/pull/1087
pal: same here
nigel: there was a typo that was fixed
any objection?
no objection
we agree to approve it
Emphasize null style semantics in context of ruby container spans
github: [35]https://github.com/w3c/ttml2/pull/1101
[35] https://github.com/w3c/ttml2/pull/1101
nigel: I summarized it
it adds a note to all the "applies to"
my summary of the debate is whether we need to do it
normatively or informatively
Pierre how do you feel about that at the moment?
pal: I feel like day 1
the practice is to list what a property applies to in this
line
and in the prose to add text
I don't see any reasons to not list the span that it does not
apply to
nigel: you don't see any difference in making it
normative/informative
pal: the practice is so loose in TTML2 that it does not make
any difference
nigel: can you live with the proposal?
pal: it could be expressed more clearly
nigel: glenn, if we said "spans except ..." with an editorial
way
glenn: 1) a span that serves as a ruby container, base
container or text container is not an element
it is no different than a span that is empty
we do not say these properties do not apply to spans that are
empty
2) a span that serves a ruby container is not an element by
the definition that we use or that CSS uses
until we introduced ruby align and ruby position, we did not
have any case that called out a qualified version of an element
we went off-track in my opinion when I wrote that text
if we had not done so (I believe it was an error) we would
not have that conversation
3) there is no normative impact and it's not testable to say
that it does not apply to
.. so it's strictly an informative advice for the reader
that we can deal with through a note
it's not different to other parts of the spec where you have
to follow the text
4) the issue about optimization
we don't document premature optimizations that could turn out
to be false
out of the 18 properties that Pierre wanted to modify I've
determined that 3 do apply
the other 15 are somewhat arbitrary
because for example color could follow the same logic
my original opinion was not to write anything
the note is a compromise
I do not accept Pierre's proposal
we already have a definition of ruby container in the text,
defined in 10-1
<Zakim> nigel, you wanted to say that elements are not
necessarily only defined by their qualified name alone
nigel: it seems reasonable to me to specify elements not only
by name but by qualifying the selection
you say that CSS does not talk about qualified elements
but actually CSS uses whatever is meaningful even if it's not
an element
there is a precedent in CSS
I take your point that there is no normative impact
nigel: do these arguments work for you?
pal: I'm all for finding a compromise
we are very close, because Glenn's latest proposal adds text
to "applies to
we are in the right direction
if that link linked to a specific note not a generic one, and
that note listed those elements to which the style property
does not apply
that might be wordy but explicit and not ambiguous
glenn: what I hear you are proposing is to copy the note 15
times in the text with exact wording
or with just the name of the property substituted
we try to use generic languages
it creates a maintenance issue
pal: I don't disagree, it's wordier
I'm trying to find a compromise
nigel: why do we need those specific notes?
pal: it has to be very clear for everybody whether or not by
reading the applies to line it applies to or not
a generic note does not do that
just like unicodeBidi does not apply to div
glenn: I definitely do not agree with the intent that pierre
stated
that the applies to line be definitive and complete
with respect to the application semantics
I'm convinced that the information in the applies to line has
to be taken in context of the full prose of each style
in XSL-FO appendix B.4
there is generic language
that says that further clarification may appear in the text
<nigel> [[ For each property the formatting objects it applies
to is listed. It should be noted, however, that for some
formatting objects there are qualifications on applicability or
values permitted. ]]
glenn: that's why I'm disagreeing in part with Pierre's
original premice
pal: thanks for highlighting the crux of the issue
past practice in TTML and CSS has been to be exhaustive in
the applies to line
that's the intention of my proposal
it's clear in CSS and TTML that that line has been exhaustive
e.g. unicodeBidi
div is not listed under unicodeBidi
because it cannot apply to div so it cannot be listed there
pal: if glenn's note would list the exact properties that
"might not" apply, that would work for me
I'm not fine with leaving a vague note
glenn: I objected to that because of the maintenance effor
Nigel: if you're not happy with the note propose a change
Pierre: I've proposed alternate text in a separately maintained
PR, or would accept a specific note on each
style property.
Glenn: Here's a suggestion: if we put a note in each of those
15 properties that points to the generic note and says
it applies to this specific property, would that satisfy you,
and have the Applies to line point to that?
Pierre: Yes, I think that would satisfy me. I don't like it
editorially.
Glenn: I'm proposing instead of the "See also" note I could add
a note in each of the 15,
and I would say the generic note applies to this property.
Pierre: Yes
Glenn: That would give you something explicit in each of the
properties
Pierre: Yes and then the note can be more definite
Glenn: I'll tweak this PR to make those changes and we'll see
if we can accept that, and maybe all the related pull requests
too.
Pierre: Sounds good to me.
Nigel: Thank you both for working constructively towards a
solution.
Meeting close
Nigel: We're out of time, thanks all.
Glenn: Regrets for me for next week.
Nigel: Let's try to move forward on GitHub on these.
[adjourns meeting]
Summary of resolutions
1. [36]Mark any remaining features with tests that don't have
at least 2 passes as at risk
Minutes manually created (not a transcript), formatted by
Bert Bos's [37]scribe.perl version Mon Apr 15 13:11:59 2019
UTC, a reimplementation of David Booth's [38]scribe.perl. See
[39]history.
[37] https://w3c.github.io/scribe2/scribedoc.html
[38] https://dev.w3.org/2002/scribe/scribedoc.htm
[39] https://github.com/w3c/scribe2/commits/master/scribe.perl
Received on Thursday, 13 June 2019 18:14:29 UTC