08:49:29 RRSAgent has joined #pmwg 08:49:34 logging to https://www.w3.org/2025/04/04-pmwg-irc 08:49:34 RRSAgent, make logs Public 08:49:35 Meeting: Publishing Maintenance Working Group 08:49:56 ivan has changed the topic to: Meeting Agenda 2025-04-04: https://docs.google.com/document/d/1SePiVZDlyWNg5nhqBffCXSh7_EGC5IXPz9nTd8i1sdw/edit?tab=t.dbiebco88mfi#heading=h.gouartxyduig 08:49:57 Chair: wendy, shinya 08:49:57 Agenda: https://docs.google.com/document/d/1SePiVZDlyWNg5nhqBffCXSh7_EGC5IXPz9nTd8i1sdw/edit?tab=t.dbiebco88mfi#heading=h.gouartxyduig 08:49:57 Meeting: PM Working Group F2F, Sophia Antipolis, 2nd Day 08:51:07 present+ 08:53:21 shiestyle has joined #pmwg 08:54:15 present+ 08:54:23 present+ 08:54:47 George has joined #pmwg 08:55:23 present+ 08:56:23 toshiakikoike has joined #pmwg 08:56:33 present+ 08:57:57 George has joined #pmwg 08:58:24 wendyreid has joined #pmwg 08:59:35 wendyreid has joined #pmwg 08:59:42 present+ 08:59:53 rdeltour has joined #pmwg 09:00:01 present+ 09:01:35 MasakazuKitahara has joined #pmwg 09:01:40 present+ 09:03:01 present+ milena 09:04:13 Avneesh has joined #pmwg 09:04:15 scribe+ 09:04:24 present+ 09:04:38 gautierchomel has joined #pmwg 09:04:38 sue-neu has joined #pmwg 09:04:43 wendyreid: Welcome, agenda review 09:05:00 present+ 09:05:10 present+ 09:05:12 gpellegrino has joined #pmwg 09:05:21 Agenda: https://github.com/w3c/pm-wg/blob/main/meetings/F2FMeetingFrance2025.md 09:05:26 ivan: We made a mistake last week on the 3.4 draft 09:05:29 present+ 09:05:48 Proposal: publish a new note entitled “EPUB Accessibility Techniques 1.1.1” and “EPUB 3 Overview”, with short names “epub-a11y-tech-111” and “epub-overview-34”, respectively, which will supersede the similar 1.1, respectively “3.3” versions of these note. 09:05:52 ... we have a couple of notes that are bound to versions, so we have to publish drafts of those 09:06:01 +1 09:06:04 +1 09:06:06 ... so we need a resolution 09:06:08 +1 09:06:15 +1 09:06:16 +1 09:06:17 +1 09:06:17 +1 09:06:17 q+ 09:06:22 ack George 09:06:23 +1 09:06:24 +1 09:06:27 +1 09:06:30 +1 09:06:36 George: Can this be modified after we publish? 09:06:48 +1 09:06:58 ivan: Yes. The old ones are now frozen to 3.3, all new work happens in the new ones bound to 3.4 09:06:58 RESOLVED: publish a new note entitled “EPUB Accessibility Techniques 1.1.1” and “EPUB 3 Overview”, with short names “epub-a11y-tech-111” and “epub-overview-34”, respectively, which will supersede the similar 1.1, respectively “3.3” versions of these note. 09:07:11 Topic: Footnotes, Extended Descriptions 09:07:34 q+ 09:07:47 wendyreid: We need a better name for this, but we will discuss footnotes/extended descriptions 09:07:51 ack gpellegrino 09:08:17 gpellegrino: Last time we proposed to have a longer list of elements 09:08:22 ... there are several 09:08:42 ... many are for publisher guidance, but no impact on RS implementation 09:08:48 ... so those are out of scope 09:08:53 ... but some need both 09:09:13 ... one is cover, or perhaps fit-width images generally 09:10:05 ... commercial pages is another (may need to ensure it is shown in samples) 09:10:11 ... then poetry 09:10:23 ... and linear/non-linear items 09:10:40 ... and finally css page break property 09:11:19 q+ 09:11:22 ack ivan 09:11:48 +1 09:11:50 ivan: I want to understand, for instance the page-break property - there is a spec 09:11:52 q+ 09:11:57 scribe+ 09:12:09 ... linear/non-linear 09:12:11 q+ 09:12:15 q+ 09:12:17 ... what else do we need to say? 09:12:34 ack duga 09:12:36 ... and which spec? a11y? rs? 09:12:47 duga: I think the problem in CSS page-break 09:13:03 ... is that its challenging, it was almost removed until we asked them not to 09:13:14 ... the spec is very vague, easy to do nothing and be compliance 09:13:50 ... "avoid" is flimsy, elements it applies to is strange, only to block-level elements, its hard to tell what to do 09:14:05 ... it's left up to the implementer 09:14:18 ... and what happens in the reader, especially in scrolling contexts 09:14:25 ... linear/non-linear is intentionally vague 09:14:43 s/compliance/compliant/ 09:14:47 ack gpellegrino 09:15:02 gpellegrino: I think this all at a level of guidance and notes 09:15:09 ... but having guidance is useful 09:15:33 ack George 09:15:35 q+ 09:15:38 ... We have guidance like this in DAISY knwledge base, but only for authors 09:15:47 George: Add notes to the list 09:15:57 Hadrien has joined #pmwg 09:16:03 q+ 09:16:06 present+ 09:16:17 ack wendyreid 09:16:19 ... We find they are supported when in the file, not when in another file 09:16:22 zakim, who is here? 09:16:22 Present: ivan, duga, shiestyle, George, toshiakikoike, wendyreid, rdeltour, MasakazuKitahara, milena, Avneesh, gautierchomel, sue-neu, gpellegrino, Hadrien 09:16:24 s/notes/endnotes/ 09:16:26 On IRC I see Hadrien, gpellegrino, sue-neu, gautierchomel, Avneesh, MasakazuKitahara, rdeltour, wendyreid, George, toshiakikoike, shiestyle, RRSAgent, Zakim, duga, Makoto, plh, 09:16:26 ... tzviya, ivan 09:16:36 q+ 09:16:42 present+ laurent 09:17:08 wendyreid: Page break is one that I noted as important. I also added dpub aria and RS behavior (e.g. how to use it in RS) 09:17:10 ack Avneesh 09:17:28 Avneesh: DAISY board approved a RS requirements group under DAISY 09:17:39 ... we are defining all these things under that group 09:17:54 q+ 09:17:58 ... It is a little beyond mainstream, since it is a11y focused 09:18:11 ack Hadrien 09:18:35 Hadrien: Back to page breaks, historically we had specialized properties 09:19:03 ... One problem we have is that we don't really use CSS page break model 09:19:09 q+ 09:19:16 ... so this doesn't integrate well 09:19:19 q+ 09:19:30 q-- 09:19:43 ... we had this because there was a point in time where we had specialized renderers, but that is no longer true 09:20:02 ... I see the use case, but there is a disconnect between this and reading system behavior 09:20:07 ack sue-neu 09:20:32 sue-neu: The page break property, I work on books for younger readers 09:20:49 ... Sometimes I need an image and text together 09:21:01 ... so I need a way to keep things grouped 09:21:09 ack ivan 09:21:14 ... so I would love to keep that together 09:21:22 q+ 09:21:31 ivan: I would like to understand where we are going 09:21:38 q+ 09:21:45 ... endnotes, footnotes, they are all problematic 09:22:21 ... There are guideline for authors and RS, but I have no idea what we would have to change in the specs 09:22:36 q+ 09:22:52 ... So if we go down guidelines, then the DAISY work makes more sense. If they are doing it we should cooperate with them to avoid duplication of labor 09:23:02 ... But first we have to decide what we want 09:23:04 q- 09:23:11 ack wendyreid 09:23:33 q? 09:23:41 wendyreid: The question we have is where to do this (spec or elswhere) 09:23:50 ... and the answer seems to be somewhere else 09:24:02 ... This feels more like a techniques document 09:24:18 ... One thing we can and should include is a test suite 09:24:22 q+ 09:24:35 ... So we you can check for support in RSes 09:25:12 ack gpellegrino 09:25:12 q+ 09:25:18 gpellegrino: I agree 09:25:32 ... to reply to Ivan, it is a little different in pub than web 09:25:37 q+ 09:25:42 ... In web you can control the UX 09:26:04 ... in epub, there isn't really JS support and more things are declarative 09:26:13 ... we rely on RS to display the content 09:26:30 ... so we should agree among the parties on how to display this 09:26:51 ... for instance we gave guidance to Adobe on how to handle certain things 09:27:01 ack George 09:27:09 ... And they asked if this was correct or not, we said to just trust us. It worked out 09:27:56 George: There is a relationship between the RS and the content where if you can depend on the way a RS will work 09:28:25 ... So right now we use backlinks from endnotes, but there are other types of links 09:28:59 ack Hadrien 09:29:02 ... And some RS can handle go back from them, but we are putting in backlinks which is bad. It would be better if we could depend on the RS to maintain a backstack 09:29:33 Hadrien: I think it is a tricky topic, existing implementation can guide us 09:29:49 ... for instance lack of footnote use not being used in Japan is a big deal 09:29:56 ... and needs to be fixed 09:30:18 ... The RSes need to fix this 09:30:29 ... There are some things we can do in readium and thorium 09:30:43 q+ 09:31:03 ... for instance, we will handle endnotes that are in another document 09:31:09 q+ 09:31:20 present+ charles 09:31:23 CharlesL has joined #pmwg 09:31:33 present+ 09:31:41 s/present+ charles// 09:31:47 ... Go back is good, but popup footnotes are useful 09:31:59 ... But they tend to be in plain text 09:32:31 ... it would be nice to use some other affordance like a sidebar that properly display the styled html 09:32:40 ... But this should be a pref 09:33:01 ... We can never be one size fits all for this, so we will probably do all three 09:33:14 ... of course this only applies to us and anyone that uses us 09:33:30 ack ivan 09:33:34 ... It is hard to see how the wg addresses this 09:33:45 ivan: So I stubbornly come back to procedural side 09:34:07 ... I see 2 docs, guidelines for authors, and another for RSes 09:34:24 ... in both cases, adding test cases and adding it to our test suite is a great idea 09:34:31 ... but this is significant work 09:34:53 ... So if we pass this as a resolution we need to assign editors and people who will lead the effort 09:35:03 ... this can't go to me and Matt 09:35:11 ack sue-neu 09:35:15 ... if we can't find someone to do that then we should close the issue 09:35:57 q+ 09:35:58 sue-neu: To build on that, we should also consider that this is not a document we can do one and done. It will need to be updated as we go along 09:36:01 ack shiestyle 09:36:17 Laurent9 has joined #pmwg 09:36:40 shiestyle: Popup foot notes are hardly used in Japan, but if have long text for a11y we have to find a way to do this (e.g. extended desc for imaages) 09:36:53 ack duga 09:37:08 ... If it is easy to find a suitable approach it is fine in Japa 09:37:23 s/Japa/Japan/ 09:37:38 duga: Footnotes, there is some real guidance we need to give to handle it properly, it's very inconsistent right now, it's helpful to have authoring guidance 09:37:49 ... you need to guess what happens when you encounter a link 09:38:07 ... the sidebar idea, what if multiple footnotes, can you show them all 09:38:21 ack wendyreid 09:38:25 q+ 09:38:35 wendyreid: we do need people to work in this 09:38:40 q? 09:38:55 ... it is also really important, so it is hard to accept that we might not have someone to do this 09:39:22 ... And to what sue-neu said, things don't change too fast 09:40:02 ... so the more confidence you have that something is a link to a footnote, the better 09:40:03 ack Geoq 09:40:07 ack George 09:40:12 mgarrish has joined #pmwg 09:40:19 George: One of the other things that looks like a footnote but isn't, is an annotation 09:40:22 q+ 09:40:28 ... specifically author provided annotations 09:40:52 q+ 09:40:58 ... Do we ignore this and just call it a footnote? 09:41:02 ack Hadrien 09:41:09 ... for instance the anmoted Alice 09:41:32 Hadrien: There is also the affordance for tap or double tap interact with an image 09:41:39 ... and another is tables 09:41:54 present+ mgarrish 09:42:01 ... image is often implemented, but there is a lot to explore (e.g. extended desc) 09:42:16 ... But tables is a big one and why people really like PDF 09:42:33 ... It would be really nice to have a good implementation 09:42:34 ack Avneesh 09:43:01 Avneesh: On to the work management side, one thing the a11y TF can do is create an index for these topics 09:43:17 ... Since it is all the same people who are also working on the knowledge base 09:43:31 ... so a11y TF can at least take that up 09:43:59 wendyreid: That is a good first step. Maybe we can take that info and go from there 09:44:15 ... anything else we want to include or are missing? 09:44:40 George: Do these impact dpub aria? do we need new roles? 09:44:50 Avneesh: Yes, and this will help us identify it 09:44:57 LaurentLM has joined #pmwg 09:45:11 q? 09:45:35 q+ 09:45:41 ack Avneesh 09:45:45 George: Some question about JAWS and NVDA and how it interacts and fits into the RS side of things 09:45:57 Avneesh: Those are things that are going on and will continue to 09:46:06 q+ 09:46:15 ... This is where the index will guide what we are working 09:46:29 ... on. It is hard to create a plan at this stage 09:46:41 ... There is ongoing work that will go on for 5 or 10 years 09:47:06 George: We have core media types, do we have the same concepts for behaviors? 09:47:09 ack CharlesL 09:47:12 all: no 09:48:09 CharlesL: Back when the diagram center was around, someone from Norton created a plug in that would, for images, grab info (extended desc, etc) 09:48:29 ... So when you hover you would get info 09:48:41 q+ 09:48:43 q+ 09:48:47 ... he made an API for that, I am not sure what happened to that work 09:49:02 ... this might be similar to what Hadrien mentioned 09:49:06 ack Hadrien 09:49:13 Hadrien: It is very similar 09:49:37 ... I was thinking a view where you could interact with the image along with desc 09:49:39 chez editis ils ont les longues descriptions en popup. 09:50:02 s/chez editis ils ont les longues descriptions en popup. / / 09:50:15 ... so the general concept is the RS would have affordances over fragments of the doc 09:50:23 ... but it is hard if you also have JS 09:50:35 ... so really hard with fixed layout with JS 09:50:54 ... so if there is JS, we will probably disable them 09:51:05 ... except maybe side panel or something like that 09:51:16 q+ 09:51:18 ack ivan 09:51:50 ivan: I don't know if the presentation we just saw from CharlesL was JS based 09:51:55 Avneesh: Yes it was 09:52:25 ivan: We said we need to go to html, I have the feeling that the aversion to JS can't last for long 09:52:37 ... so I know it is allowed, but we also say don't do it 09:52:53 ... I don't think long term that is an option 09:52:56 q+ 09:52:58 q+ 09:53:16 Makoto4 has joined #pmwg 09:53:17 ... I think we need some ways to do this programmatically 09:53:22 q+ 09:53:30 q- 09:53:43 ... That tendancy is there and people will be less and less interested in declarative 09:53:44 ack George 09:53:52 ... so we need to allow it on the RS saide 09:53:54 q+ 09:54:19 George: There is a lot going on with visualizations so I kind of agree with Ivan 09:54:46 present+ 09:54:51 ... Also being able to hold things together might be a thing for dpub aria 09:54:56 ack duga 09:55:04 duga: You can do that with page-break: avoid 09:55:11 ... page break is not a great way of doing anything 09:55:20 ... it's remarkably expensive to get that info from the DOM 09:55:42 ... I had a regex to check if page-break was used in a file, when its present it has a cost to rendering 09:55:50 ... to Ivan's side, we had a spec for that 09:56:06 ... what if you wanted to do interesting data viz in reflow, widgets 09:56:17 ... it was never used, no one wanted to figure out the widget spec 09:56:32 ... my feeling is, you might be right, but then EPUB is dead, all publications are now web pages 09:56:59 ... the web is a development platform for applications, once EPUB readers become hosts for applications, it makes no sense, browsers are already very good at that 09:57:06 ... I have no interest in recreating web browsers 09:57:12 ... publishers don't want to write applications 09:57:34 ... if you want advanced things, do it on the web, but for straightforward content, use EPUB 09:57:40 ack Hadrien 09:57:46 Hadrien: I wanted to say more on that 09:58:04 ... I hve had to deal with epub files, where each file was a react app 09:58:10 ... so I know what it takes to do that 09:58:26 ... I think there is some value in consistency in affordances 09:58:37 ... that might not be available otherwise 09:58:53 ... there is also desire to do your own thing that won't be a problem 09:59:18 ... The way we handled this with fixed layout and JS was to do as little as possible 09:59:43 ... So you are left with the spine and toc, and that's about it 09:59:51 ... we could do that for reflow 10:00:01 ... we would drop pagination 10:00:16 ... and maybe add some affordances 10:00:24 ... some thing would be hard 10:00:36 ... bookmarks maybe but annotations are hard 10:00:46 ... so we may have to do that 10:01:01 ... The people who want to do that don't like containers 10:01:17 ... So remote resources come up and are problematic 10:01:27 ... it is intersesting to explore 10:01:37 ... there are some things you gain, some you lose 10:01:49 ... I am not sure if users will be happy with lack of consistency 10:01:52 ack sue-neu 10:02:47 sue-neu: I agree with ivan that one reason we don't pull in younger people is lack of scripting 10:03:11 q+ 10:03:11 ... But I really hate the idea that epub is dead, as we have a lot of them 10:03:38 q- 10:03:38 wendyreid: nest steps, a11y TF will create an index 10:03:51 s/nest/next/ 10:05:29 scribe+ 10:05:36 Topic: Dark Mode 10:05:51 duga: [shares screen] 10:06:03 ... I noticed this a while ago when we implemented dark mode in the specs 10:06:16 ... the web has caught on to the fact that people like to read in different colour modes 10:06:24 ... we've had it in ebooks for 30+ years 10:06:29 ... the web has caught up! 10:06:36 ... reading systems often have 2+ modes 10:06:45 ... this interacts oddly with the platform you are on 10:06:59 ... if your platform is on dark mode, you may not want to read that way, the RS will override 10:07:16 ... CSS has this cool way of making the web page adapt to the mode of the device 10:07:21 ... [sample on screen] 10:07:23 q+ 10:07:30 ... you can specify different CSS for light mode or dark mode 10:07:39 ... RS do strange things to make colours work 10:08:06 ... Play books has light, dark, sepia, and nightlight, this is mapped to different activities 10:08:31 ... depends on the device, on Android, the activity can be light or dark, and the web view will pick up the activity, similar on iOS, no idea what happens on windows 10:08:49 ... since this is automatic, the webview is extracting these styles and implementing them 10:09:01 ... tried this sample on several platforms 10:09:06 ... to see what would happen 10:09:34 ... what happens is, if you are in anything other than light mode, these styles are ignored for colours, discarded, no issues 10:09:38 gautierchomel_ has joined #pmwg 10:10:16 ... in light mode/neutral mode, they are ignored or follow the setting of the current view. The colours might get mixed, or the device overrides to dark mode. 10:10:25 ... only affects light/neutral mode 10:10:29 ... doesn't apply in dark mode 10:10:52 ack gpellegrino 10:10:54 ... it's horribly inconsistent, no issues today but might be an issue in future, we might want to warn publishers 10:11:29 q+ 10:11:31 gpellegrino: EPUB is dead, the way RS managed this for years was problematic for a11y, if the content creator used colours, it would get messed up when the themes were added 10:11:45 ... colours would switch improperly, I'm not sure we should suggest not to use 10:11:49 q+ 10:12:02 ... using media queries we can learn about specific colours or modes for a11y 10:12:29 ... maybe we should require RS to use the browser method, and if the EPUB creator does not declare, the RS can apply their stylesheet 10:12:40 ... if the EPUB creator declares, the RS should listen 10:12:59 duga: The problem with that, EPUB ecosystem is much richer than web, people have been reading long form contnet for a long time 10:13:16 ... it's all over the place on different platforms 10:13:42 q? 10:13:45 gpellegrino: You can still offer sepia, if the EPUB creator provides dark or light, you should honour that 10:13:57 duga: What about charcoal, Kobo has that + dark mode 10:14:06 ... Thorium doesn't have light, it has neutral 10:14:10 ... CSS doesn't mandate names 10:14:21 ... we could make a list 10:14:36 ... my reason for not going down that road, figuring out all the variations is challenging 10:14:37 ack Hadrien 10:14:45 Hadrien: I don't see how this could work 10:14:53 ... just assessing the presence of these things would be hell 10:15:04 ... the only place this could work is FXL 10:15:18 ... reflowable is "whatever I want", many apps let you set all the colours 10:15:33 ... I don't believe that author intent can be preserved in this 10:15:46 q+ 10:15:47 ... FXL is different because the relationship with RS and content is different 10:15:58 ... only thing RS might do with FXL is spread layout or zooming 10:16:08 q+ 10:16:10 ... doing this in FXL would be fine, but in reflow it opens a huge can of wor,s 10:16:22 ack ivan 10:16:23 ... incredibly difficult to implement without breaking expected behaviour 10:16:49 ivan: I am more with Gregorio on this, if I am an author take the responsibility to use the CSS and declare colours, 10:16:59 ... that is a request to the RS to hand off the settign 10:17:05 ... I set up these things 10:17:24 ... that does not seem related to the FXL thing 10:17:29 ... I don't see the problem with that 10:17:32 q+ 10:18:01 duga: You don't do UX for reading systems 10:18:06 ... RS implementors are horrified 10:18:12 ack gautierchomel_ 10:18:33 gautierchomel_: The question raised by Gregorio, and the accessibility part, we're not asking to have author style maintained in reflow 10:18:53 ... the point is to provide a mode accessible RX in some modes, that some RS can't handle right now 10:19:14 q+ 10:19:17 ... I agree with Ivan, if the EPUB creator makes a mistake, the responsibility falls to them, it should be used wisely 10:19:30 ... it's an accessibility problem 10:19:51 q+ 10:19:51 ... some content becomes unreadable when the colour is changed, but some experts know how 10:19:53 ack duga 10:20:04 duga: As a reader of books, I would argue you have no idea how I want to read 10:20:26 ... you create light and dark mode, as a signal to the reading system, it's not trivial to detect but possible 10:20:40 ... my device is in dark mode 100% of the time, and 100% of the time I read in light mode 10:20:47 q+ 10:20:55