- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 4 Jul 2019 16:32:28 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <D943E85C.4850C%nigel.megitt@bbc.co.uk>
Thanks all for attending todays TTWG call. Minutes can be found in HTML format at https://www.w3.org/2019/07/04-tt-minutes.html
In text format:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
04 July 2019
[2]IRC log.
[2] https://www.w3.org/2019/07/04-tt-irc
Attendees
Present
Atsushi, Gary, Glenn, Nigel, Pierre
Regrets
Andreas, Cyril, Philippe
Chair
Nigel
Scribe
nigel
Contents
* [3]Meeting minutes
1. [4]This meeting
2. [5]WebVTT
3. [6][IR] parsing: region lines webvtt#467
4. [7]Emphasize null style semantics in context of ruby
container spans (#1100). ttml2#1101
5. [8]Meeting close
Meeting minutes
This meeting
Nigel: Hi, first of all, welcome to Atsushi, who is our new
team contact
Atsushi: I joined W3C last November, and I am working for 50%
on i18n and the other half on various other WGs
I'm still working for a bunch of other things, but hope I can
work here efficiently. I'm learning about this WG and
its specifications.
Nigel: [introduces Gary, Glenn and Pierre as well as himself]
If you want time to run through things I am available for
that Atsushi.
Atsushi: I'm in listening mode today, I've had an introduction
from Philippe.
Nigel: Agenda for today: some WebVTT, TTML2 issues. We won't
cover Charter status because Philippe has sent his
regrets. Is there any other business or points to make sure
we cover?
group: [no other business]
WebVTT
Gary: I posted two issues on the agenda, we only need to talk
about one.
Yesterday I opened up issues from the currently failing tests
so they don't get forgotten.
One of the tests is failing because when parsing the region
lines value the spec says interpret it as an integer.
Safari and Firefox interpret it differently. I'm not sure it
is easy to test.
Other than this I think the current at risk proposal is good
to go.
[IR] parsing: region lines webvtt#467
github: [9]https://github.com/w3c/webvtt/issues/467
[9] https://github.com/w3c/webvtt/issues/467
Gary: When parsing the WebVTT file with region lines being some
very large value or very small value, that is
outside of the int range, Safari I think returns max integer
but Firefox returns a zero.
I think that is technically correct based on reading the
spec, because it says "interpret as an integer".
Nigel: Which is correct?
Gary: I think both of them are. I don't think one is
necessarily more correct.
There's nothing beyond "interpret".
Nigel: Is that not an interop problem?
Gary: Maybe, and that's why I thought this is worth talking
about, because I'm not sure.
Nigel: Any immediate views on this? I don't have an answer.
Gary: The HTML spec for parsing floating points says if too
large or small to use the closest available number to it.
To me that seems like the correct decision, but at the same
time, basically I guess the question to answer now is
should this hold up the current at risk CR or should we just
get that out and then figure out what to do with this,
alongside everything else.
Nigel: It doesn't help with exiting CR because there's a
failing test.
Gary: Yes
Nigel: It looks like Firefox would need to change if your
instinct is right. Is it worth talking to anyone at Mozilla?
Gary: Yes I can try or ask Philippe to find someone.
Nigel: Sounds like a good way forward.
Atsushi: I have nothing for today, but I also work for i18n WG
and would like to check with them.
SUMMARY: Probable proposal will be to use closest value
algorithm, needs implementor input
Emphasize null style semantics in context of ruby container spans
(#1100). ttml2#1101
github: [10]https://github.com/w3c/ttml2/pull/1101
[10] https://github.com/w3c/ttml2/pull/1101
Nigel: Summary so far is that the existing pull request is okay
in most respects but Pierre asks for similar wording
to be added to 4 further style attributes, and it seems Glenn
is not happy to do so. Let's iterate through them.
First up is tts:unicodeBidi
Nigel: The discussion says it can have an effect - shall we
cross it off the list?
Pierre: No, there's an outstanding question. unicodeBidi has an
effect on the child spans of an element.
I gave two examples where I think the rendering is different
depending on the value of the unicodeBidi property.
But when the span is a ruby container, the two child spans,
like a text container and a base container are rendered
separately and their content should not ever be reordered by
the unicode bidi algorithm because they're on different lines
so I'm fairly certain that the computed value of unicodeBidi
cannot have an effect on a ruby container. The two
children, the base container and the text container are
rendered entirely separately.
Glenn: That discussion ignores the fact that there are 3
different containers we are talking about, the top level,
the base and the text. It clearly applies to the base and
text containers because they can contain multiple bases and
texts.
In edge case scenarios potentially the top level container
arguably does not have a semantic application.
Pierre: I don't agree with that.
Glenn: The other point is that even if the top level container
does not have that effect normally, if you are actually
rendering two separate inline boxes for the ruby text, that
argument ignores the fact that the delimiter function and
the fallback functions make use of inline ruby in which one
does have a potential bidirectional semantic. In that case
it does apply. The same thing is true for wrapOption and
direction. All three of those style attributes have cases
where they could have a semantic application.
In any case I thought we had a compromise from a few weeks
ago to go ahead with the 15 styles where I did add the
note even though I was extremely unhappy to do so. Now in the
last couple of weeks Pierre has come back and asked
for more and still seems to ask for more with color.
At this point I will not accept any new notes in any other
style attributes.
Nigel: Entrenching your position is really unhelpful for
getting to a resolution. We can discuss the technical merits
Pierre: If there are multiple base containers and text
containers within a ruby container I don't think unicodeBidi
should
apply across the text containers because each is only
associated with one base container.
Glenn: There is a base container and a base ruby.
Pierre: Sorry, if there are two base containers and they each
have a different bidi position before and after then it
doesn't apply, right?
Glenn: There are technical scenarios where based on context you
could come up with a theory that there isn't anything
to apply it to, but does that require a note to the reader? I
strongly disagree with that, and that's been my contention
from the beginning, that none of these notes is making any
different whatsoever.
This is a note about optimisation. I'm not going to move on
this. If you want to add more I prefer going nowhere.
Nigel: I've asked once, please don't restate or entrench
position, let's have a technical basis for the decisions we
make.
Pierre, you don't seem to have responded to the point about
there being no delimiter.
Pierre: It's complicated [shares screen]
[11]ruby attribtue
[11] https://www.w3.org/TR/ttml2/#style-attribute-ruby
Pierre: The note shows the nesting model
Glenn: The fallback scenario is well defined.
Pierre: You should never reorder across ruby text and base ever
though.
Glenn: Users may want to.
The purpose of the style property unicodeBidi and direction
is to provide an alternate way to override the unicode
characters
for bidi. There's nothing to stop users using those unicode
characters.
We have to make sure that both representations can translate
to each other for example TTPE.
Pierre: Unicode reordering does not apply across divs, right?
Glenn: It does apply divs, yes, and across boundaries.
I don't know a good user case for it. You can do it in CSS,
and in plain text characters you can do it using explicit bidi
controls.
Pierre: Today unicodeBidi does not apply to div, so how can a
property apply across divs but not to divs.
Glenn: I agree that's not a good one to talk about. Let's say
p.
You're right about divs. But we don't say they don't apply to
div
Pierre: unicodeBidi does not apply to div
Glenn: I'm sorry I was wrong, you're correct.
Reminder about the "presentation related element" term that
is used in one of the algorithms.
We defined it as something that affects the presentation of
content, but we did not define an algorithm for how to
determine whether an element can affect the presentation of
content.
When we adopted this language we discussed the issue of how
to determine it and we agreed that unless
an implementation can prove it does not affect presentation
then it should assume it does.
We left it to the implementations to optimise what to prune.
You've basically brought this back into play, to come up with
an algorithm to come up with corner cases.
Pierre: It's not an optimisation.
Glenn: It is only an optimisation. For me we should only be
talking about elements.
This discussion is the same as the one we had for
presentation related element content.
I don't understand why you're spending so much time on this
trivial issue that is an optimisation. I plan to ignore it,
it doesn't even matter.
Pierre: It does, we're talking about unicodeBidi applying
across elements, so it could lead to different results so it
does matter for interop.
This is complex stuff.
Glenn: I haven't seen any users bring forward non-interoperable
content. Do you have any bug reports?
Pierre: Yes that's exactly what led to the issue in the first
place, with respect to underline on a ruby container span.
Glenn: That was a real bug in the spec we have fixed already.
Pierre: This is actually because of a bug report on what
applies to a ruby container span.
This is opened the door to what does apply to ruby container
spans.
Glenn: I don't think we should be going down this road of
premature optimisation.
Pierre: It's interoperability. The bug is that the spec was
unclear and we are clarifying it for better interop.
Glenn: The only real bug was about white space that was
potentially considered significant when xml:space=preserve is
used.
Pierre: No that was not the only bug.
Nigel: We're trying to work out if the spec is clear about the
layout of ruby with unicodeBidi.
Pierre: Specifically the container : base text example.
Nigel: I'm concerned here about if there is an ambiguity that
means that two implementations could both seem to be
conformant to the spec but render text in a different order,
changing the meaning, in which case we need to clarify it.
Glenn: I'm concerned about overspecifying, I think we may get
it wrong.
Nigel: Can we merge what we have and open a new issue about
this ruby layout complexity?
Pierre: color is really simple.
Coming back on the point of a compromise that I've reopened,
I raised the point about the other attributes on the original
review.
Glenn: I'm at the take it or leave it stage.
Pierre: I'm happy to take over editing the pull request and
come up with one we can vote on.
Glenn: I'm going to object to it so it will be put on hold. I
already objected to your pull request.
I think you've overstepped your prerogative.
Pierre: I'm a member of this group.
Nigel: I'm seeing no overstepping.
Pierre: I'm raising this for interop reasons.
Glenn: If we go to the CSS WG and ask them for their CSS ruby
model and they have a firm answer to it I am willing to
look at it again. I'm not prepared to make statements we
don't have agreement for.
Pierre: What about color? It's the same as textDecoration.
Glenn: Why didn't you raise it in the first place?
Pierre: I had suggested some elements and you took the liberty
not to take some into account and I'm bringing them up again.
I'm trying to do this based on technical reason.
Nigel: Does the note apply to tts:color?
Glenn: In the same way as it applies to any empty span.
Nigel: So it does apply.
Glenn: The context means some attributes do not apply.
Nigel: I have a proposal: let's add color to this PR, merge it,
and open a new issue for wrapOption, unicodeBidi and direction,
and go
to CSS WG and i18n as Glenn suggested.
Glenn: Alternative proposal: accept these two PRs as they
stand. Open a new issue for color and view that on its own
merit,
and it there's some technical argumentation for the other
three, then open new issues for those separately.
So far I've not seen any argument that says what we have
right now is unacceptable.
Nigel: Unless you think there's a technical argument against
adding the note to color then we should include it.
Pierre: I'm happy to do that editorial work.
Nigel: Ok please go ahead on the same PR
Glenn: I will put an objection on that pull request if you do
that
Nigel: Okay if you want to make an objection, make it well
formed with a rationale.
Glenn: It's a process objection
Nigel: I don't want to spend another hour discussing this. The
unicodeBidi issue needs to be raised separately and
warrants further discussion but we've spent long enough on
this that I think we're approaching the point where I will
need to make a call as Chair and let us move on with our
lives.
Meeting close
Nigel: Thanks all for attending, especially those in the US on
4th July. [adjourns meeting]
<atsushi> nigel, thank you on that. I try to catch up items
shortly
Minutes manually created (not a transcript), formatted by
Bert Bos's [12]scribe.perl version Mon Apr 15 13:11:59 2019
UTC, a reimplementation of David Booth's [13]scribe.perl. See
[14]history.
[12] https://w3c.github.io/scribe2/scribedoc.html
[13] https://dev.w3.org/2002/scribe/scribedoc.htm
[14] https://github.com/w3c/scribe2/commits/master/scribe.perl
Received on Thursday, 4 July 2019 16:32:54 UTC