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]
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.
github: 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
github: 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]
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.
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