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