13:26:01 <RRSAgent> RRSAgent has joined #epub
13:26:01 <RRSAgent> logging to https://www.w3.org/2021/04/09-epub-irc
13:26:03 <Zakim> RRSAgent, make logs Public
13:26:04 <Zakim> please title this meeting ("meeting: ..."), dauwhe
13:26:12 <dauwhe> Meeting: EPUB 3 Working Group Telecon
13:26:20 <dauwhe> Date: 2021-04-09
13:26:26 <dauwhe> Chair: dauwhe
13:26:54 <dauwhe> dauwhe has changed the topic to: https://lists.w3.org/Archives/Public/public-epub-wg/2021Apr/0007.html
13:29:07 <Karen> Karen has joined #epub
13:29:41 <ivan> ivan has joined #epub
13:30:32 <ivan> Chair: wendy
13:30:32 <ivan> Date: 2021-04-08
13:30:32 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-epub-wg/2021Apr/0007.html
13:30:32 <ivan> Meeting: EPUB 3 Working Group Telco
13:44:43 <ivan> Yes, I am fine
13:54:32 <dkaplan3> dkaplan3 has joined #epub
13:57:53 <avneeshsingh> avneeshsingh has joined #epub
13:57:57 <tzviya> present+
13:58:06 <dkaplan3> present+
13:58:07 <avneeshsingh> present+
13:58:11 <ivan> present+
13:58:28 <MattChan> MattChan has joined #epub
13:59:24 <MasakazuKitahara> MasakazuKitahara has joined #epub
13:59:30 <MasakazuKitahara> present+
13:59:42 <toshiakikoike> toshiakikoike has joined #epub
13:59:43 <wendyreid> wendyreid has joined #epub
13:59:51 <CircularKen> CircularKen has joined #epub
13:59:56 <toshiakikoike> present+
14:00:02 <wendyreid> present+
14:00:04 <ivan> present+ CircularKen
14:00:10 <MattChan> present+
14:00:17 <dauwhe> present+
14:00:19 <BenSchroeter> BenSchroeter has joined #epub
14:00:21 <gpellegrino> gpellegrino has joined #epub
14:00:37 <gpellegrino> present+
14:00:56 <MattChan> scribe+
14:00:59 <mgarrish> mgarrish has joined #epub
14:01:48 <dlazin> dlazin has joined #epub
14:01:53 <duga> duga has joined #epub
14:01:56 <George> George has joined #epub
14:02:00 <duga> present+
14:02:04 <mgarrish> present+
14:02:05 <ivan> present+ george
14:02:05 <ivan> present+ brady
14:02:08 <ivan> present+ charlesL
14:02:13 <George> present+
14:02:18 <CharlesL> CharlesL has joined #epub
14:02:18 <ivan> present+ dlazin
14:02:27 <ivan> present+ billk
14:02:50 <MattChan> wendyreid: welcome
14:02:51 <MattChan> TOPIC: Overview of TFs
14:02:53 <CharlesL> present+
14:02:57 <MattChan> wendyreid: we've had 2 TF meetings
14:03:11 <MattChan> ... FXL a11y TF, and virtual locators TF
14:03:23 <MattChan> ... both TFs have figured out what they want to work on, and are starting up
14:03:27 <Bill_Kasdorf_> Bill_Kasdorf_ has joined #epub
14:03:30 <MattChan> ... FXL a11y meeting every tuesday
14:03:46 <MattChan> ... still working out timing of virtual locators TF, since it is more international
14:03:58 <MattChan> ... more issues with timezones
14:04:06 <ivan> present+ mgarrish
14:04:53 <MattChan> ... FXL a11y is focusing on updating Daisy KB info with problems that we see in the content today, write some best practices documentation, and experimentation with using more modern CSS (e.g. grid, flexbox) instead of hacking in functionality in spec
14:05:13 <MattChan> ... virtual locators TF trying to figure out use-cases
14:05:31 <MattChan> ... there is now a wiki if you have use cases to add
14:05:49 <MattChan> ... still trying to figure out a date for the scripting meeting
14:06:04 <MattChan> ... it will not currently be a TFs, but rather a series of a couple meetings
14:06:19 <ivan> present+ teenya
14:06:23 <Teenya> Teenya has joined #epub
14:06:23 <wendyreid> https://github.com/w3c/epub-specs/wiki/Use-Cases-for-Virtual-Locators
14:06:24 <MattChan> ... please send Doodle to anyone interested in working on epub scripting
14:06:37 <wendyreid> q?
14:06:37 <gpellegrino> q+
14:06:42 <wendyreid> ack gpellegrino
14:06:42 <Teenya> present+ (Apologies for tardiness)
14:06:51 <MattChan> gpellegrino: can you please reshare Doodle for scripting?
14:07:01 <wendyreid> https://doodle.com/poll/q9uwcpfep62wkty9?utm_source=poll&utm_medium=link
14:07:26 <MattChan> TOPIC: Testing Update
14:08:05 <MattChan> dlazin: good morning, all. I've made a few first steps, and would like to talk about how you can contribute
14:08:16 <BenSchroeter> present+
14:08:44 <wendyreid> tinyurl.com/epub-tests
14:09:12 <MattChan> ... i've complied a spreadsheet, it is a catalogue of all the normative statements in the RS spec
14:09:32 <MattChan> ... it is no longer exactly accurate, since we've been making modifications to the spec
14:09:41 <MattChan> ... let's just focus on the MUSTs for now
14:09:54 <MattChan> ... there are ~186 normative statements in RS spec
14:10:11 <MattChan> ... some might require multiple tests per line
14:10:38 <MattChan> ... among these 105 MUSTs
14:11:26 <MattChan> ... in the github tests repo, dauwhe has contributed some and I have written some
14:11:42 <MattChan> ... currently organized according to the order of the spec
14:11:45 <Garth> Garth has joined #epub
14:12:05 <MattChan> ... I've started writing tests for the media types
14:12:24 <MattChan> ... dauwhe has written a test template that anyone can use
14:12:51 <wendyreid> q?
14:13:14 <Garth> present+ Garth
14:13:20 <MattChan> ... getting through 105 MUSTs will be a lot of work, so please contribute if you can
14:13:28 <ivan> q+
14:13:32 <wendyreid> ack ivan
14:13:44 <MattChan> ... put your name in the far right column to claim a particular statement if you're writing a test for it
14:13:49 <MattChan> ... please only claim one at a time
14:14:32 <MattChan> ivan: let's say I put in an XHTML containing a jpg, then I make it an epub using my own machine?
14:15:03 <MattChan> dlazin: there might be a script in the repo that does that, but I've just been using eCanCrusher
14:15:10 <gpellegrino> * to Ivan: https://www.docdataflow.com/ecancrusher/ :)
14:15:11 <dauwhe> q+
14:16:02 <MattChan> ivan: i think we should try to make a service online to help people create those epubs, or a set of instructions to help people figure out what they need to install on their machine
14:16:08 <wendyreid> ack dauwhe
14:17:12 <MattChan> dauwhe: i tried to automate a bunch of stuff when I started testing, but the only thing that really saved time was that little testing template that is already up there in the repo
14:17:21 <ivan> q+
14:18:05 <MattChan> dlazin: i'm happy to do a little introduction for people who are new to epub authoring
14:18:17 <wendyreid> ack ivan
14:18:49 <MattChan> ivan: we eventually need a way to prepare a report of our testing
14:19:05 <MattChan> ... makes sense to think about metadata about our testing now, rather than when we already have 200 tests...
14:19:20 <MattChan> dlazin: can you take a look at the spreadsheet and call out what we are missing?
14:19:33 <MattChan> ... we'd export the spreadsheet to JSON when we are done
14:19:49 <MattChan> ... but yes, let's set it up so that it contains all the metadata that we'll need
14:20:06 <MattChan> TOPIC: WebIDL/epubReading System
14:20:08 <dlazin> tinyurl.com/epub-tests for the testing spreadsheet :)
14:20:10 <wendyreid> https://www.irccloud.com/pastebin/SvqIOfmv/
14:20:13 <ivan> scribejs, issue 1610,1420
14:20:16 <dlazin> https://tinyurl.com/epub-tests
14:20:22 <ivan> https://github.com/[w3c/epub-specs#1](https://github.com/w3c/epub-specs/issues/1610)420
14:20:22 <ivan> https://github.com/[w3c/epub-specs#1](https://github.com/w3c/epub-specs/issues/1610)610
14:20:55 <MattChan> ivan: we have a separate section with a small webIDL describing the RSO
14:21:01 <MattChan> ... i have two questions
14:21:17 <MattChan> ... first, should it be normative? (it currently is)
14:21:21 <mgarrish> there's also https://github.com/w3c/epub-specs/issues/716
14:22:01 <MattChan> ... second, if normative, we may run into the problem that webIDL is considered by browser implementors as something they have to implement
14:22:24 <MattChan> ... other specs I've worked on have used webIDL, and it has gotten us into trouble
14:22:33 <dauwhe> q+
14:22:41 <MattChan> ... I'd prefer to avoid this if possible
14:23:06 <MattChan> ... the spec also calls it a JS epubReadingSystem object, but webIDL is supposed to be language independent
14:23:12 <wendyreid> ack dauwhe
14:23:41 <MattChan> dauwhe: is there something in W3C policy that says if you use webIDL then all browsers must implement it?
14:24:00 <MattChan> ivan: no, BUT i'd rather not get into this type of discussion about formalities down the line
14:24:20 <duga> q+
14:24:36 <MattChan> ... some other people might disagree with me and say that implementation is required
14:24:45 <wendyreid> ack duga
14:25:22 <MattChan> duga: i think webIDL is for things intended to be implemented by browsers
14:26:03 <MattChan> ... but it does seem to be a normative requirement because of statements that we make later on in the appendix
14:26:17 <MattChan> wendyreid: can someone please explain the importance of webIDL?
14:27:29 <wendyreid> https://www.w3.org/TR/epub-rs-33/#app-epubReadingSystem
14:27:36 <Garth> q?
14:27:40 <Garth> q+
14:27:45 <mgarrish> q+
14:27:57 <MattChan> duga: we were just trying to describe the RSO stuff using webIDL
14:28:19 <MattChan> tzviya: one of our goals is the define the role of the RS more clearly, and I'm not sure that this section does that?
14:28:35 <MattChan> dauwhe: I think it does, webIDL is the industry standard for describing APIs
14:28:35 <wendyreid> ack Garth
14:28:57 <MattChan> Garth: maybe we can just describe it in JS?
14:29:07 <MattChan> ivan: I think yes
14:29:09 <dlazin> q+
14:29:49 <wendyreid> ack mgarrish
14:29:55 <duga> q+
14:30:00 <MattChan> Garth: so webIDL might be fine to use, but if JS is also fine to use, then maybe we can resolve this small thing by just using JS
14:30:17 <dauwhe> q+
14:30:21 <MattChan> mgarrish: some time back there was also discussion about maybe dropping RSO entirely...
14:30:46 <wendyreid> ack dla
14:31:00 <MattChan> ivan: if we turn that section into informative only, then that allows us to bypass formal objections down the line?
14:31:41 <wendyreid> ack duga
14:31:42 <MattChan> dlazin: are we currently just discussing the question of how to DOCUMENT RSO? And how widely implemented is it?
14:31:58 <MattChan> dauwhe: some do, some don't
14:32:24 <MattChan> Garth: do we care about the requireness of this given that support isn't unanimous
14:32:48 <MattChan> duga: not sure how common this is. We should write a test and try it in some RSes
14:32:57 <MattChan> ... has anyone in this call implemented it?
14:33:31 <dlazin> q+
14:33:32 <MattChan> ... yes it is normative now, and there are MUST statements that point to this, but on the other hand we might spend a lot of time on this only to find out that no one really uses it
14:33:34 <dauwhe> q?
14:33:52 <MattChan> ... if no one implements this, then we can decide whether to drop it or make it non-normative etc.
14:34:14 <wendyreid> ack dauwhe
14:34:31 <MattChan> ... and publishers should tell us if they use JS in their epubs, and if yes, then have they relied on this being available
14:34:49 <MattChan> dauwhe: we've used this because of the state of epub interoperability
14:35:11 <MattChan> ... we use this to figure out which RS our epub is in
14:35:20 <CircularKen> q+
14:35:21 <MattChan> ... e.g. UA sniffing
14:35:28 <wendyreid> ack dla
14:36:15 <MattChan> dlazin: speaking of interop, one of the testing questions is: When we identify that not RS currently supports, e.g. Opus, does that mean that it ought not to be a core media type?
14:36:42 <MattChan> ... my feeling is that giving guidance on where we want to go is a pathway towards future interop
14:37:25 <MattChan> ... but when we mandate things that are not widely used, that leads RS implementors to not know what to trust
14:37:39 <wendyreid> ack CircularKen
14:37:46 <MattChan> ... and I'm happy to write a test about this
14:38:45 <MattChan> CircularKen: a lot of FXLs with interactive content rely on scripting, so this is important
14:39:02 <MattChan> dauwhe: it is possible to support scripting without relying on webIDL
14:39:44 <MattChan> ivan: for now, do we say that this thing should be implemented by RS?
14:39:55 <dauwhe> s/webIDL/epubReadingSystem Object/
14:40:11 <MattChan> ... the other possibility is that we keep as normative requirement, but flag as at risk
14:40:35 <avneeshsingh> +1 to ivan, flag at risk and keep as normative requriement for now
14:40:46 <MattChan> ... I'm leaning towards the second option, plus, rewording the section using JS
14:41:43 <wendyreid> Proposed: Flag appendix A as at-risk, keep as a normative requirement and test implementation, remove the WebIDL
14:41:52 <Garth> +1
14:41:53 <gpellegrino> +1
14:41:55 <duga> +1
14:41:55 <mgarrish> +1
14:41:58 <dkaplan3> +1
14:41:58 <MasakazuKitahara> +1
14:41:59 <avneeshsingh> +1
14:42:00 <dlazin> +1
14:42:01 <BenSchroeter> +1
14:42:02 <MattChan> +1
14:42:06 <ivan> +1
14:42:10 <tzviya> +1
14:42:14 <George> +1
14:42:14 <CharlesL> +1
14:42:17 <wendyreid> Resolved: Flag appendix A as at-risk, keep as a normative requirement and test implementation, remove the WebIDL
14:42:34 <MattChan> TOPIC: CSS Direction
14:42:34 <wendyreid> https://github.com/w3c/epub-specs/issues/1614
14:42:43 <ivan> scribejs, issue 1614
14:42:53 <dauwhe> q+
14:43:22 <MattChan> ivan: in the core spec, there is an item which says that RS must not use CSS features for direction and bidi
14:43:26 <ivan> > Because HTML UAs can turn off CSS styling, we recommend HTML authors to use the HTML dir attribute and element to ensure correct bidirectional layout in the absence of a style sheet. Authors should not use direction in HTML documents.
14:44:09 <MattChan> ... in the CSS documentation this is advice based on the fact that certain browsers may not implement CSS
14:44:26 <MattChan> ... core spec turns this into a MUST
14:44:45 <MattChan> ... should we depart from CSS spec in this way?
14:45:09 <MattChan> ... if we keep it as it is, then what should RS do if they do encounter CSS that uses these features?
14:45:12 <wendyreid> ack dauwhe
14:45:35 <MattChan> dauwhe: epub says that you can't use CSS direction since epub 3.0
14:45:41 <MattChan> ... this is enforced in epubcheck
14:46:20 <mgarrish> q+
14:46:22 <MattChan> ... CSS group is very adamant that this is the wrong way to provide info about text direction
14:46:30 <duga> q+
14:46:32 <MattChan> ... preferring use of HTML attribute dir
14:46:46 <MattChan> ... everyone seems happy with this state of things
14:47:12 <ivan> q+
14:47:15 <MattChan> ... understand that current language is slightly different from CSS, but i just don't see the value of changing this right now
14:48:05 <MattChan> ... there are other examples where epub spec has been more stringent than average
14:48:14 <wendyreid> ack mgarrish
14:48:21 <MattChan> ... in terms of what RS should do if they see it, I think they should just follow the CSS
14:48:27 <MattChan> ... no special treatment necessary
14:48:54 <MattChan> mgarrish: RS interop is critical, part of the rationale for having these requirements
14:49:32 <wendyreid> ack duga
14:50:10 <MattChan> duga: this wasn't just fantasai's opinion, she was a representative of the CSS WG
14:50:52 <wendyreid> ack ivan
14:51:07 <MattChan> ... also, if you use epubcheck as part of your ingestion pipeline, you might reject an epub if you include this sort of CSS
14:51:20 <dauwhe> q+
14:51:38 <MattChan> ivan: current the RS spec doesn't say anything about this, even though we so strongly say this in core
14:51:53 <MattChan> s/current the/currently the
14:52:09 <MattChan> ... uncomfortable with the disconnect
14:52:10 <wendyreid> ack dauwhe
14:52:21 <tzviya> q+
14:52:22 <MattChan> ... also, the language needs to be updated to account for SVG
14:52:38 <wendyreid> ack tzviy
14:52:52 <MattChan> dauwhe: comfortable with not putting any special requirements on RS when they see this
14:52:57 <Garth> q?
14:52:59 <Garth> q+
14:53:04 <wendyreid> ack Garth
14:54:06 <MattChan> Garth: could we acknowledge this in RS spec, and specifically say that an RS is able to do whatever it feels is appropriate?
14:54:19 <MattChan> dauwhe: yes, I would agree
14:54:42 <wendyreid> Proposed: Amend the RS section to allow RSs to do whatever they "damn well" please with CSS direction
14:54:45 <tzviya> +1
14:54:46 <Garth> +1
14:54:46 <dkaplan3> +1
14:54:47 <ivan> +1
14:54:48 <CharlesL> +1
14:54:48 <duga> Damn well +1
14:54:50 <wendyreid> +1
14:54:52 <MattChan> +1
14:54:53 <dlazin> +1
14:54:55 <Bill_Kasdorf_> +1
14:54:56 <gpellegrino> +1
14:54:59 <BenSchroeter> +1
14:55:14 <wendyreid> Resolved: Amend the RS section to allow RSs to do whatever they "damn well" please with CSS direction
14:55:48 <MattChan> TOPIC: AOB?
14:56:00 <MattChan> wendyreid: it is (virtual) F2F season
14:56:13 <MattChan> ... thinking of making it similar to what we did with the TPAC one
14:56:14 <George> +1
14:56:26 <MattChan> ... i.e. 3 hour at JP time, followed next day by 3 hour at this time slot
14:56:58 <ivan> q+
14:57:03 <MattChan> ... thinking of May 13/14 or May 27/28
14:57:08 <wendyreid> ack ivan
14:57:38 <MattChan> ivan: May 13 may conflict with public holiday in some parts of EU
14:57:50 <MattChan> ... some people may have holiday plans around that time
14:58:16 <MattChan> gpellegrino: no, that's no a problem for us
14:58:22 <dlazin> q+
14:58:23 <MattChan> s/no a problem/not a problem
14:58:28 <wendyreid> ack dlazin
14:58:41 <dlazin> https://w3c.github.io/epub-specs/epub33/rs/#dc-creator
14:58:42 <MattChan> dlazin: couple quick questions about testing philosophy
14:58:55 <MattChan> ... that is a single para with 2 normative statements in it
14:59:07 <dauwhe> q+
14:59:09 <ivan> q+
14:59:11 <MattChan> ... should that be one test, two tests?
14:59:37 <MattChan> dauwhe: i don't think the division of the spec text should affect testing
14:59:44 <MattChan> ... comfortable treating those as separate tests
14:59:50 <tzviya> +1 to dauwhe
15:00:00 <wendyreid> ack dauwhe
15:00:02 <wendyreid> ack ivan
15:00:13 <MattChan> ivan: very often text in spec is structured to increase readability
15:00:33 <MattChan> ... in practice there are two tests, regardless of how the text is
15:00:42 <dauwhe> q+
15:01:21 <MattChan> dlazin: we are driving towards more interop, so when we can't find independent RS implementations, what do we do? Do we revisit the "mustness" of it?
15:01:25 <MattChan> ivan: yes
15:01:39 <MattChan> dlazin: what about minor RS support?
15:01:42 <CharlesL> CharlesL has left #epub
15:01:54 <MattChan> ivan: it's not up to us to make that minor/major distinction
15:02:07 <MattChan> ivan: also, we have a mandate to maintain backwards compat
15:02:53 <ivan> rrsagent, draft minutes
15:02:53 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/09-epub-minutes.html ivan
15:04:23 <ivan> zakim, end meeting
15:04:23 <Zakim> As of this point the attendees have been tzviya, dkaplan, avneeshsingh, ivan, MasakazuKitahara, toshiakikoike, wendyreid, CircularKen, MattChan, dauwhe, gpellegrino, duga,
15:04:26 <Zakim> ... mgarrish, george, brady, charlesL, dlazin, billk, teenya, (Apologies, for, tardiness), BenSchroeter, Garth
15:04:26 <Zakim> RRSAgent, please draft minutes
15:04:26 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/09-epub-minutes.html Zakim
15:04:29 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
15:04:33 <Zakim> Zakim has left #epub
15:04:45 <dkaplan3> dkaplan3 has left #epub
15:04:49 <ivan> rrsagent, bye
15:04:49 <RRSAgent> I see no action items