23:02:42 RRSAgent has joined #epub 23:02:42 logging to https://www.w3.org/2021/04/15-epub-irc 23:02:45 RRSAgent, make logs Public 23:02:47 please title this meeting ("meeting: ..."), dauwhe 23:02:55 Meeting: EPUB 3 Working Group Telecon 23:03:01 Chair: dauwhe 23:03:09 Date: 2020-04-15 23:51:09 wendyreid has joined #epub 23:58:17 toshiakikoike has joined #epub 23:58:54 shiestyle has joined #epub 23:59:04 MasakazuKitahara has joined #epub 23:59:09 present+ 23:59:33 present+ 23:59:44 MattChan has joined #epub 23:59:45 present+ 00:00:44 present+ 00:00:54 present+ 00:01:42 present+ 00:01:57 present+ 00:02:12 marisa has joined #epub 00:02:39 marisa has joined #epub 00:02:51 present+ 00:03:26 scribe+ 00:03:47 TOPIC: Summary of FXL and Virtual Locators calls 00:04:11 wendyreid: we had calls for both TF this week 00:04:14 ... both moving forward 00:04:29 ... FXL TF has divided up the work we talked about last meeting 00:04:33 ... updating Daisy KB 00:04:50 ... best practices documentation (probably end up as WG note) 00:05:04 ... and modern HTML and CSS standards in epubs 00:05:12 ... Locators had a really productive calls 00:05:19 ... broke down the use-cases 00:05:35 ... we will review CFI to see what we can learn 00:06:03 dan: CFI does what we need, but it is not that friendly 00:06:17 ... so we want to think about whether we can have something more user friendly 00:06:44 wendyreid: we talked about whether there was anything we could do to make our solution as "webby" as possible 00:07:03 dauwhe: there's some API that's supposed to solve the problem of how to locate something within a webpage 00:07:07 wendyreid: the findtext API? 00:07:34 duga: we release Chrome extension for making link to arbitrary location on a page (basically by finding some text) 00:07:44 dauwhe: and having indexers involved is really good 00:08:12 dan: they are enthusiastic and knowledgable, one of our indexers is a current PhD candidate in the ebook area 00:08:24 https://github.com/w3c/epub-specs/issues/1313 00:08:30 TOPIC: language around rendition:flow 00:09:02 dauwhe: i was concerned that we say RS MUST use auto as a default value, but auto means "RS, do whatever you want" 00:09:05 dlazin has joined #epub 00:09:06 ... not sure that it was testable 00:09:12 present+ 00:09:17 ... but Dan thinks it is testable 00:09:25 ... so maybe we should just undo that resolution 00:09:41 https://github.com/w3c/epub-specs/pull/1616#pullrequestreview-629109802 00:10:26 q+ 00:10:31 ack duga 00:10:34 ... if it is testable i'm fine with restoring that requirement 00:10:56 duga: agree. Not worth spending much time on. 00:11:04 ... and agree with dlazin's testing method for it 00:11:29 dauwhe: yes, we just need to see that things are consistent between having consistent auto value and "implied" auto 00:11:41 s/consistent auto/explicit auto 00:12:26 Proposed: Merge PR 116 00:12:29 +1 00:12:30 +1 00:12:30 +1 00:12:31 +1 00:12:31 +1 00:12:33 +1 00:12:35 +1 00:12:39 +1 00:13:07 Resolved: Merge PR 1616 00:13:34 +1 00:13:34 https://github.com/w3c/epub-specs/issues/1602 00:13:38 TOPIC: Getting rid of registries 00:13:55 https://w3c.github.io/epub-specs/epub33/rs/#sec-xhtml-custom-attributes 00:14:33 dauwhe: we said that vendors may define custom attributes, and then we setup a custom registry to track these 00:14:52 ... HTML has quite a few ways for users to add attributes 00:15:22 q? 00:15:24 ... it seems to me a that it would be a great benefit to remove something that was never used, and which takes as further from HTML 00:15:36 dlazin: why would this be bad for HTML? 00:15:57 dauwhe: name space attributes create issues for us in future because we can't use them in HTML serialization 00:16:05 q? 00:16:18 q+ 00:16:34 dlazin: so proposal here is to remove entire section on custom attributes? 00:16:35 q- 00:16:37 dauwhe: yes 00:16:43 Proposed: Remove all references to custom attributes 00:16:51 +1 00:16:51 +1 00:16:51 +1 00:16:52 +idpf:1 00:16:53 +1 00:16:54 +1 00:16:54 +1 00:16:57 +1 00:17:12 Resolved: Remove all references to custom attributes 00:17:31 dlazin: for clarity, when I reported that as bug, I thought that vendors WERE using this, but just not reporting into the registry 00:17:40 dauwhe: no, don't think that is the case 00:17:59 https://github.com/w3c/epub-specs/issues/1523 00:18:08 TOPIC: Restrictions on container-constraints scripts 00:18:33 dauwhe: this refers to scripts that run inside iframes 00:19:05 ... we say that such scripts should not modify parent in DOM or other documents in publication, must not modify the size of its containing rectangle 00:19:06 q+ 00:19:25 ... the idea is that container-constrained scripts should stay in their containers 00:19:49 ... Ivan was wondering whether using attributes to do this would accomplish the same thing, and be checkable by epubcheck 00:20:10 ack duga 00:20:12 ... i looked into the sandbox attribute, but nothing seemed like a perfect match for what we want to achieve 00:20:27 duga: i don't think sandbox is appropriate here, its for security and we're concerned with layout 00:20:49 ... the fact that the script cannot touch things outside of yourself, is by definition 00:21:06 ... if you do touch outside things, no longer are you "container-constrained" 00:21:18 ... so maybe rewrite this language as defining what it is 00:21:40 ... "a container-constrained script is... doesn't affect things outside itself, etc." 00:22:05 ... and anything not contained is considered spine level 00:22:37 dauwhe: but then who's responsibility is it to enforce that? The RS? 00:22:59 duga: this is being done for publishers because we want to enable some scripting without breaking the content 00:23:22 ... if they chose to ignore this and the content breaks, then they'll just learn to stop 00:23:33 dauwhe: Ivan was also concerned about this from a testing perspective 00:24:03 ... can't reasonably write a validator to check every javascript for whether or not it goes outside its container 00:25:22 ... but what we are leaning towards almost seems to move that section into the definitions 00:25:42 ... maybe we can take this back to Ivan and Matt? 00:25:59 duga: you could almost just turn that paragraph into a bullet point 00:26:28 dauwhe: or just say "container-constrained script does NOT... etc." 00:26:59 wendyreid: okay, so maybe no proposal for now, and we can just comment on the github ticket 00:27:17 marisa: what do people use container-constrained scripts for? 00:27:20 ... widgets? 00:27:38 duga: yeah, some little interactive thing. 3D model, for example 00:28:40 https://github.com/w3c/epub-specs/issues/1517 00:28:51 TOPIC: Quick reference pages 00:28:55 dauwhe: this is a feature request 00:29:11 q+ 00:29:12 ... someone wants to do pop-up reference pages, like a modal pop-up 00:29:21 ... it would appear to the user without changing the user's reading location 00:29:29 ... i think there have been precedents 00:29:41 ... sounds Microsoft Reader pagelits 00:29:51 q+ 00:29:58 ... linear="no", that spawned a pop-up in front of the existing page 00:30:12 ... this strikes me as potentially useful, but also a huge can of worms 00:30:27 ... we'd have to describe complex visual rendering of something in epub 00:30:40 ... how do we respond to requests like this? 00:30:50 q+ 00:31:02 ... we could say "use HTML techniques", but most of those may not work in epub 00:31:08 ack wen 00:31:16 wendyreid: this came up in Locators call 00:31:29 ... the question was raised about the positioning of index in RS 00:31:46 ... most RS have separate TOC that can be accessed without changing reading position 00:31:54 ... so what about index? 00:31:56 q? 00:32:04 ... we've never seen it done 00:32:14 ... maybe cause there are clear indicators for what a TOC is 00:32:21 ... nothing analogous for index 00:32:44 ... i think we need to define how modals should appear, but maybe just elevate some common elements to same semantic level as TOC 00:32:45 q+ 00:32:57 ... like for index, map, etc. 00:33:06 ack duga 00:33:12 ... then RS could choose to visually treat that the way they do TOCs 00:33:19 duga: this is probably out of scope for now? 00:33:32 ... and it seems like maybe we could do this using existing markup 00:34:25 ack dl 00:34:28 ... maybe have note, "if you have target blank pointing to something within the epub then display like a modal" 00:35:13 dlazin: if we were to grant this, people would use this to do all sorts of weird UI things 00:35:34 ... might be good for making ebooks less tied down to replicating print books 00:35:54 ... so this feature would be for whatever the authors wants to put in this separate window 00:36:26 ack da 00:36:32 ... but I'd like clarification on how we normally deal with feature requests 00:36:47 dauwhe: the TOC is interesting because the spec mandates a navigation document 00:36:51 ... we call it out in the manifest 00:37:35 ... and we require that a RS make the text and links of navigation document available even if the linked document is not in the spine at all (linear="no") 00:38:04 ... epub is sort of different from the web because the RS decides how UI works, and author just provides the content inside 00:38:21 ... not sure what to think about attempts to change that fundamental division 00:38:25 q+ 00:38:28 ... open to experimentation in this area 00:38:45 ... i'd want to see interest from content creators and interest from RS developers 00:39:01 ... they need to tell us how such an interface would work 00:39:02 ack dl 00:39:31 dlazin: something that seems analogous here is a widget framework like Chrome extension or Google Docs add-ons 00:39:48 ... those are more apps than content 00:40:12 ... but just like here, Google Docs creates the UI, but extensions have some control 00:40:22 q? 00:40:41 q+ 00:41:01 ... we could think of 3 categories, normal content, model content, and non-modal content outside of the main document (e.g. sidebar) 00:41:04 ack da 00:41:22 dauwhe: this sounds like a job for the CG 00:41:32 ... they can better incubate, gather support 00:41:48 ... and that's more our process for feature requests 00:41:49 q+ 00:42:15 ... also remember that Opera had something like this, like a "secondary browsing context"? 00:42:21 ack dug 00:42:25 ... you could make it open a side window 00:42:34 duga: agree that this should go to CG 00:43:25 ... we might want to have a more formal way to hook up the content experiments with the RS experiments 00:43:43 ... so that there is a place to test the experimental content and vice versa 00:44:25 wendyreid: raise it with Mattias and Zheng 00:44:37 s/Mattias/Mateus/ 00:45:00 ... so we'll just comment on the issue and let them know that we are referring this to the CG 00:45:11 https://github.com/w3c/epub-specs/issues/1516 00:45:11 dauwhe: and tag Mateus and Zheng 00:45:29 TOPIC: What do we mean by support for "presentation logic"? 00:45:50 dauwhe: we say RS must "honor presentation logic expressed through package document" 00:46:16 ... mgarrish thinks we should just delete it since we already require all the pieces of that in other places in the RS spec 00:46:21 ... making this statement redundant 00:46:28 duga: agree 00:46:52 marisa: yes, agree 00:47:50 Proposed: Drop the statement in issue 1516 00:47:51 +1 00:47:52 +1 00:47:53 +1 00:47:56 +1 00:47:56 +1 00:47:58 +1 00:47:59 +1 00:48:02 +1 00:48:07 Resolved: Drop the statement in issue 1516 00:48:13 TOPIC: Handling non-Arabic page numbers 00:48:16 https://github.com/w3c/epub-specs/issues/1505 00:48:38 q+ 00:48:40 dauwhe: what are the rules for RS when faced with non-Arabic page numbers? 00:48:46 ack du 00:49:00 duga: are there any rules for handling Arabic page numbers? 00:49:13 dauwhe: right, we haven't really said anything about this 00:49:26 duga: Arabic or otherwise 00:49:42 dauwhe: we've left a lot of these UI decisions up to RS 00:50:04 ... some RS will use the content of the pagelist if it exists instead of internal page numbering 00:50:09 q+ 00:50:11 ... assume these would just use whatever string is in there 00:50:32 dlazin: that's true for Apple 00:50:46 duga: true in Play Books 00:51:15 dauwhe: yep, backmatter in educational books often use letters 00:51:36 duga: we often see a mix of Arabic numerals and other stuff 00:51:46 dauwhe: not sure I see the problem here 00:52:29 ... is there any guidance in the pagelist section on this? 00:52:44 wendyreid: don't think so 00:53:26 ... the context of this is really how RS communicate non-Arabic page numbers, but if RSes already have a solution... 00:53:43 dlazin: there is an issue with the string-based solution with TTS and AT 00:53:54 ... cannot pronounce arbitrary string 00:54:09 ... maybe possible to solve it with ARIA label? 00:54:39 dauwhe: maybe have informative statement that if there is a pagelist, then RS should use strings embedded in pagelist? 00:54:52 ... if they want to present that to user? 00:55:39 wendyreid: maybe refer this back to mgarrish? The a11y spec does not tell RS what to do, which is how it ended up here 00:55:54 ... maybe we need him to explain why this came up in a11y in the first place 00:57:01 dauwhe: okay, so no resolution for now 00:57:08 ... further discussion to come 00:57:31 TOPIC: AOB? 00:57:44 dauwhe: okay, thanks everyone! 00:58:05 zakim, end meeting 00:58:05 As of this point the attendees have been MasakazuKitahara, toshiakikoike, dauwhe, MattChan, wendyreid, shiestyle, duga, marisa, dlazin, idpf:1 00:58:07 RRSAgent, please draft minutes 00:58:07 I have made the request to generate https://www.w3.org/2021/04/15-epub-minutes.html Zakim 00:58:10 I am happy to have been of service, dauwhe; please remember to excuse RRSAgent. Goodbye 00:58:14 Zakim has left #epub 00:58:40 rrsagent, you are excused 00:58:40 I'm logging. I don't understand 'you are excused', dauwhe. Try /msg RRSAgent help 00:58:48 rrsagent: bye 00:58:48 I see no action items