23:56:21 RRSAgent has joined #epub 23:56:21 logging to https://www.w3.org/2022/06/23-epub-irc 23:56:23 RRSAgent, make logs Public 23:56:24 please title this meeting ("meeting: ..."), dauwhe 23:56:31 Meeting: EPUB 3 Working Group Telecon 23:56:33 Chair: dauwhe 23:57:53 shiestyle has joined #epub 23:59:00 MURATA has joined #epub 23:59:09 toshiakikoike has joined #epub 23:59:20 present+ 23:59:28 MasakazuKitahara has joined #epub 23:59:32 present+ 23:59:37 mgarrish has joined #epub 23:59:50 wendyreid has joined #epub 23:59:51 MattChan has joined #epub 00:00:09 present+ 00:00:35 present+ 00:00:35 present+ 00:00:40 present+ 00:01:02 scribe+ 00:01:49 present+ 00:02:00 duga has joined #epub 00:02:05 present+ 00:02:21 https://github.com/w3c/epub-specs/issues/2327 00:02:21 present+ 00:02:26 TOPIC: Allocating Bridgehead 00:02:46 dauwhe: someone is a little worried about how we defined bridgehead in the SSV 00:03:24 ... i understand that using bridgehead won't have any impact on anything, and given that it doesn't exist in HTML, can we just deprecate it? 00:04:46 mgarrish: from an a11y perspective, people misunderstand these semantics. e.g. if they type a heading as bridgehead then they think it doesn't show up as a heading in AT 00:04:57 dauwhe: are we still making changes to the SSV? 00:05:03 mgarrish: we are publishing it as a note again 00:05:20 dauwhe: okay, in that case, yes, let's deprecate it 00:05:26 Proposed: Deprecate Bridgehead, close issue 2327 00:05:34 +1 00:05:34 +1 00:05:34 +1 00:05:35 +1 00:05:35 +1 00:05:36 +1 00:05:37 +1 00:05:45 RESOLVED: Deprecate Bridgehead, close issue 2327 00:06:17 https://github.com/w3c/epub-specs/issues/2292 00:06:21 TOPIC: Reference to Initial Containing Block definition should be improved 00:06:56 dauwhe: we have a viewport meta tag for FXL. It has an informal definition in a CSS module, but Ivan feels like that isn't a good enough reference 00:07:27 ... he suggests that we define it ourselves. But from experience, defining things related to layout is really difficult 00:08:00 wendyreid: i'm in favor of defining it only because RS already use this tag in a very very specific way 00:08:21 ... we can even say that our definition is for RS only, and not to expect the same behaviour elsewhere 00:08:39 ... and the way we use it isn't documented normatively anywhere else in our spec 00:09:26 dauwhe: do people ever use anything else in this element other than dimensions? No other units? 00:09:43 duga: I think somewhere someone has probably put 'px' after the number value 00:09:57 dauwhe: the amount of variation out there is a concern 00:10:28 wendyreid: i've almost always seen numeric values, not ems, not 'device-height' 00:10:52 duga: i'm almost certain we've had bugs related to this, but I don't recall what weird thing people have tried 00:11:14 wendyreid: i've seen bugs where people try to make different content documents different sizes 00:11:25 duga: there's a test for device height 00:12:01 wendyreid: we could create a bunch of different test FXLs that try to use different units in this element. Easy enough to test 00:12:55 mgarrish: when we define this with the Apple documentation it required pixels. It was only when we switched to referencing CSS that we began to open the door to these other sorts of values 00:13:02 ... not sure we did that intentionally 00:13:24 s/test for device height/test for device-height 00:14:05 mgarrish: we could always define it strictly and see what feedback we get 00:14:16 dauwhe: limit it to just 'width' and 'height' 00:14:40 ... trying to imagine if various types of relative units make sense in there 00:15:01 ... do we know how RS would treat 'device-height' and 'device-width'? 00:15:16 wendyreid: whatever viewport the RS happens to be in, maybe? 00:15:38 ... i feel like there was guidance about this in our best practices documentation 00:15:45 ... what did it say? 00:16:54 dauwhe: no, we don't say anything specific about that other than that it must be included, and all examples given are in pixel values 00:17:42 ... would be interested in making a FXL with 'device-height' and 'device-width' but run it in a desktop RS 00:18:31 duga: Play parses the value and just takes the beginning number value regardless of what the unit is. Unless it is 'device-height' or 'device-width'. We pass those back. 00:19:30 dauwhe: propose that we define viewport meta, but only allow width and height properties as a restricted version of the CSS definition, but that we don't place further restriction on what values may be used in 'width' and 'height' 00:20:33 duga: what about things that have initial scale on the viewport? 00:21:06 wendyreid: not part of our definition. Other properties on viewport meta are undefined. 00:21:26 Proposed: Define the meta viewport property with only the width and height attributes as a restriction on the CSS definition, close issue 2292 00:21:38 +1 00:21:39 +1 00:21:41 +1 00:21:41 +1duga 00:21:41 +1 00:21:42 +1 00:21:42 +1 00:21:44 +1 00:21:47 +1 00:21:54 RESOLVED: Define the meta viewport property with only the width and height attributes as a restriction on the CSS definition, close issue 2292 00:22:23 https://github.com/w3c/epub-specs/issues/2270 00:22:27 TOPIC: Unclear whether SVG dimensions should only apply in FXL 00:23:58 dauwhe: in FXL stuff we say RS must use dimensions from ICB in rendering SVG documents. Do we respect SVG dimensions or at least proportions in reflow as well? 00:24:38 ... I think no 00:25:26 duga: agreed, this is for FXL section only 00:26:01 Proposed: Close issue 2270, don't fix 00:26:04 +1 00:26:05 +1 00:26:06 +1 00:26:07 +1 00:26:08 +1 00:26:09 +1 00:26:11 +1 00:26:14 RESOLVED: Close issue 2270, don't fix 00:26:15 +1 00:26:23 +1 00:27:02 https://github.com/w3c/epub-specs/issues/2261 00:27:07 TOPIC: Should the specs address links in referenced SVGs? 00:28:29 dauwhe: we don't explicitly say what happens if you click a hyperlink in various different contexts, should we? 00:28:58 ... our special case is links from inside epub to outside, and we discuss that case 00:29:30 ... for other contexts, that behaviour is covered by the appropriate spec 00:29:31 +1matt 00:30:13 Proposed: Close issue 2261, won't fix 00:30:19 +1 00:30:20 +1 00:30:20 +1 00:30:21 +1 00:30:23 +1 00:30:25 +1 00:30:25 +1 00:30:25 +1 00:30:26 +1 00:30:31 RESOLVED: Close issue 2261, won't fix 00:32:04 TOPIC: AOB? 00:32:40 dauwhe: I'll be out next week, but back the week after 00:32:54 ... okay, thank you everyone, see you all later 00:33:02 zakim, end meeting 00:33:02 As of this point the attendees have been toshiakikoike, MasakazuKitahara, dauwhe, mgarrish, MattChan, shiestyle, wendyreid, duga, MURATA 00:33:04 RRSAgent, please draft minutes 00:33:04 I have made the request to generate https://www.w3.org/2022/06/23-epub-minutes.html Zakim 00:33:07 I am happy to have been of service, dauwhe; please remember to excuse RRSAgent. Goodbye 00:33:11 Zakim has left #epub 00:33:17 rrsagent, bye 00:33:17 I see no action items