- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 8 Oct 2020 18:59:21 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <CBF2FFD3-4D92-4DD7-9E10-67590E5A7725@bbc.co.uk>
Thanks all for attending today's extended call. Minutes can be found in HTML format at https://www.w3.org/2020/10/08-tt-minutes.html
In text format:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
08 October 2020
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2020/10/01-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/151
[4] https://www.w3.org/2020/10/08-tt-irc
Attendees
Present
Andreas, Atsushi, Fantasai, Gary, Glenn, Nigel, Pierre
Regrets
Cyril
Chair
Gary, Nigel
Scribe
fantasai, nigel
Contents
1. [5]This meeting
2. [6]Interaction between tts:writingMode and tts:direction on
paragraph element. w3c/ttml2#1211
3. [7]Virtual TPAC 2020 Planning
4. [8]switch to dated links for non-dated patent policy links
#156
5. [9]Meeting close
Meeting minutes
This meeting
Nigel: Main topic for today is the TTML2 issue on writing mode
and direction
… We also have an AOB from Atsushi about our patent policy
links, which I will put off to the end.
… Placeholder for virtual TPAC but the main thing to mention
there is that we don't yet have
… a schedule for a joint meeting with CSS, which somehow
slipped through the cracks.
… Work is in progress to try to set that up, but appreciate
that the notice will be short at this
… stage.
… Any other business to raise?
group: [no other business]
Interaction between tts:writingMode and tts:direction on paragraph
element. w3c/ttml2#1211
github: [10]https://github.com/w3c/ttml2/issues/1211
[10] https://github.com/w3c/ttml2/issues/1211
Nigel: [introduces topic] Any other points that are important
here to get to a conclusion?
Glenn: Difference of opinion between me and fantasai about
getting to equivalence by wrapping
… text in bidi control characters. Given that we do not have a
test case in terms of data
… and we don't have actual test suite or device to test such
data against, we don't have
… anything to evaluate to determine whose opinion is correct.
Nigel: I'm not seeing the application of the bidi algorithm as
central to this issue.
palemieux: [shares screen] Here's a testcase. How should it be
rendered?
glenn: this is a question on the semantics of 'direction' as it
applies to P
glenn: I'd pointed out in my comments that there are two
scenarios for use of direction in P
glenn: one is when it appears by itself, the other is when
appearing in combination with unicode-bidi property
glenn: semantics of P only appear to apply when ...
glenn: only pertain to P unrelated to its combination with
unicode-bidi
glenn: Originally we defined direction and unicode-bidi
together, in CSS2.0
glenn: We copied from XSL:FO 1.0
glenn: And applied to span and P as well, but really didn't go
into semantics of it in the case of SPAN or P
glenn: For some reason, we allowed to apply to SPAN and P but
didn't talk about semantics very much
glenn: Now we have situation where we have unicode-bidi
applying to both SPAN and P
glenn: and direction applying to both SPAN and P
glenn: But we subsequently redefined direction on P to apply
only to the semantics of defining the paragraph level for UAX9
on P
glenn: and when we did that, we neglected to notice that we
also had the case of it applying in combination with the
unicode-bidi property on P
glenn: What we now have is a case where, if you put direction
on P, and you also have unicode-bidi on P, what does that mean?
glenn: Does that mean the direction applies to the paragraph
level? Or direction is supposed to be used in combination as
for SPAN
glenn: definition of direction in TTML, pretty clear that
direction use on P does not apply to unicode-bidi
glenn: so unicode-bidi property is just there, has no
connection with P
glenn: so we do have a technical issue
glenn: Asking question of what this means, we have technical
issue in this spec
glenn: Another problem fantasai points out, if we didn't have
this technical problem, suppose hypothetically that this was
equivalent to what we'd do with a SPAN, and you tried to map
that to a P in CSS, now you have problem of CSS not defining
what override is on P in CSS
fantasai: For the record, CSS does define this
glenn: So that's a separate problem
CSS spec - [11]https://www.w3.org/TR/
css-writing-modes-3/#text-direction
[11] https://www.w3.org/TR/css-writing-modes-3/#text-direction
nigel: If we think about TTS direction on P, how it might
affect the unicode-bidi algorithm
nigel: Glenn, you made a proposal that unicode-bidi should not
apply to P in TTML, which resolves the issue that you just
raised?
nigel: Another question was raised on the thread about the
inline progression direction
nigel: XSL and CSS do take the 'direction' property to define
the inline progression direction
nigel: And TTML doesn't say that it does. It only says that
writing-mode sets the inline progression direction
nigel: But that looks like a weird omission, and is a source of
difference that gave rise to a lot of the discussion on this
issue
nigel: I wonder if it was an accidental omission
nigel: and direction should affect the inline progression
direction as it does in XSL and CSS
nigel: If it did, if it were intended all along, then
everything else would make sense
nigel: And all the other properties that depend on inline
progression direction would fall into line and behave correctly
nigel: So that was my thought, that perhaps we ought to be
modifying the text of tts:direction to say that it does in fact
set the inline progression direction
glenn: It was not an accidental omission on my part. It was
intentional that it did not apply
glenn: If you go back and read XSL:FO, I think you're missing
some text where the context you quote
glenn: Says the language only applies when writing-mode applies
to the object
glenn: So that quote that you make, where 'writing-mode'
establishes ...
glenn: That is true for when 'writing-mode' applies to the FO
object at hand
glenn: In this case the 'writing-mode' property does not apply
to P, and only applies to regions in the case of TTML
glenn: The 'writing-mode' property does not apply to P
glenn: That's the problem with your argument
nigel: The text says the 'direction' property is used for FO
objects that generate inline areas that are also not reference
areas.
nigel: So talks about what direction does when applied to P
nigel: You might be right about writing-mode, but we're talking
about direction.
glenn: P doesn't generate inline areas, it generates block
areas
atai: It's difficult, the use of "inline progression
direction". Not clear when it applies
atai: For example, inline progression direction sets
directionality of edges, where start/end applies
atai: Also applies to unicode bidi algorithm
atai: It's clear in TTML that edges are only set by
writing-mode
atai: and direction, inline-progression direction, and unicode
bidi algorithm
atai: I think that's OK, direction isn't specified on region
atai: writing-mode is taken as the value, and inherits
atai: If direction is set on region, then the direction of
region is taken into account
atai: But direction, as glenn said, only for inline objects
atai: but doesn't change how inline progression direction
applies to regions
glenn: writing-mode establishes inline progression direction of
the [?]
glenn: and writingMode establishes inheritance
glenn: goes down to paragraph, so that paragraph inherits right
value of 'direction'
glenn: that ultimately comes from region inhertance
glenn: So 'direction' affects what gets inherited, and can be
overridden by direction on P
glenn: but as far as areas generated by P, those are block
areas
glenn: Anyway as for intention, I did not accidentally omit.
glenn: Might go back and reconsider, but it was intentional.
glenn: We noticed that there was language in XSL had the
additional semantics of setting the base level of the paragraph
for the bidi algorithm
glenn: We processed that issue, so there must be a record of us
processing that issue
glenn: unicode-bidi property also applies to P, what does that
mean, do we have a conflict now that we say that 'direction'
can mean something by itself? Should we have left in the
possibility of having both direction by itself and direction in
conjunction with unicode-bidi?
atai: I would like to bring this together with example that pal
put up at the beginning
atai: What does direction mean when specified on a P
atai: would be good to get a common understanding of what this
means
nigel: If we do have a deliberate divergence from the
definition of direction as it is defined in the specifications
from which the TTML rendering model derives, we should call it
out and explain why
nigel: It's unclear to me why we would have this divergence.
nigel: We should also be sure that this is the primary
difference in what is defined in TTML vs CSS
<Zakim> fantasai, you wanted to answer that question
fantasai: No, the wrapping of content to the paragraph in an
embedding is not the same as
<fantasai> [12]http://software.hixie.ch/utilities/js/
live-dom-viewer/?saved=8562
[12] http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=8562
fantasai: setting the embedding level on the paragraph as well.
It's not just about the algo
… but also the outcome of it.
… test case above.
… Trailing whitespace is handled differently for example, it
has special handling wrt the
… paragraph level. You cannot get the same effect.
… Second, there's a q what does unicodeBidi mean on a p.
… In CSS, if you set unicodeBidi on the paragraph level nothing
happens if you set direction,
… unless you set unicode-bidi to override, in which case [???]
… It's not that there's no effect, but that the differences are
relevant at the edges.
… Whether wrapped in isolate or embed makes no difference
because the interesting thing
… is what happens outside that. So in CSS unicode-bidi does
affect block level elements,
… so you could say it applies but in some cases has no effect.
… WRT the direction property and whether it affects IPD, this
is the key issue.
… In CSS there's no concept of different direction vs IPD. We
didn't think there was any reason
… for them to diverge so that isn't supported in CSS. If you
want them to diverge you should
… have a use case. I can't think of any. It does seem to me
that XSL does the same, so if you
… diverge then you'd be divergent from both XSL and CSS.
… Does XSL-FO define any elements that define a block area to
which writingMode does not apply?
… That's a question I have that I don't know the answer to.
Glenn: writing-mode does not generally apply to block elements
in XSL.
glenn: it applies to higher-level constructs that construct
page-level region type features
glenn: for organizing page layout, into which blocks are
placed.
glenn: blocks tend to be children of higher-level constructs
glenn: Is there any way to set the paragraph-level in CSS
independently of direction?
fantasai: paragraph-level base direction is set by 'direction'
glenn: So the UAX9 direction and inline progression direction
are bound together
fantasai: yes
fantasai: Question, what would it even mean to have them
diverge, and why would you want to do it?
atai: As I read the HTML recommendation, I read that the use of
markup to set writing direction instead of CSS where possible
atai: What glenn mentioned, explicit bidi control codes, should
these be used at all?
fantasai: HTML dir attribute is defined to be mapped to CSS
'direction' property
fantasai: we strongly recommend to HTML authors to only use
'dir' attribute, not CSS
glenn: but authors might not follow that advice, could be mixed
up
fantasai: yes, and the results are dictated by the Cascade
glenn: So you have to use both arbitrarily, and you have to map
one of those techniques to the other in order to be consistent
glenn: What I've done in the past was to map all directional
formatting characters to style or vice versa, to have a
consistent data model to work with
fantasai: Yes, and CSS model requires that.
fantasai: CSS direction sets the paragraph embedding leve
fantasai: don't use the UAX9 heuristic unless opt-in via
'unicode-bidi: plaintext'
fantasai: but the rest of the CSS bidi controls are mapped to
bidi control codes and passed to UAX9 algorithm
fantasai: if you're mixing markup and control codes in your
source, this could get weird, but we do map it all into one
system
nigel: setting 'direction: rtl' and setting dir=rtl clearly
behaves the same
nigel: Question implicitly stated earlier, but not properly
asked
nigel: what's the use case for having a different value for
inline progression direction from the paragraph embedding?
nigel: I don't think so far anyone has proposed such a use
case.
nigel: So there doesn't seem to be one
nigel: If we were to make a change here, it would be a breaking
change, because if there is someone who has authored
documents...
nigel: that depend on this difference, that would present
differently
nigel: But I suspect the state of implementation on this is not
so solid anyway.
pal: Certainly in the case of TTML, no one I know of has run
into this case.
pal: Now is the time to make a change if we want to make a
change.
glenn: What kind of change do you have in mind?
pal: The only point I wanted to make is that now would be a
good time to make a change if we're going to make a change.
pal: Just wanted to note that I don't think this is broadly
deployed or broadly used
glenn: Don't know about content out there
pal: Yeah, but based on folks we've worked with, sample content
we've seen, either this is not deployed or least of anybody's
worries.
glenn: Don't know how many ppl are trying to convert TTML to
CSS
<fantasai> pal: In my observation, I don't think we would be
breaking people's content meaningfully if we made a change for
interaction of direction and unicode-bidi on P
<Zakim> fantasai, you wanted to make proposal
fantasai: A straightforward thing to do would be to clarify the
interaction between unicodeBidi
… and direction on p to match what CSS does.
… Another is to state that the direction property sets the ipd
overriding whatever is set by
… writingMode, so it is a more specific control.
… Set both, direction wins, set one, then the one you set wins.
… Two ways to do it in terms of inheritance. Safest way
probably would be to say that you
… do the mapping first and then inherit.
… The difference would be if you set both writingMode and
direction on an ancestor then
… both would inherit through to the child. If the child sets a
different direction it would
… override the parent. If the parent didn't set [xxx]
… There may be a choice if the child overrides...
Glenn: [interrupts] there's already a detailed section about
how to do the inheritance and
… compute the value.
… Only applies to region, so we already have that.
fantasai: OK, so you just need to specify that direction does
set the ipd.
Glenn: It is §10.2.12.1 by the way
nigel: That's two proposals. I think they both seem to match
what CSS does, and I think also what XSL does. Takes away one
of the divergences if I understood right
nigel: We mentioned the incompatibility that might produce, and
lacking statistical data. Anecdotally, not going to trip
anybody up with this.
atai: Third option, quite radical
atai: I understand how it was meant, but this is different
issue
atai: But super difficult for a user to apply because not so
many TTML experts
atai: Most people are coming from CSS, so difficult for them to
understand
atai: Third option that was mentioned was to not only disallow
unicode-bidi on P or say that it doesn't apply, but also say
that 'direction' doesn't apply.
atai: I think from functionality we won't lose anything
atai: Having direction on P, instead use on inline elements.
fantasai: That is much more likely to break existing content
because if people are using it
… on p then it will stop working. There are differences in
rendering, not just theoretical ones,
… so I don't think you'd get the right behaviour, so that would
be a very bad option.
glenn: If we're going to allow direction on P to change inline
progression direction on P, then need to do the same on DIV and
BODY and potentially SPAN as well
pal: We don't have to
glenn: It would be asymmetric to do otherwise. All part of the
inheritance hierarchy
glenn: Having it be special on P would be confusing / weird
nigel: But it doesn't apply currently.
glenn: That's true, they're just inheritable items
glenn: OK, so I guess because we have text-align and
border/padding applying to P, that's why this might be relevant
there.
atai: You're absolutely right in terms of specification and
compatibility, you're right
atai: But hard to get empirical data that, I hadn't seen people
using unicode-bidi and direction at all
atai: And doubt they apply to P
fantasai: unicodeBidi on p might be rare but I doubt direction
woul dbe that rare
atai: But seeing how long we discuss on this thread, even if
people use it, what is the intent actually?
atai: Specification group, after publishing it, coming to
agreement on how this applies, how are the users going to
udderstand
fantasai: Users have a much easier job because all they're
doing is saying if the p is rtl or ltr primarily
… and set writingMOde or direction appropriately.
… They're not thinking about all the complex implications, or
thinking about how it works.
… It's the implementor's job to figure out how it works. THere
are countless hours
… spent figuring out how the unicode bidi algo works, mapping
to HTML etc.
… Users just have to label the content appropriately.
nigel: Feels as though on this call, seems we've ended up in
place of understanding what the spec says now and what the
divergence is from CSS, and proposal for two actions to take to
address it and clarify
nigel: From those points, has anybody been holding back any
questions?
glenn: I haven't seen the text of the proposals, so haven't
reviewed the text of the proposals.
glenn: I would like to withhold my final comment
nigel: of course, we can all review things
glenn: I would like to talk about the strategy and timing
nigel: On the substance of the issue, though, are there
unresolved questions or comments?
nigel: I'm only aware of one, mine, possibly handle later
nigel: In the section on writing-mode in the spec, there's an
example fragment
nigel: that's a region that sets a region to tbrl, but the text
appears to have an LTR direction
glenn: RL in this case means right-to-left lines. Block
progression mode is right to left. Top to bottom inline
progression mode
nigel: So writing-mode does apparently affect the inheritance
of 'direction', we saw that earlier in the section on
'direction'.
glenn: Mapping from each value of 'writing-mode' into the
corresponding direction isn't specified.
nigel: You're saying that in tbrl ...
glenn: RL there is not the same as RTL in direction
glenn: RL means the block direction
nigel: That mapping isn't defined, not listed anyonere.
nigel: Means lines are being laid out on their side. It's a
vertical mode
nigel: If I'm reading this and trying to understand what is the
value of 'direction' I'm trying to derive from this, hard to
tell
nigel: tbrl doesn't mean rtl, how do I know that?
glenn: It has nothing to do with bidi
nigel: So inline progression direction determined, according to
specifics
nigel How is it mapped?
glenn: top-to-bottom would be LTR basically
glenn: It would depend on the rotation of the text
glenn: If the text were zero-degress oriented, clockwise
glenn: Depends on the orientation. If the orientation is
upright, then you can't tell.
glenn: If the orientation is 90deg, then it would be LTR from
bidi perspective.
glenn: If orientation is 270deg then it would be RTL
nigel: We have mixed, sideways, and upright
glenn: You'll have to go back to XSL:FO definitions
fantasai: writingMode rl => rtl and everything else to ltr
probably
… tbrl and tblr probably should not set direction at all, just
allow it to inherit
Glenn: You might find some example images inside the XSL-FO
spec. I recall seeing some there.
… You would have to know the orientation angle to accurately
interpret that.
… Elika's heuristic is probably a good one.
fantasai: The orientation mixed/upright/sideways, in CSS, if
orientation is upright, which
… forces even rtl letters to be upright, then direction is
forced to ltr regardless of value
… so when you run bidi everything is laid out top to bottom.
You don't have to worry
… about that in TTML - the CSS definition will take care of
that.
Glenn: That makes sense, it wouldn't make sense in say Arabic,
unless you're doing something
… where the letters aren't connected anyway.
fantasai: Yes, if you force upright in Arabic then you go top
to bottom.
nigel: So seems like two proposals here, not clearly written
down, but clear to me what those proposals are
nigel: Glenn, you wanted to mention strategy. Which version of
the spec we should make changes to?
glenn: My suggestion would be to give fair warning that a
change is coming in 2nd Edition
glenn: Add some informative material, but not actually make a
substantive change here.
glenn: I think it's too late to make this kind of change in 2nd
Edition. That's my opiniont.
pal: I would even go one step back and say, the first step is
to actually capture what the proposed solution is as an issue.
pal: Let's capture what the change is, so implementers can
experiment with it
pal: And when we feel it's ready to merge into the spec we can
see where we are.
glenn: Agree this issue is getting too wild.
pal: Maybe someone can make a proposal as a PR against this
issue. Lable it WIP/Do not merge. Take the time to make sure it
works
pal: We can merge it when we're ready
glenn: Against this issue ?
pal: My goal is to find a solution that works
glenn: This issue has many sub-issues.
pal: This edition of spec, but brand new issues
<nigel> fantasai: Two issues, one for ipd from direction, the
other for unicodeBidi on p
nigel: Sounds sensible.
nigel: Already discussed outcome of this meeting. once we've
captured clearly like this, let's run it by CSS and i18n
nigel: If we can get time with them in the next couple weeks,
can get the issues logged. Seems feasible.
nigel: Another question of what to do in specific versions.
Let's have an aside to think about impact of change.
nigel: Impact of change to users if we make a change directly
instead of signalling.
nigel: Also an impact if we don't make a change.
nigel: Also a question of process, if we make a normative
change to TTML now
nigel: Might need to go back to CR. Don't think we need to go
back to WD.
nigel: That would incurr minimum period to move to PR. But that
said, we're not ready for PR yet anyway
pal: Suggest not talking about process today, instead let's
craft the issues.
pal: Since we have all the experts on the line
pal: From my perspective, I'd love to be able to implement
those solutions ASAP
pal: Make sure it can be implemented, and get user feedback
asap
glenn: I have to run off. I think I've got enough information
that I can start moving ahead with crafting a new issue or
issues.
glenn: I'll consult with fantasai and pal if that's OK
pal: Yeah, go ahead!
pal: Best to do next few days, so we can review through TPAC
joint meetings
nigel: Next week would be too long
fantasai: I can help by filing the issues, and then can figure
out the wording later
nigel: Main thing is capturing it
fantasai: We could file the issues at a high level, and you can
work on the wording as a follow-up. Does that work?
fantasai: Propose to file the issue, then you can take the lead
on the editing. Work for you Glenn?
glenn: OK
nigel: OK, that's the plan.
fantasai: happy to stay on and draft issues
… paragraph one and unicode is easy
pal: do it now?
<fantasai> [13]https://www.w3.org/TR/
css-writing-modes-3/#text-direction
[13] https://www.w3.org/TR/css-writing-modes-3/#text-direction
group: [drafts issues] (Glenn left shortly before doing this)
Nigel: Raised #1212
<atsushi> [14]#1212
[14] https://github.com/w3c/ttml2/issues/1212
Nigel: And #1213
[15]#1213
[15] https://github.com/w3c/ttml2/issues/1213
SUMMARY: Agreed to raise follow-up issues on the application of
unicodeBidi to p and on the application of direction to p
Virtual TPAC 2020 Planning
Nigel: Next week we don't have a usual call, we have a joint
meeting.
atsushi: I pasted a link on #139. Please visit the TPAC meeting
page for links to zoom calls.
Nigel: We are working on a schedule for meeting CSS WG, and now
I think we may want to
… bring i18n into that as well, or possibly separately.
switch to dated links for non-dated patent policy links #156
github: [16]https://github.com/w3c/ttwg/issues/156
[16] https://github.com/w3c/ttwg/issues/156
atsushi: I listed our specifications in /TR which have
non-dated patent policy.
… 1st q: Do we want to fix that with dated links?
… 2nd q: If yes, we need to go to call for consensus to request
replacement of published Recs.
fantasai: I think that if you have a bunch of already published
things it would make sense
… to ask for permission to edit those in place because pointing
existing Recs to new patent
… policies which have not been made active yet would make
sense.
… You might want to check in with Wendy. You should not try to
replace the documents,
… just republish those links.
atsushi: I mean in-place republishing.
fantasai: I would check with Wendy
Pierre: I'm not even sure why this WG has a choice here.
atsushi: Other groups' specs also use non-dated links to patent
policy.
… Respec has 2017 and 2020 but bikeshed does not.
… It is not a q just for TTWG but for all W3C.
fantasai: That's an interesting question. I will check in with
Tab about that for bikeshed.
… We are going to need that over the next year.
atsushi: In any case my proposal here is let us contact Tab or
Wendy or someone else about
… what to do for our published ones and let me come back to
this WG.
Nigel: Thank you. I agree this seems like a W3C-wide issue.
fantasai: you should definitely contact Wendy about existing
specs.
… I will take care of filing an issue against bikeshed.
SUMMARY: @himorin to ask @wseltzer how to proceed
Meeting close
Nigel: Thank you everyone, that was a really productive
meeting. [adjourns meeting]
Minutes manually created (not a transcript), formatted by
[17]scribe.perl version 123 (Tue Sep 1 21:19:13 2020 UTC).
[17] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 8 October 2020 19:04:28 UTC