23:40:37 RRSAgent has joined #epub 23:40:37 logging to https://www.w3.org/2020/11/12-epub-irc 23:40:39 RRSAgent, make logs Public 23:40:41 please title this meeting ("meeting: ..."), dauwhe 23:40:51 Meeting: EPUB 3 Working Group Telecon 23:40:58 Date: 2020-11-12 23:41:31 Chair: Shinya Takami 23:54:08 Guest+ dauwhe 23:56:46 shiestyle has joined #epub 23:58:16 MasakazuKitahara has joined #epub 23:58:57 MattChan has joined #epub 23:59:38 florian has joined #epub 23:59:49 present+ 23:59:58 present+ 00:00:05 present+ 00:00:19 toshiakikoike has joined #epub 00:00:47 present+ 00:00:58 present+ 00:01:36 jyoshii_ has joined #epub 00:01:56 present+ 00:02:07 rkuroda has joined #epub 00:02:37 naomi has joined #epub 00:02:40 present+ 00:02:44 Nellie has joined #epub 00:03:45 scribe+ dauwhe 00:03:54 shiestyle: welcome everyone 00:04:06 Topic: align-x-center 00:04:11 github: https://github.com/w3c/epub-specs/issues/1380 00:04:51 shiestyle: this is not supported by major reading systems 00:05:03 ... and perhaps not very many files use this? 00:05:13 +q 00:06:05 ack toshiakikoike 00:06:21 toshiakikoike: proposed on github 00:06:43 https://github.com/w3c/epub-specs/issues/1380#issuecomment-719108924 00:06:59 ... every reader can implement 00:07:52 toshiakikoike: this feature is supported by voyager reading system, but not many epub files use this feature 00:08:15 ... he expects epubcheck would not mark as error 00:08:28 q+ 00:08:50 q? 00:09:00 ack dauwhe 00:10:23 dauwhe: not sure how epubcheck will deal with properties... it actually might be easier 00:10:49 ... am I correct that people don't really see this as necessary 00:10:55 shiestyle: yes 00:13:18 Proposal: deprecate rendition:align-x-center 00:13:31 +1 00:13:32 +1 00:14:04 0 00:14:28 0 00:14:30 +1 00:14:35 +1 00:14:35 +1 00:14:47 Daihei has joined #epub 00:14:51 Present+ 00:14:56 +1 00:16:04 Resolved: deprecate rendition:align-x-center pending confirmation on NA call 00:16:46 q+ 00:16:51 topic: https://github.com/w3c/epub-specs/issues/1389 00:17:48 ack dauwhe 00:18:16 q+ 00:19:12 ack florian 00:19:17 dauwhe: this was done deliberately 00:19:32 florian: there were several kinds of changes to writing modes between its reference and rec 00:19:39 ... some are easy to deal with; some less so 00:19:50 ... from a behaviour change, there hasn't been much, if we ignore the syntax 00:20:04 ... there is one part which has changed a lot, but it's the detailed, nuanced part 00:20:15 ... and I doubt that epub readers implemented the correct part 00:20:25 ... the old behaviour was badly defined 00:20:30 ... about sizing elements with mixed elements 00:20:53 ... automatic sizing inside horizontal text inside vertical text, for example 00:21:03 ... I would be surprised if that was a problem 00:21:13 ... but there have been syntax changes 00:21:31 ... we might need to maintain a list of aliases 00:21:41 ... and just document that 00:21:55 ... more tricky is that some features have been removed 00:22:03 ... hopefully they haven't been used 00:22:13 ... some features were moved to level 4 00:22:34 ... text-combine-upright: digits was moved from level 3 to level 4 00:22:45 ... and this one may still change because browsers have not yet implemented 00:22:55 ... so if you document the syntax in the EPUB spec 00:23:05 ... and then say for behaviour look to writing modes 00:23:14 ... the trickier one is the complete removal 00:23:45 https://w3c.github.io/epub-specs/epub33/core/#sec-css-prefixed-writing-modes 00:23:54 q+ 00:27:31 florian: [makes same points (presumably!) in Japanese] 00:30:10 ack dauwhe 00:32:22 dauwhe: so we can just point to the current spec, and identify aliases to current syntax and behaviours 00:34:05 dauwhe: I think there's work for the editors to do to clean up this section, then we can get feedback from the wg 00:34:27 shiestyle: that sounds good 00:35:05 Topic: Patent Policy 00:35:23 shiestyle: w3c released a new patent policy right after this WG was chartered 00:35:30 ... so we are officially using the old patent policy 00:35:38 ... but we could switch to the new patent policy 00:35:51 ... so I invited Florian (from the W3C ab) to explain the new policy 00:36:11 florian: one main difference between old and new 00:36:28 ... with the old policy, when you reach CR, you get asked if you have any patents you want to exclude 00:36:41 ... if you say you won't give a license, then a special group is formed 00:36:57 ... if you don't answer, or say it's ok, you promise to license them to everyone at no cost 00:37:10 ... you don't make this promise immediately; only when the spec becomes REC 00:37:25 ... so there's no license during CR; just a promise for a license later 00:37:39 ... with the new policy, same thing--you get asked at CR 00:37:58 ... but if you're OK with the patents at CR, you license them immediately (rather than waiting until REC) 00:38:23 ... another minor difference: when the old policy was written, people imagined that one WG produces one REC, then it's over 00:38:39 ... they did not consider groups publishing multiple or updated specifications 00:38:45 ... so there was ambiguity 00:38:57 q+ 00:43:58 ack dauwhe 00:45:02 Dauwhe: we have multiple specs. does it make sense to move to the new policy? 00:45:18 florian: yes. with multiple specs, there is potentially an issue... it would likely work out 00:45:37 ... the old patent policy is not clear about the same spec going to rec multiple times 00:45:44 ... especially if some people leave the group 00:48:08 Proposal: move to the 2020 patent policy 00:48:39 +1 00:48:43 +1 00:48:47 +1 00:48:50 +1 00:48:54 +1 00:48:57 +1 00:48:59 +1 00:49:21 +`1 00:49:25 +1 00:49:27 Resolved: move to the 2020 patent policy 00:50:05 Topic: unsupported features 00:50:20 shiestyle: deprecated features: authors are strongly recommended not to use 00:50:27 ... reading systems may support 00:50:43 ... legacy features: authors may include 00:50:48 ... reading systems must not support 00:51:11 ... I have a suggestion that we need a third category 00:51:33 ...where authors are strongly recommended NOT to use 00:51:39 ... reading systems should support 00:51:40 q? 00:51:42 q+ 00:52:44 ack dauwhe 00:53:02 q+ 00:54:24 ack florian 00:54:28 dauwhe: another factor is epubcheck 00:54:32 florian: I think I agree 00:54:46 ... I propose that the third group be called "compatiblity features" 00:54:54 ... maybe for epubcheck a low priority warning 00:55:01 ... like in verbose mode 00:55:49 dauwhe: there are info alerts in EPUBCheck 00:56:20 florian: it's also probably useful to say what happens if both properties are used 00:56:54 +q 00:56:59 dauwhe: what about the cascade 00:57:07 ack toshiakikoike 00:57:16 florian: the model also tells what happens from script 00:57:24 toshiakikoike: (in Japanese) 00:57:59 ... with current versions of epub check, when using vendor prefixes, we don't issue any warning or info 00:58:04 tzviya has joined #epub 00:58:18 ... should we issue an info only for epub prefixes? 00:58:31 florian: my opinion is that it is low priority 00:58:46 ... when we know what unprefixed property should be used 00:58:49 q+ 00:59:32 ack dauwhe 01:00:41 duga has joined #epub 01:00:59 present+ 01:01:09 dauwhe: we're not sure how much we want to enforce restrictions on CSS 01:01:28 I guess we didn't change to match Boston time 01:01:39 shiestyle: in conclusion, we will continue to discuss unsupported features. I will file a GitHub issue. 01:01:46 ... and we can continue the discussion there. 01:02:48 Zakim, end meeting 01:02:48 As of this point the attendees have been florian, MasakazuKitahara, MattChan, toshiakikoike, shiestyle, jyoshii_, naomi, Daihei, `1, duga 01:02:50 RRSAgent, please draft minutes 01:02:50 I have made the request to generate https://www.w3.org/2020/11/12-epub-minutes.html Zakim 01:02:53 I am happy to have been of service, dauwhe; please remember to excuse RRSAgent. Goodbye 01:02:57 Zakim has left #epub 01:03:06 RRSAgent: make logs public 01:03:12 RRSAgent: make logs public 01:03:35 RRSAgent, make logs public 01:03:55 RRSAgent: bye 01:03:55 I see no action items