21:32:03 <RRSAgent> RRSAgent has joined #epub
21:32:03 <RRSAgent> logging to https://www.w3.org/2022/09/13-epub-irc
21:32:06 <Zakim> RRSAgent, make logs Public
21:32:07 <Zakim> please title this meeting ("meeting: ..."), ivan_
21:32:25 <ivan_> ivan_ has changed the topic to: Meeting Agenda 2022-09-13: https://www.w3.org/mid/454b0512194eab8532527298602ee9be@w3.org
21:32:26 <ivan_> Chair: dauwhe, wendy, shinya
21:32:26 <ivan_> Date: 2022-09-13
21:32:26 <ivan_> Agenda: https://www.w3.org/mid/454b0512194eab8532527298602ee9be@w3.org
21:32:26 <ivan_> Meeting: EPUB 3 Working Group F2F, 2nd Day
21:32:30 <ivan_> present+
21:36:56 <dauwhe> dauwhe has joined #epub
21:43:00 <wendyreid> present+
21:47:33 <ivan_> present+ gregorio
21:48:11 <ivan_> present+ John_Roque
21:49:34 <dauwhe> dauwhe has joined #epub
21:54:02 <dhall> dhall has joined #epub
21:54:06 <gpellegrino> gpellegrino has joined #epub
21:56:09 <dauwhe> dauwhe has joined #epub
21:56:19 <dauwhe_> dauwhe_ has joined #epub
21:57:22 <shiestyle> shiestyle has joined #epub
21:57:40 <ivan_> present+ makoto
21:58:08 <shiestyle> present+
21:58:15 <ivan_> present+ symon
21:58:20 <toshiakikoike> toshiakikoike has joined #epub
21:58:40 <ivan_> present+ dauwhe
21:58:46 <dhall> present+
21:58:50 <gpellegrino> present+
21:58:51 <MasakazuKitahara> MasakazuKitahara has joined #epub
21:59:02 <toshiakikoike> present+
21:59:34 <ivan_> present+ MasakazuKitahara
21:59:37 <MasakazuKitahara> present+
22:00:10 <ivan_> present+ dhall
22:00:34 <MURATA> MURATA has joined #epub
22:00:43 <MURATA> present+
22:01:18 <ivan_> present+ billk
22:02:45 <ivan_> present+ maurice_york
22:02:48 <dauwhe> dauwhe has joined #epub
22:03:03 <dauwhe> dauwhe has joined #epub
22:03:19 <Bill_Kasdorf__> Bill_Kasdorf__ has joined #epub
22:03:28 <Bill_Kasdorf__> present+
22:05:16 <wendyreid> zakim, pick a victim
22:05:16 <Zakim> Not knowing who is chairing or who scribed recently, I propose maurice_york
22:05:55 <johnr> johnr has joined #epub
22:06:07 <dauwhe_> scribenick: dauwhe
22:06:44 <dauwhe_> wendyreid: Digital Publishing Salon was this morning
22:06:52 <dauwhe_> ... productive conversation
22:06:59 <dauwhe_> ... surprised by how many attended
22:07:01 <ivan_> Topic: Digital Publishing Salon
22:07:07 <dauwhe_> ... renewed interest in what we're up to
22:07:14 <dauwhe_> ... a couple of themes came out
22:07:32 <dauwhe_> ... format was talking about problems, then further explorations or potential solutions
22:07:38 <dauwhe_> ... six main areas of interest
22:07:40 <nbarron> nbarron has joined #epub
22:07:47 <dauwhe_> ... 1. complex content and a11y
22:07:53 <dauwhe_> ... music, mathml, interactivity
22:08:01 <dauwhe_> ... and building accessible content
22:08:10 <dauwhe_> ... 2. community engagement
22:08:14 <dauwhe_> ... 3. Tools
22:08:19 <dauwhe> dauwhe has joined #epub
22:08:21 <dauwhe_> ... 4. Addressibility, annotations...
22:08:30 <dauwhe_> ... 5. Rights and distribution, libraries, etc.
22:08:36 <dauwhe_> ... 6. Digital-first practices
22:08:42 <dauwhe__> dauwhe__ has joined #epub
22:09:07 <dauwhe_> ... lots of interest in archiving
22:09:31 <Victor_Lopes> Victor_Lopes has joined #epub
22:09:38 <dauwhe_> ... lots of challenges with tools, producing accessible files
22:09:46 <dauwhe_> ... how can people produce better content
22:10:03 <dauwhe_> ... Mateus and I have not yet gone over the notes to document themes
22:10:04 <MURATA> FYI: SC34/JWG7 is interested in long-time preservation of EPUB.
22:10:12 <dauwhe_> ... will probably need another session
22:10:33 <Yuyu> Yuyu has joined #epub
22:10:34 <ivan_> present+ brady
22:10:40 <ivan_> present+ dan
22:10:46 <dauwhe_> ... not yet enough for a new charter for a digipub group
22:10:55 <dauwhe_> ... need to do more homework
22:11:01 <dauwhe_> ... any questions?
22:11:21 <Bill_Kasdorf__> q+
22:11:23 <duga> duga has joined #epub
22:11:27 <dauwhe_> ack bi
22:11:29 <wendyreid> ack Bill_Kasdorf__
22:11:37 <dauwhe_> Bill_Kasdorf__: the figma worked pretty darn well
22:11:41 <dauwhe_> ... and that's hard to do
22:11:56 <dauwhe_> wendyreid: I'm exporting that content to CSV and make it more accessible
22:12:07 <MURATA> FYI: This is extracted from the JWG7 recommendations.
22:12:10 <MURATA> Call for leadership for PWI on EPUB long-term preservation (EPUB/A) Mindful of ISO/IEC TS 22424-1:2020 Digital publishing - EPUB3 preservation - Part 1: Principles produced by JTC 1/SC 34, JWG7 requests the SC34 Secretariat invite nominations of a candidate project editor to lead the preparation of a draft Preliminary Work Item (PWI) for this standard. Ideally, this person will have expertise in digital preservation and/or EPUB production. After th[CUT]
22:12:16 <dauwhe_> q
22:12:18 <dauwhe_> q?
22:12:50 <dauwhe_> wendyreid: MURATA, can you elaborate on what you posted?
22:12:52 <duga> present+
22:13:02 <dauwhe_> MURATA: interest in digital preservation from JWG7
22:13:14 <dauwhe_> ... this is relevant for archiving, which you mentioned
22:13:27 <dauwhe_> ivan_: is there already anything technical done, or is it only the intention?
22:13:47 <dauwhe_> MURATA: ???
22:13:51 <MURATA> MM: There is a technical specification.
22:13:52 <dauwhe_> wendyreid: any questions?
22:14:04 <dhall> q+
22:14:09 <wendyreid> ack dhall
22:14:09 <dauwhe_> s/???/There is a technical specification/
22:14:14 <ivan_> Topic: issues from the hackaton
22:14:28 <dauwhe_> dhall: how would we find out about a follow-up session
22:14:40 <dauwhe_> wendyreid: I have all the emails
22:14:44 <dauwhe_> ... we'll send out notes
22:14:45 <dauwhe> dauwhe has joined #epub
22:14:46 <Bill_Kasdorf__> q+
22:15:01 <dauwhe_> ... don't want to take too much advantage of the list
22:15:05 <GeorgeK> GeorgeK has joined #epub
22:15:08 <dauwhe_> ... you could join the CG or the WG
22:15:23 <GeorgeK> present+
22:15:52 <dauwhe_> q?
22:15:54 <dauwhe_> ack bi
22:15:55 <wendyreid> ack Bill_Kasdorf__
22:16:10 <dauwhe_> Bill_Kasdorf__: I'm thrilled to hear of people who want to be involved
22:16:30 <ivan_> Topic: issues from the hackaton
22:16:37 <gpellegrino> q+
22:16:43 <dauwhe_> wendyreid: let's talk about issues from the hackathon
22:16:58 <dauwhe_> ... I looked at the issues list, matt filed a bunch of issues
22:17:00 <dauwhe> dauwhe has joined #epub
22:17:05 <wendyreid> ack gpellegrino
22:17:24 <dauwhe_> gpellegrino: yesterday I tested the Kobo ereader
22:17:45 <dauwhe_> ... not all tests were simple to understand, I had to ask the test developer
22:17:57 <dauwhe_> ... in the reading solution, I see EPUB listed with title
22:18:10 <dauwhe_> ... in JSON I see the ID, so hard to match
22:18:32 <dauwhe_> ... I can see cmt-svg-css, but in interface I don't see ID/file name
22:18:40 <ivan_> q+
22:18:49 <dauwhe_> ... in JSON we have three values for each test, true|false|null
22:19:10 <dauwhe_> ... I use true if test passes, false if test files, null if I can't run the test or if it is not applicable
22:19:16 <dauwhe_> ... do we need another value?
22:19:31 <dauwhe_> ... for example, media overlays are not relevant because e-reader does not have a speaker
22:19:37 <dauwhe> dauwhe has joined #epub
22:19:39 <wendyreid> ack ivan_
22:20:10 <dauwhe_> ivan_: if descriptions are not understandable, submit a PR with changes, or file an issue
22:20:42 <dauwhe_> ... in some cases, we may have tests where the test might be slightly different for reasons of a11y
22:21:00 <dauwhe_> ... the null, we introduced that for not applicable
22:21:05 <dauwhe_> ... in some cases you found problems
22:21:11 <dauwhe_> ... it's ok to leave as null
22:21:13 <Hiroshi_Kawada> Hiroshi_Kawada has joined #epub
22:21:17 <dauwhe_> ... unless we can locate what the problem is
22:21:22 <dauwhe_> ... not applicable is fine
22:21:43 <dauwhe_> ... we need to translate this to a report to the (director)
22:22:07 <dauwhe_> ... for the ID, that's a tougher one
22:22:38 <dauwhe_> ... can there be two tests with same title? Maybe.
22:22:48 <dauwhe_> ... sometimes it's difficult
22:23:21 <dauwhe_> gpellegrino: add ID to the title so it's searchable?
22:23:35 <dauwhe_> wendyreid: why can't id be titles?
22:23:40 <dauwhe_> dlazin: readability
22:23:51 <dauwhe_> wendyreid: why do the titles have to be readable?
22:23:54 <dauwhe_> dlazin: reports
22:24:12 <dauwhe_> ivan_: with both, it gets complicated in the report
22:24:36 <dauwhe_> ... we can think about it
22:24:50 <dauwhe_> wendyreid: for test runners, it's a problem--it's extra work
22:25:02 <dauwhe_> ... what does this title mean for the test I'm doing? You have to look at the file
22:25:28 <dauwhe_> gpellegrino: for each line, search for the epub
22:25:38 <dauwhe_> ivan_: the report JSON is ordered by notification time
22:25:52 <dauwhe_> ... that's because one of th e testers at EDRLab is doing that
22:25:59 <dauwhe_> ... if a new test is added, or if there's a change
22:26:06 <dauwhe_> ... so they would have to find the new reports
22:26:16 <dauwhe_> ... so there's a modification date in the metadata which we keep valid
22:26:28 <dauwhe_> ... and the JSON is ordered according to the modification
22:26:38 <dauwhe_> ... ordering the JSON alphabetically is easier, maybe
22:26:58 <dauwhe_> gpellegrino: it took me 4 hours to do 75% of tests. all tests would take 5 hours.
22:27:01 <dauwhe> dauwhe has joined #epub
22:27:18 <dauwhe_> wendyreid: could we add test IDs to the titles?
22:27:28 <dauwhe_> q+
22:27:39 <dauwhe_> ... then we could strip from report?
22:27:51 <dauwhe_> ivan_: then I'd have to write a script to...
22:28:12 <dauwhe_> ... there's a test with a Hebrew title
22:28:15 <shiestyle> q+
22:28:29 <dauwhe_> ... that title is necessary
22:28:31 <wendyreid> ack dauwhe_
22:28:36 <gpellegrino> q+
22:29:07 <wendyreid> dauwhe_: One possible concern with the test id in the title, I wonder if important information would be truncated in the RS display.
22:29:30 <dauwhe_> gpellegrino: in the JSON report, for each report having id for title and result...
22:29:30 <wendyreid> ack shiestyle
22:29:53 <dauwhe_> shiestyle: adding ID to title for each test, just tried to use existing epubs in my reading system
22:30:01 <dauwhe_> ... it's a little bit complicated by English names
22:30:08 <dauwhe_> ... it's easier to recognize just a number
22:30:33 <dauwhe> dauwhe has joined #epub
22:30:48 <mauriceyork> mauriceyork has joined #epub
22:31:00 <dauwhe_> wendyreid: most of tests start with three-letter "area code" basically
22:31:10 <dauwhe_> ... what if we did a 3-letter ID then an number
22:31:13 <dhall> Suggestion: 'cnt-xhtml-support' in the content itself?
22:31:17 <dauwhe_> ... CSS-001, CSS-002
22:31:48 <dauwhe_> ivan_: those ids refer back to the spec, and are derived from the sectioning
22:31:59 <dauwhe_> wendyreid: don't need the number in the test ID, only in the title
22:32:05 <dauwhe_> dlazin: short id and long id
22:32:15 <dauwhe_> ... let's take this up in another context
22:32:54 <dauwhe_> ivan_: we could modify the report so it's keyed by the ID, but instead of 3-value, it would have result and title
22:33:19 <dauwhe_> ivan_: we would have to rewrite the test files
22:33:51 <wendyreid> ack gpellegrino
22:33:52 <dauwhe_> ivan_: let me think about the implications
22:33:55 <GeorgeK> q+
22:33:57 <dauwhe_> gpellegrino: other things i've seen
22:34:06 <dauwhe_> ... since I was testing B&W/greyscale device
22:34:13 <dauwhe_> ... all tests based on colors didn't work
22:34:20 <dauwhe_> ... for example CSS applied to SVG
22:34:25 <dauwhe_> ... and SVG viewport
22:34:34 <dauwhe_> ... "if you see green test passes"
22:34:53 <dauwhe_> ... because green cannot be distinguished from red in a greyscale device
22:35:04 <dauwhe_> ... could we use border styles or something?
22:35:25 <dauwhe> dauwhe has joined #epub
22:35:37 <dauwhe_> ivan_: the kobo player, is it BW or greyscale?
22:35:47 <dauwhe_> wendyreid: greyscale
22:35:55 <dauwhe_> ivan_: so doing the test as greyscale should help
22:36:16 <dauwhe_> duga: (pretty good joke that I can't transcribe)
22:36:36 <dauwhe_> gpellegrino: last thing, the L->R and R->L change
22:36:51 <dauwhe_> ... it doesn't change the page in one direction or another
22:37:01 <dauwhe_> ... hard to tell if it's changing to R or L
22:37:12 <dauwhe_> ... it is defined by device
22:37:21 <dauwhe_> ... I tap on R and it goes to the next page
22:37:28 <dauwhe_> wendyreid: it's responding to the directionality
22:37:49 <dauwhe_> ... if you tap on the ?? then ??, but if you tap on the ?? then ??
22:38:16 <dauwhe_> wendyreid: any other comments about tesets?
22:38:22 <dauwhe_> s/tesets/tests/
22:38:29 <dauwhe_> q?
22:38:30 <dauwhe_> ack Ge
22:38:33 <wendyreid> ack GeorgeK
22:38:39 <AramZS> AramZS has joined #epub
22:38:42 <dauwhe_> GeorgeK: I cloned repo and went to the tests and saw instructions
22:38:51 <dauwhe_> ... is there a reason it isn't built for everyone?
22:38:57 <dauwhe_> ivan_:  they are built
22:39:06 <dauwhe_> wendyreid: all of the epubs are in the "tests" folder
22:39:22 <dauwhe_> ... not in the folders for the un-packaged tests
22:39:47 <dauwhe_> GeorgeK: did we say we were goint to put something in the instructions on how people using screenreaders can report?
22:40:15 <dauwhe_> ivan_: gpellegrino will go through the reports to help define what screenreader users should hear
22:40:23 <dauwhe> dauwhe has joined #epub
22:40:56 <dauwhe_> GeorgeK: I can help with thorium with nvda
22:41:06 <dauwhe_> ... this will be useful for our testing report
22:41:18 <dhall> q+
22:41:31 <dauwhe_> wendyreid: we'll have to do this separately from the main report
22:41:46 <dauwhe_> ivan_: I don't think so... we can have a screenreader as a reading system
22:42:08 <wendyreid> ack dhall
22:42:12 <ivan_> q+
22:42:31 <dauwhe_> dhall: if we run through submitting prs as we make progress is that appropriate?
22:42:32 <dauwhe_> ivan_: yes
22:42:57 <dauwhe_> dhall: if we come up with a test, if a test calls for a certain styling, the user might be able to override that with a theme
22:43:04 <dauwhe_> ... should that be discussed in wg meetings?
22:43:06 <dauwhe_> ivan_: yess
22:43:14 <gpellegrino> q+
22:43:26 <dlazin> dlazin has joined #epub
22:43:28 <dlazin> present+
22:43:29 <dlazin> q+
22:43:31 <dauwhe_> ... even if I change background in ibooks, background colors in an SVG should not change
22:43:43 <dauwhe_> dhall: not aware of a test with this issue, but it might happen
22:43:50 <dauwhe> dauwhe has joined #epub
22:44:03 <dauwhe_> wendyreid: it's not just themes, it's all the reading system settings
22:44:29 <dauwhe_> ... if I think a setting might affect the rendering, I add an instruction in the test--reset to publihser reset
22:44:44 <dauwhe_> dlazin: we are not testing the RS, just the implementabilty of the specification
22:45:20 <dauwhe_> dlazin: I did lots of Apple books test yesterday. Desktop fails the tests about vertical scroll direction--it's always paginated.
22:45:28 <dauwhe_> ... mobile version can do it
22:45:35 <gpellegrino> q-
22:45:37 <dauwhe_> ... so the test passes because you understand the feature
22:45:39 <wendyreid> ack ivan_
22:45:52 <dauwhe_> ivan_: that means we have three pull tests from yesterday
22:46:02 <dauwhe_> ... what are the overall results
22:46:12 <dauwhe_> ... from the CR perspective are we in a good place
22:46:22 <dauwhe_> dlazin: we don't have that much data yet
22:46:29 <dauwhe_> ... I got through most of apple macos
22:46:31 <gpellegrino> q+
22:46:42 <dauwhe_> ... brady is thru 3 platforms of google
22:46:52 <dauwhe_> ... and some progress on thorium and kobo
22:47:01 <dauwhe_> ... we don't have enough to see horizontally
22:47:06 <dauwhe_> ... all the obvious stuff is safe
22:47:12 <dauwhe_> ... non-obvious stuff is failing a lot
22:47:15 <dauwhe_> ... for example
22:47:24 <dauwhe_> .... apple books is quite... well-polished
22:47:36 <dauwhe_> .. 69 true, 39 false, 45 I haven't gotten to
22:47:50 <dauwhe_> ... lots of fails on recent things, like URL parsing which is new to the spec
22:47:59 <wendyreid> ack dlazin
22:47:59 <dauwhe_> ivan_: what we have done is useful
22:48:02 <wendyreid> ack gpellegrino
22:48:04 <dauwhe> dauwhe has joined #epub
22:48:08 <dauwhe_> gpellegrino: question to Apple
22:48:20 <dauwhe_> ... since we know that some platforms do tricks on epubs will ingesting
22:48:27 <dauwhe_> ... for example google,
22:48:40 <dauwhe_> ... is it the same to test file via sideloading?
22:48:44 <dlazin> q+
22:48:57 <dauwhe_> ... the best thing would to be test via the ingestion pipeline if it changes something
22:49:23 <dauwhe_> dlazin: from publisher point of view, that's important, but that's not the goal of the working group.
22:49:37 <dauwhe_> ... the WG cares about the implementability of the feature
22:49:38 <wendyreid> ack dlazin
22:49:59 <dauwhe_> ... some onix tests don't pass in apple sideloading, but no one would use onix on a sideloaded epub
22:50:40 <dauwhe_> wendyreid: any other testers have comments?
22:50:54 <dauwhe_> ... thanks to yesterday's testers... we fixed a bunch of tests
22:51:17 <dauwhe_> ... and I updated some language
22:51:49 <dauwhe_> ... if you run a test, and if you're not sure of the expected results, open issues in the test repo
22:52:03 <dauwhe_> dlazin: there is also an epub-testing in w3c slack
22:52:12 <dauwhe_> s/epub-testing/epub-testing channel/
22:52:23 <dauwhe_> ivan_: anyone can ask to be added to the Slack
22:52:44 <mauriceyork> mauriceyork has joined #epub
22:52:45 <dauwhe_> wendyreid: this link should help you get on the Slack
22:53:14 <mauriceyork> Sorry Wendy, could you send that one more time? My server disconnected
22:53:24 <dlazin> And then just message, say, me, and I/we can add you to #epub-testing in Slack (or if you understand Slack you can probably just add the channel yourself)
22:53:24 <dauwhe_> wendyreid: any other comments about testing
22:53:29 <dauwhe_> https://www.w3.org/slack-w3ccommunity-invite
22:53:37 <mauriceyork> awesome, thanks
22:53:44 <dauwhe_> dlazin: we have 90% coverage
22:53:57 <dauwhe_> ... but it will be harder to add new tests to existing implemenation reports
22:54:06 <dauwhe_> wendyreid: we can help keep track of that
22:54:11 <dauwhe_> ivan_: what about missing tests?
22:54:16 <GeorgeK> bye
22:54:34 <dauwhe_> ivan_: need 2 tests for MO
22:54:40 <dauwhe_> ... marisa knows that stuff
22:54:53 <dauwhe_> ... zheng will do the package one
22:55:02 <dauwhe_> wendyreid: we're in good shape
22:55:30 <dauwhe_> ivan_: how do we get someone at Amazon to run tests
22:55:43 <Bill_Kasdorf__> q+
22:55:49 <dauwhe_> wendyreid: ask ?? who is on a11y team at Amazon
22:55:56 <Bill_Kasdorf__> q-
22:55:58 <wendyreid> s/??/Terra/
22:56:07 <dauwhe_> gpellegrino: she's put some DAISY tests in the pipeline
22:56:31 <dauwhe_> ivan_: if we have tests run by Apple/Google/Thorium etc we are already covering a good bit of market.
22:56:44 <dauwhe_> wendyreid: let's take a break now
22:57:03 <dauwhe_> ... reconvene at 16:10 PDT
23:01:02 <dauwhe> dauwhe has joined #epub
23:07:46 <gpellegrino> gpellegrino has joined #epub
23:08:58 <duga> duga has joined #epub
23:11:00 <ivan_> Topic: Testing with CJK implementers
23:12:09 <ivan_> scribe+ dhall
23:12:39 <dhall> wendyreid: More discussion around testing.  We want to make the tests as usable by as many people as possible.
23:12:41 <Furoshiki> Furoshiki has joined #epub
23:12:50 <dhall> ... all tests written in English currently
23:13:20 <dhall> ... Should we do translation, in particular CJK
23:14:37 <dhall> For Japanese, it is a bit hard to do the tests, we want to encourage the testing activities.  Translation is a good idea - esp for reading systems built in Japan.
23:14:52 <wendyreid> s/For/shiestyle: For/
23:15:06 <dhall> ... an explanation for each test would be helpful.  Each place has a discussion of criteria for passing.
23:15:49 <dhall> ... Would be ok to have translation of a description of the test result captured outside the epub itself.
23:17:13 <dhall> There are some tests that have a fairly long description.  Many tests are only two or three sentences, but there are others that the description of what the tester should look at is a description.
23:17:14 <mauriceyork> mauriceyork has joined #epub
23:17:40 <ivan_> s/There/ivan: There/
23:17:54 <dhall> wendyreid: We could have the 'test passes' statement - need to know how it looks
23:18:24 <dhall> duga: I'm duga.  :-)
23:18:49 <dhall> wendyreid: If we just need to do a spreadsheet where we have the test ID, statement, then we should be good.
23:19:24 <dhall> ... generating the spreadsheets should be easy, what we need support with is finding translators to translate the statements.
23:19:47 <dhall> ivan_: Just to be clear, the first job is to generate the spreadsheet
23:20:31 <dhall> duga: If it is a reasonable number will look into getting translations done.
23:21:03 <dhall> wendyreid: make a note for the images for the css tests
23:21:31 <dhall> wendyreid: Next Topic: an additional item for today:
23:21:33 <ivan_> Topic: Webtoons
23:21:37 <dlazin_> dlazin_ has joined #epub
23:21:37 <wendyreid> https://github.com/w3c/epub-specs/issues/2412
23:21:38 <dhall> ... Webtoons
23:21:49 <Victor_Lopes> Victor_Lopes has joined #epub
23:22:11 <ivan_> github-bot, bye
23:22:11 <github-bot> github-bot has left #epub
23:22:15 <dhall> shiestyle: From last year or so, in Japan, webtoons gaining popularity
23:22:26 <dhall> ... publishers creating webtoons for their content
23:22:57 <dhall> ... current specifications lacking identifiers for their content.  Apple has guidelines for producing EPUBs, and extended guidelines.
23:23:24 <dhall> ... includes a property to identify a webtoon.  Reading systems must ignore the flow property if fixed layout.  Webtoons consist of fixed layout.
23:23:43 <dhall> ... amazon will follow the stated behavior for producing guidelines.
23:24:21 <dhall> ... webtoon services have not used EPUBS.  In Japan we have various formats, and want to use EPUB 3 format also.
23:24:40 <dhall> ... Want to discuss a reasonable solution for Webtoos for identification.
23:24:56 <dhall> ... One option is to use a custom property identification in OPF file. Meta-name property.
23:25:10 <dhall> ... legacy format for epub3, so not good style.
23:25:36 <dhall> ... another option current mistaken behavior by apple / amazon - could change epub3 spec to turn behavior optional.
23:25:55 <dhall> ... fixed-layout could be identified.  want to discuss for reasonable solution.
23:26:01 <dhall> wendyreid: two options:
23:26:06 <johnr> johnr has joined #epub
23:26:14 <dhall> ... add a new metadata property for webtoons specifically
23:26:22 <duga> q+
23:26:33 <dhall> ... or we remove the fixed-layout caveat on rendition-flow from the specification, and let that exist for any type of content.
23:26:47 <wendyreid> ack duga
23:26:53 <ivan_> q+
23:27:55 <wendyreid> ack ivan_
23:27:56 <dhall> duga: we could wait for after 3.3, because of where we at in the specification, but that leaves the meaning unknown.
23:28:49 <dhall> ivan_: First, put on w3c hat - small change, does not affect existing tests, September we still have the time to make the change, provided we have additional tests and client support.  (This is from an administrative point of view)
23:29:06 <wendyreid> q+
23:29:22 <dhall> ... however, concern over rushing into something.  This is a question that would come up later towards the end of the working group.  How do we imagine and plan for changes after the WG is finalized.
23:29:54 <dhall> ... the current approach is that after this working group we create a maintenance WG.  Has the right to add new features (need testing, etc), but does not mean we have to go through 2yrs work to add the feature.
23:30:30 <dhall> .. other working groups have followed this possibility.  It's up to us to say how self disciplined we are.  we can envisage doing it this way.  we would have more experience and more thorough.
23:30:36 <wendyreid> ack wendyreid
23:30:38 <dhall> .. have to be careful not to rush into stuff.
23:31:08 <dhall> wendyreid: Also understand Brady's concern.  It feels wrong, wish we had known about this earlier as a use case.
23:31:41 <dhall> ... the way we have looked at rendition-flow is specified is under specified.  we do know there are reading systems out there that have a reading mode of vertical scroll.
23:32:06 <dhall> ... The spec is fairly vague and may be in our favor in this instance.  the reading system should present the content from one continuous flow from spine item to spine item.
23:32:20 <dhall> duga: I don't know what this actually means
23:32:38 <duga> q+
23:32:57 <dhall> wendyreid: I think that making this change - we're also removing an inconsitancy - don't see why we don't need to have that.
23:33:30 <dhall> ... feels removing the don't do this is an ok change to make.  Because we are still in the CR period, we will remove anything that is not implemented.
23:33:59 <wendyreid> ack duga
23:34:06 <dhall> ... it also addresses a need in the community that if we don't address it, community may do it a different way, and then we don't have a way
23:34:31 <shiestyle> q+
23:35:00 <dhall> duga: would rather have a non-standard spec in an epub for now.  If we don't define a rendering model, define how it actually behaves, then it's not really a standard.  Next year we sit down, and open up a client and we then try and copy the behavior.
23:35:11 <wendyreid> q+
23:35:55 <dhall> ... This was a mistake early on as following client reader implementation.  What does it mean?  Do I display it as they are?  what if we have variable size pages? fit to width? etc.
23:36:21 <dauwhe_> q?
23:36:30 <dauwhe_> q+
23:36:45 <dhall> ... need a rendering model to be proposed, and we want to understand - what does this mean when applied to fixed layout, what are all the use cases.  We would end up with a Wild West.
23:36:50 <wendyreid> ack shiestyle
23:37:47 <dhall> shiestyle: The first I proposed is to add a custom meta-data.  We should do one common metadata.  Discuss with various companies to use the metadata commonly.  it's not option.  Another proposal is to add to the specification.
23:38:00 <dhall> ... Is description ok?  This is an other option.
23:38:01 <wendyreid> ack wendyreid
23:38:04 <wendyreid> https://www.w3.org/TR/epub-33/#flow
23:38:15 <dhall> wendyreid: https://www.w3.org/TR/epub-33/#flow
23:39:04 <dhall> ... we do have different rendition flow examples.  maybe we should bring over to RS.  We should provide some guidance as to what this looks like for fixed layout.
23:39:37 <dhall> ... This isn't a perfect description of how this renders.  We have made decisions before to not be super descriptive.  we can put a bit of effort into how this would render and look.
23:39:58 <dhall> ... don't think this is a huge change to make.  If we add a custom metadata field, this won't make it into the specification either.
23:40:00 <gpellegrino> q+
23:40:08 <wendyreid> ack dauwhe_
23:40:51 <CharlesL> CharlesL has joined #epub
23:41:08 <wendyreid> ack gpellegrino
23:41:09 <dhall> dauwhe_: Want to offer some cautionary advice: Share's Brady's concern around rendering.  We have faced challenges around fixed layout properties and what they mean.  Don't want future groups to have the same issue.  We want interoperability - be clear of our expectations around reading systems.
23:42:00 <dhall> gpellegrino: Try to understand - what if we say in the Japan market they can use the metadata to express as a web-toon.  why in the standard do we not define at the moment.  this is a way that is currently used in Japan.
23:42:22 <duga> q+
23:42:34 <shiestyle> q+
23:42:59 <duga> q-
23:43:10 <dhall> ivan_: This Combes back to what I said - this is between reading systems and publishers, that for me is what incubation is all about.  people may enumerate a few times to settle down, and in a year in combination with the WG, we can say there is an agreed upon behavior.
23:43:38 <dhall> ... we could add into the standard, and then from that point on, can expect reading systems to follow.  need to let the incubation phase run it's course
23:44:09 <dhall> ... we have a bunch of things in the ePUB standard which were put into the specification at some point with the hope it will be implemented by everyone, and may pay the price at the end because we don't have implementations.
23:44:19 <dhall> ... would be worried about the same kind of effect that would have.
23:44:20 <wendyreid> ack shiestyle
23:44:25 <wendyreid> q+
23:44:55 <dhall> shiestyle: Apparently the first market that would generate to generate epub format webtoons, we need some kind of solution.
23:45:02 <wendyreid> ack wendyreid
23:45:10 <dhall> wendyreid: Hit a bit of an impasse. A third proposal:
23:45:59 <dhall> ... document the incubation period - don't change the spec as it is currently written.  however, can we add an editorial note to the rendition flow section regarding the use-case.  we think it can be used for this purpose.  If you want to fit this use case we recommend you do it this way.
23:46:11 <mauriceyork> mauriceyork has joined #epub
23:46:30 <dhall> ... want to see how this gets implemented - provides a location for feedback, and can look at reasons for.
23:46:46 <dhall> ... Want to document because it seems to fit, but also agree we don't want to rush it.
23:46:57 <dhall> ... want to encourage people in a direction, and give guidance.
23:47:23 <dhall> ivan_: Incubation matters in the field with implementations.
23:47:31 <dhall> ... believe proposal is doable.
23:48:01 <dhall> duga: feel we need more in the field implementations - is this an at-risk feature?
23:48:13 <dhall> ivan_: This is a good point and a risk point.
23:48:26 <dhall> duga: It might move, right?
23:48:35 <dhall> wendyreid: Going to formalize in IRC
23:50:14 <dhall> Wendy: proposal statement
23:50:19 <wendyreid> Proposed: Add a note to the specification identifying rendition:flow scrolled continuous as a possible option for webtoons in EPUB, it is being incubated and requesting feedback
23:50:20 <dhall> wendyreid: proposal statement
23:50:34 <dhall> wendyreid: "Proposed: Add a note to the specification identifying rendition:flow scrolled continuous as a possible option for webtoons in EPUB, it is being incubated and requesting feedback"
23:50:56 <ivan_> +1
23:50:58 <shiestyle> +1
23:50:59 <duga> +1
23:50:59 <dhall> duga: Fine, not sure if there is another way.
23:51:00 <toshiakikoike> +1
23:51:02 <MURATA> +1
23:51:03 <gpellegrino> +1
23:51:04 <SymonFlaming> +1
23:51:04 <dhall> +1
23:51:04 <MasakazuKitahara> +1
23:51:05 <johnr> +1
23:51:05 <wendyreid> +1
23:51:14 <wendyreid> RESOLVED: Add a note to the specification identifying rendition:flow scrolled continuous as a possible option for webtoons in EPUB, it is being incubated and requesting feedback
23:51:28 <dhall> wendyreid: proposed vote.  "RESOLVED: Add a note to the specification identifying rendition:flow scrolled continuous as a possible option for webtoons in EPUB, it is being incubated and requesting feedback"
23:51:54 <dhall> q+
23:51:59 <wendyreid> ack dhall
23:52:22 <wendyreid> dhall: Being new to the group and working on the reading experience, we'd have a vested interest in implementing the right thing
23:52:43 <wendyreid> ... what does that look like? Joining discussions? Providing feedback
23:53:25 <wendyreid> ivan_: Goal is to find consensus amongst the participants
23:53:26 <duga> q+
23:53:45 <wendyreid> ... the proposal can be rejected still, but otherwise it must be acted on
23:54:09 <wendyreid> ... longer term, a standard becomes a standard when it has more than 2 implementations
23:54:31 <wendyreid> ... there will be ongoing discussions about the spec even after publication
23:54:35 <wendyreid> q+
23:54:41 <wendyreid> ack duga
23:55:00 <wendyreid> duga: That's a good question because we haven't done this for EPUB within the W3C
23:55:29 <wendyreid> ... you'll go and incubate, you might discover you need more information, you would report back on your findings
23:55:44 <wendyreid> ... do you need to bring it to the CG or WG?
23:55:46 <wendyreid> ivan_: WG
23:55:58 <wendyreid> duga: There's more of a discussion
23:56:16 <wendyreid> ivan_: We've added the directional features for title for instance
23:56:33 <wendyreid> q-
23:59:42 <ivan_> scribe+ duga