23:50:23 <RRSAgent> RRSAgent has joined #epub
23:50:23 <RRSAgent> logging to https://www.w3.org/2021/12/09-epub-irc
23:50:26 <Zakim> RRSAgent, make logs Public
23:50:28 <Zakim> please title this meeting ("meeting: ..."), dauwhe_
23:50:34 <dauwhe_> Meeting: EPUB 3 Working Group Telecon
23:50:54 <dauwhe> chair: dauwhe
23:54:01 <MasakazuKitahara> MasakazuKitahara has joined #epub
23:57:04 <wendyreid> wendyreid has joined #epub
23:57:09 <MasakazuKitahara> present+
23:57:51 <wendyreid> present+
23:58:41 <shiestyle> shiestyle has joined #epub
23:58:59 <toshiakikoike> toshiakikoike has joined #epub
23:59:08 <toshiakikoike> present+
23:59:29 <John_Roque> John_Roque has joined #epub
23:59:51 <MattChan> MattChan has joined #epub
00:00:34 <duga> duga has joined #epub
00:00:42 <duga> present+
00:00:50 <shiestyle> present+
00:01:04 <MattChan> present+
00:01:17 <dauwhe> present+
00:01:47 <John_Roque> present+
00:02:12 <MattChan> scribe+
00:02:46 <dauwhe> https://github.com/w3c/epub-specs/issues/1921
00:02:52 <MattChan> TOPIC:  Invalid File Name Characters
00:02:52 <MURATA_> MURATA_ has joined #epub
00:02:59 <MURATA_> +present
00:03:10 <MattChan> dauwhe: there has been some back and forth with the i18n folks about our restrictions on file naming
00:03:33 <MattChan> ... mgarrish suggested that we change MUST NOT on list of forbidden chars in file names to SHOULD NOT
00:03:58 <MURATA_> +1, but why did Matt propose this
00:04:03 <MattChan> ... i don't agree, a lot of chars are on that list for a good reason, e.g. to allow for moving epubs across OS
00:04:32 <MattChan> ... file called "?.html" could not be linked to, for example, because of interaction with URL parser
00:04:45 <MattChan> ... also, not aware of any authors asking to use these characters in epub content
00:04:48 <duga> q+
00:05:05 <MattChan> ... also not that we are not restricting any language in these forbidden chars
00:05:12 <dauwhe> ack du
00:05:14 <MattChan> s/not that/note that
00:05:25 <MattChan> duga: did i18n specify which countries would be impacted by not allowing these chars?
00:05:57 <MattChan> dauwhe: i think this came from mgarrish wondering whether we should just make the whole list a should rather than selectively taking things out of the forbidden list
00:06:04 <MattChan> ... e.g. emoji combining chars
00:06:46 <MattChan> duga: agree that there is not a reason to add these, plus, these restrictions are applicable to file names - opaque to the reader
00:06:55 <MURATA_> +1
00:06:58 <toshiakikoike> +1
00:07:04 <John_Roque> +1
00:07:04 <shiestyle> +1
00:07:10 <wendyreid> Proposed: Close issue 1921 with no change
00:07:15 <wendyreid> +1
00:07:17 <dauwhe> +1
00:07:19 <duga> +1
00:07:20 <MattChan> +1
00:07:20 <John_Roque> +1
00:07:20 <shiestyle> +1
00:07:23 <MURATA_> +1, again
00:07:26 <hober> present+
00:07:33 <MasakazuKitahara> +1
00:07:48 <wendyreid> RESOLVED: Close issue 1921 with no change
00:08:36 <dauwhe> https://github.com/w3c/epub-specs/issues/1929
00:08:37 <MattChan> TOPIC:  Is page-spread-center a synthetic spread or not?
00:08:46 <dauwhe> https://github.com/w3c/epub-specs/pull/1950
00:08:59 <AramZS_> AramZS_ has joined #epub
00:09:01 <MattChan> wendyreid: i just got through writing the tests for all the FXL rendition properties, which lead to a question about page-spread-center
00:09:34 <MattChan> ... this is a spine property that is not meant to override spread behaviour, but that the page should be centered in the viewport
00:09:43 <MattChan> ... but this doesn't seem to be what is happening in practice
00:09:57 <MattChan> ... rather, the observed behaviour seems to be identical to spread none
00:10:00 <duga> q+
00:10:03 <wendyreid> https://github.com/w3c/epub-specs/issues/1929
00:10:29 <MattChan> ... we've discussed in the issue, and mgarrish came up with the idea of making page-spread-center an alias of spread none
00:10:34 <dauwhe> ack du
00:10:47 <MattChan> ... and not to deprecate page-spread-center
00:11:35 <Victor_Lopes> Victor_Lopes has joined #EPUB
00:11:50 <MattChan> duga: not sure why page-spread-center is confusing. Imagine you are doing a synthetic spread, but you want one specific page centered in the middle of the screen. That's how you would tell the RS to do that.
00:12:17 <MattChan> ... spread none sounds like you've turned off spreads completely
00:12:18 <dauwhe> q+
00:12:53 <shiestyle> q+
00:12:59 <MattChan> wendyreid: an additional level of oddness was finding out that you can put page spread properties on spine level items as well
00:13:28 <MattChan> duga: spread none and spread center mean different things, because spread none doesn't tell you where to put the page
00:14:21 <wendyreid> ack dauwhe
00:14:35 <MattChan> ... and yes, it is confusing that you can put this on a spine item (you can also alternate portrait and landscape on spine level items as another weird way of interacting with spreads)
00:14:55 <MattChan> dauwhe: is there a concern that this could affect the relative size of pages as you go from spread, to non-spread, and back to spread?
00:15:12 <MattChan> duga: i can't see people really doing this
00:15:47 <dauwhe> q?
00:16:03 <dauwhe> ack shi
00:16:23 <MattChan> ... one potential use case is if one of your content documents is already a spread, so you want to disable synthetic spreads for that one only
00:16:57 <MattChan> shiestyle: in JP we use spread-center for the cover pages in many many cases, so making spread-center a depreciated feature would not be acceptable
00:17:04 <MattChan> ... aliasing it to spread none is okay
00:17:20 <MattChan> wendyreid: right, so we won't deprecate page-spread-center
00:17:49 <MattChan> ... this might be the sort of thing we need to test out
00:18:01 <MattChan> ... when the page appears in the center of the viewport, i think there is a change in the page size
00:19:01 <MattChan> dauwhe: i'm not comfortable deciding this until we have more info on whether we need to better define how a RS should position the viewport when you use page-spread-center or spread none as an override of a synthetic spread epub
00:19:27 <MattChan> wendyreid: agree that the FXL properties section could use some visual aides
00:19:47 <MattChan> ... we can put this off for tonight
00:20:03 <MattChan> duga: if we end up keeping page spread then we need to fix this definition
00:20:15 <MattChan> wendyreid: yeah, definitions in that section are not very good
00:20:51 <MattChan> dauwhe: it was a long time ago that we wrote those, we were balancing against implementations that already existed at the time (amazon, apple)
00:20:56 <wendyreid> https://github.com/w3c/epub-specs/issues/1936
00:21:09 <MattChan> TOPIC: Normatizing the fixed layout property statements
00:21:41 <MattChan> wendyreid: i noticed that in RS spec we say in rendition:layout that the default value is a MUST
00:22:08 <dauwhe> q+
00:22:11 <victoria> victoria has joined #epub
00:22:26 <MattChan> ... but for the other 2 FXL properties even though we also define default behaviour, we don't make those statements normative
00:22:36 <dauwhe> ack d
00:22:51 <MattChan> dauwhe: there are a couple instances where we say that the default value MUST be assumed, but i didn't know how that would be testable
00:23:08 <MattChan> wendyreid: the default behaviour is auto, and that means to respect what the RS is doing
00:23:24 <duga> q+
00:23:27 <MattChan> ... so the test would pass if the epub appears in way that would respect the app settings or the user settings
00:23:31 <wendyreid> ack duga
00:23:34 <MattChan> ... which is essentially what auto is meant to do
00:23:36 <dauwhe> ack du
00:24:19 <MattChan> duga: you could not specify in one case and specify in another case, and if the result is the same then the RS passes?
00:24:52 <MattChan> wendyreid: my proposal was to turn the 2x non-normative default behaviour statements into normative MUSTs
00:25:00 <MattChan> ... i've already made the tests for both of them
00:25:12 <MattChan> dauwhe: so we just ask mgarrish to made the change, then
00:25:24 <wendyreid> Proposed: Elevate the default behaviour statements for rendition:orientation and rendition:spread to MUSTs
00:25:29 <duga> +1
00:25:32 <shiestyle> +1
00:25:33 <wendyreid> +1
00:25:34 <John_Roque> +1
00:25:34 <MattChan> +1
00:25:37 <toshiakikoike> +1
00:25:37 <hober> +1
00:25:41 <MURATA_> +1
00:25:43 <dauwhe> +1
00:25:44 <MasakazuKitahara> +1
00:25:52 <wendyreid> RESOLVED: Elevate the default behaviour statements for rendition:orientation and rendition:spread to MUSTs
00:26:11 <dauwhe> https://github.com/w3c/epub-specs/issues/1941
00:26:18 <MattChan> TOPIC: Should the RS spec include something about layout overrides?
00:26:55 <MattChan> wendyreid: we have a statement in content spec that it is possible to override the global layout value, but nothing is said about it in the RS requirements
00:27:16 <MattChan> ... and some of the associated behaviours are SHOULD in the RS spec
00:27:17 <wendyreid> https://www.w3.org/TR/epub-33/#layout-overrides
00:27:59 <MattChan> ... these overrides theoretically make mixed modality content (fixed + reflow) possible, but its underspecified
00:28:26 <wendyreid> https://github.com/w3c/epub-specs/pull/1947
00:28:43 <MattChan> dauwhe: i'm aware of some uses, e.g. in educational content, there might be reflow text on one side, and fixed layout reference material on the other side
00:29:06 <MattChan> duga: i'd hate to lose this feature to a lack of implementations. We don't support it, but I think we should
00:29:06 <dauwhe> q?
00:29:12 <shiestyle> q+
00:29:36 <dauwhe> ack shie
00:29:39 <MattChan> wendyreid: mgarrish has made a PR where he he proposes language
00:30:08 <MattChan> shiestyle: in JP we do use partially fixed layout
00:30:13 <dauwhe> q?
00:30:21 <MattChan> dauwhe: does that give us enough implementations to get this feature through?
00:30:42 <MattChan> wendyreid: we might also have a partial implementation of this - specifically for covers for reflow books
00:31:22 <MattChan> dauwhe: we do seem to have consensus that its necessary to have an RS conformance statement for these overrides
00:31:48 <MattChan> ... the fact that its missing might just be an artefact from when we split out RS requirements from core
00:32:11 <wendyreid> Proposed: Merge PR 1947 and close issue 1941
00:32:15 <duga> +1
00:32:16 <shiestyle> +1
00:32:18 <wendyreid> +1
00:32:18 <MattChan> +1
00:32:23 <MURATA_> +1
00:32:25 <toshiakikoike> +1
00:32:29 <dauwhe> +1
00:32:30 <MasakazuKitahara> +1
00:32:42 <wendyreid> RESOLVED: Merge PR 1947 and close issue 1941
00:32:58 <MattChan> TOPIC: Bikeshedding – what to call features without enough implementation?
00:33:15 <MattChan> wendyreid: continuing our discussion from last week - what do we call the features that don't get enough implementation?
00:33:15 <dauwhe> https://github.com/w3c/epub-specs/issues/1944
00:33:37 <MattChan> ... we've used deprecated in the past (not what HTML spec goes by), and we've also used legacy
00:34:08 <MattChan> dauwhe: legacy features are holdovers from EPUB2 that are still useful, e.g. for making EPUB3 backwards compatible with EPUB2 RS
00:34:14 <MattChan> ... this is a different situation
00:34:30 <hober> q?
00:34:54 <MattChan> ... this is a collision between W3C process whereby we need demonstrable implementation of features (i.e. tests), but we also have a charter where we can't invalidate existing content
00:35:11 <hober> q+
00:35:39 <MattChan> ... so what if there's something in the spec where we don't have 2 passing tests now, but the implementations could exist in the future
00:35:43 <wendyreid> ack hober
00:35:48 <dauwhe> ack ho
00:36:39 <MattChan> hober: i don't know the details of the charter restriction. If epubcheck would have said "this is fine" before, then it needs to keep saying that? Even if no one had implemented the feature?
00:37:00 <MattChan> dauwhe: yes, that's basically my understanding, since we live in an ecosystem where even a warning from epubcheck will block content from reaching users
00:37:10 <MattChan> ... and we can't rely on people updating content
00:37:39 <MattChan> hober: in HTML we might call a feature obsolete, and then obsolete features can itself be conforming or non-conforming
00:38:18 <MattChan> ... i think it would be fine to call your features obsolete, but the spec needs to have specific text directed to conformance checkers asking them not to throw warnings
00:38:27 <MattChan> ... like obsolete but conforming
00:38:59 <MattChan> ... in the W3C process when you reach CR you have to list features at risk, and typically those are the ones where you don't have enough implementations, but where you hope to get those implementations during CR
00:39:33 <MattChan> ... so, actually, yeah... if you don't want to maybe end up dropping those features at the end of CR, then i'd go back to my first suggestion
00:39:54 <MattChan> dauwhe: epubcheck already has an informative level of alert below warning
00:40:00 <MattChan> ... we could say to use this level
00:40:27 <MattChan> hober: typically things in W3C are less tied to a specific conformance checker, but clearly epubcheck is the reality for epubs
00:40:42 <MattChan> ... you want to make your spec a little more general, but you can have a specific statement about epubcheck
00:41:03 <MattChan> dauwhe: we also don't want to send false messages about what is and is not well supported
00:41:10 <dauwhe> q?
00:41:28 <MattChan> hober: one of the ways that HTML handles that for obsolete features, is that in the main text of the spec it doesn't even mention them
00:41:43 <MattChan> ... they're defined in a separate obsolete features section at the end
00:41:55 <duga> q+
00:42:08 <MattChan> ... if a feature like that is presented right in the main text and not visually distinct, then people will of course believe that those features are just as sound
00:42:11 <dauwhe> ack du
00:42:18 <MattChan> ... so maybe consolidate them and make them visually distinct
00:42:37 <MattChan> duga: i liked at risk, but ivan didn't like it because at risk had a specific meaning in W3C process
00:43:02 <MattChan> ... deprecated doesn't seem to fit. Maybe something scarier like imperilled.
00:43:29 <MattChan> ... and we should make sure that conformance checkers can fail epubs that contain these at the user's option
00:43:43 <MattChan> ... even if it isn't the checker's default behaviour
00:44:12 <MattChan> hober: imperiled is a bit obscure for non-native speakers
00:44:26 <MattChan> ... obsolete and deprecated are more recognizable in the world of spec writing
00:44:46 <MattChan> ... but I see duga's point that at risk scares people off more effectively than either of the other terms
00:44:58 <dauwhe> q?
00:45:04 <MattChan> duga: also these features might actually become used some day, where as deprecated feels almost like the opposite
00:45:17 <MattChan> hober: right, if you get more implementations they could just become regular features
00:45:50 <MattChan> ... reminds me of speculative features for browsers, where you have one good implementation, but then it just gets stuck in feature limbo for a while
00:46:11 <MattChan> ... might be worth reaching out to YCG chairs to ask what they're doing
00:46:43 <MattChan> duga: we could do something like "experimental" (but it would be weird to have manifest fallbacks become experimental)
00:46:58 <dauwhe> q?
00:47:10 <MattChan> wendyreid: i like experimental, but I also like the idea of reaching out to YCG chairs to ask for advice
00:47:32 <MattChan> dauwhe: also incubating, unproven, or unstable - but i'm not wild about these
00:48:13 <MattChan> hober: aside from the question of naming, it sounds like everyone is on the same page about how to describe these types of features, and what the behavior of conformance checkers should be, so it seems like you're in a pretty good place
00:48:36 <MattChan> dauwhe: i think we a lot more good info on our goals, and how HTML has handled this
00:48:44 <MattChan> ... we'll ask around for advice about naming
00:49:10 <MattChan> duga: maybe we could go for a JP name?
00:49:27 <MattChan> MURATA_: no specific ideas right now
00:49:56 <MattChan> dauwhe: just a reminder that this was the last meeting of 2021, we will resume in 2022
00:50:10 <MattChan> ... thank you all, see you next year!
00:50:29 <dauwhe> Zakim, end meeting
00:50:29 <Zakim> As of this point the attendees have been MasakazuKitahara, wendyreid, toshiakikoike, duga, shiestyle, MattChan, dauwhe, John_Roque, present, hober
00:50:31 <Zakim> RRSAgent, please draft minutes
00:50:31 <RRSAgent> I have made the request to generate https://www.w3.org/2021/12/09-epub-minutes.html Zakim
00:50:34 <Zakim> I am happy to have been of service, dauwhe; please remember to excuse RRSAgent.  Goodbye
00:50:39 <Zakim> Zakim has left #epub
00:52:46 <dauwhe> rrsagent: bye
00:52:46 <RRSAgent> I see no action items