14:02:37 <RRSAgent> RRSAgent has joined #epub
14:02:37 <RRSAgent> logging to https://www.w3.org/2021/12/03-epub-irc
14:02:40 <Zakim> RRSAgent, make logs Public
14:02:40 <Zakim> please title this meeting ("meeting: ..."), ivan
14:02:58 <ivan> ivan has changed the topic to: Meeting Agenda 2021-12-03: https://lists.w3.org/Archives/Public/public-epub-wg/2021Dec/0000.html
14:02:59 <ivan> Chair: wendy
14:02:59 <ivan> Date: 2021-12-03
14:02:59 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-epub-wg/2021Dec/0000.html
14:02:59 <ivan> Meeting: EPUB 3 Working Group Telco
14:02:59 <ivan> Regrets+ tzviya, rickj, romain
14:37:24 <wendyreid> wendyreid has joined #epub
14:59:16 <MasakazuKitahara> MasakazuKitahara has joined #epub
14:59:23 <MasakazuKitahara> present+
14:59:34 <ivan> present+
14:59:35 <avneeshsingh> avneeshsingh has joined #epub
14:59:45 <dauwhe> present+
14:59:51 <ivan> present+ avneesh
14:59:53 <avneeshsingh> present+
14:59:56 <ivan> present+ george
14:59:57 <BenSchroeter> BenSchroeter has joined #epub
15:00:06 <ivan> present+ BenSchroeter
15:00:15 <BenSchroeter> present+
15:00:17 <George> George has joined #epub
15:00:25 <toshiakikoike> toshiakikoike has joined #epub
15:00:31 <wendyreid> present+
15:00:32 <toshiakikoike> present+
15:00:37 <George> present+
15:00:55 <MattChan> MattChan has joined #epub
15:01:12 <mgarrish> mgarrish has joined #epub
15:01:17 <MattChan> present+
15:01:41 <ivan> present+ ubbink
15:01:56 <Jen_G> Jen_G has joined #epub
15:02:03 <Jen_G> Present+
15:02:25 <MattChan> scribe+
15:03:20 <ivan> present+ MattChan
15:03:53 <ivan> present+ mgarrish
15:04:00 <duga> duga has joined #epub
15:04:07 <duga> present+
15:04:11 <ivan> present+ charles
15:04:45 <MattChan> dauwhe: first few issues are about remote resources
15:04:59 <dauwhe> https://github.com/w3c/epub-specs/pull/1949
15:05:03 <MattChan> ... all of our previous conclusions are complicated by custom elements in HTML
15:05:16 <MattChan> TOPIC: Alternative remote resource rule for custom elements
15:05:36 <MattChan> dauwhe: mgarrish tries to phrase our existing requirements in a way that fits with custom elements
15:05:45 <Bill_Kasdorf> Bill_Kasdorf has joined #epub
15:05:51 <dlazin> dlazin has joined #epub
15:05:54 <ivan> present+ Bill_Kasdorf
15:05:57 <MattChan> ... but this makes things impossible for epubcheck, which won't know what is actually there until scripts have run
15:05:59 <dlazin> present+
15:07:19 <MattChan> mgarrish: right, there are 2 PRs, this one tries to find language that still works with our past intent, the other PR more specifically address the existence of custom elements
15:07:24 <dauwhe> q+
15:07:34 <ivan> https://github.com/w3c/epub-specs/pull/1943
15:07:49 <ivan> https://github.com/w3c/epub-specs/issues/1913
15:07:52 <CharlesL> CharlesL has joined #epub
15:07:54 <MattChan> ... there is really little we can do to check for this, people will try to work around it. It will ultimately be down to RS to decide whether to even support custom elements
15:08:34 <MattChan> dauwhe: i made a test book for this, it worked in ADE, Kindle previewer failed because it doesn't support js, didn't work in Thorium
15:08:36 <ivan> q+
15:08:40 <ivan> ack dauwhe
15:08:42 <dauwhe> ack iv
15:09:03 <mgarrish> q+
15:09:17 <MattChan> ivan: what you tested tells me that custom elements are here, it would be foolish of us to try to restrict them. They are part of the element that we have to deal with
15:09:50 <dauwhe> ack mg
15:10:12 <MattChan> ... I'm in favor of the first PR, which removes restrictions. The second PR which tries to keep restrictions is harder to check anyway
15:10:14 <ivan> q+
15:10:37 <ivan> q-
15:10:50 <duga> q+
15:10:52 <ivan> +1 to matt
15:11:08 <MattChan> mgarrish: the simpler solution might be just to say that RS should not render remote resources in iframes
15:11:23 <ivan> q+
15:11:28 <MattChan> dauwhe: worried that people would then work around that by using a custom element to effectively make an iframe
15:11:36 <CharlesL> present+
15:11:49 <dauwhe> ack duga
15:12:05 <MattChan> mgarrish: there's more awareness of how to handle that at the RS level than at checking, because you have the DOM
15:12:45 <MattChan> duga: when it comes to scripting, it kind of the wild west. It'll be impossible to test whether scripts are being used to do something malicious
15:13:39 <MattChan> ... there's utility to having everything be in the package (interop, archival), and if people don't care about that then there's little we can do
15:13:55 <MattChan> ... our main concern in making these exceptions for resources are for size
15:14:14 <dauwhe> ack iv
15:14:15 <MattChan> ... should the restriction be based on size then
15:15:06 <MattChan> ivan: to be clear, custom elements means scripting. As soon as RS allows scripting, any restriction on custom elements is meaningless. The real restriction is on scripting
15:15:22 <MattChan> ... the first PR simplifies that
15:15:59 <MattChan> dauwhe: there are 2 types of custom elements. First inherents from existing HTML element (i.e. "is" attribute). This type doesn't work in webkit, and will probably be limited in epub world.
15:16:14 <MattChan> ... this is a can of worms that we can't really do much about
15:17:02 <wendyreid> Proposed: Merge PR 1943 and not 1949
15:17:11 <dauwhe> +1
15:17:11 <ivan> +1
15:17:11 <BenSchroeter> +1
15:17:12 <duga> +1
15:17:12 <wendyreid> +1
15:17:13 <MattChan> +1
15:17:14 <toshiakikoike> +1
15:17:16 <mgarrish> +1
15:17:16 <MasakazuKitahara> +1
15:17:20 <CharlesL> \
15:17:21 <CharlesL> ]
15:17:24 <George> +1
15:17:26 <dlazin> +1
15:17:26 <CharlesL> +1
15:17:38 <wendyreid> RESOLVED: Merge PR 1943 and not 1949
15:18:25 <dauwhe> https://github.com/w3c/epub-specs/issues/1913
15:18:37 <Bill_Kasdorf> +1
15:18:55 <wendyreid> Proposed: Close issue 1913 once PR 1943 is merged.
15:19:01 <BenSchroeter> +1
15:19:05 <duga> +1
15:19:06 <wendyreid> +1
15:19:09 <MattChan> +1
15:19:09 <MasakazuKitahara> +1
15:19:10 <ivan> +1
15:19:10 <Bill_Kasdorf> +1
15:19:12 <dauwhe> +1
15:19:14 <dlazin> +1
15:19:18 <mgarrish> +1
15:19:23 <CharlesL> +1
15:19:28 <wendyreid> RESOLVED: Close issue 1913 once PR 1943 is merged.
15:20:27 <MattChan> dauwhe: i would warn everyone to be wary of custom elements, because it's easy to miss things related to a11y. HTML elements take care of a lot of that thinking for you
15:20:44 <MattChan> ivan: that's not really our fight, leave for WHAT WG
15:21:54 <MattChan> dlazin: we use custom elements quite a bit in my day job, and there are more a11y friendly ways of doing it, but yes, beware
15:22:04 <dauwhe> https://github.com/w3c/epub-specs/issues/1944
15:22:14 <dauwhe> https://github.com/w3c/epub-specs/issues/1942
15:22:32 <MattChan> TOPIC: What happens to issues that don't have enough implementations?
15:23:05 <MattChan> dauwhe: the point of the W3C process is to show that features are implementable by writing tests and showing that that test can be passed by more than 1 independent implementation
15:23:13 <ivan> q+
15:23:14 <MattChan> ... so, where we don't find implementations, what then?
15:23:19 <dauwhe> ack iv
15:23:26 <MattChan> ... and how do we balance against our need for backwards compat
15:23:48 <MattChan> ivan: the usual approach is to say that in a normative statement doesn't have enough implementations it is removed from spec
15:23:54 <MattChan> ... we cannot do this because of backwards compat
15:24:12 <MattChan> ... we have to resolve this before we go to CR
15:25:00 <MattChan> ... there are 2 categories already used for features that are not entirely okay. 1) "Legacy" (e.g. NCX) which are there in the spec because people may still want to use EPUB2. These are not defined in our spec.
15:25:17 <MattChan> ... currently we say RS must not implement them, and users may use them
15:25:25 <MattChan> ... so no error or warning if found in an epub
15:25:50 <dauwhe> q?
15:26:09 <MattChan> 2) "Deprecated" features are ones that were in earlier versions of epub3, but were not implemented. Authors are discouraged from using them ("should not" use), and RS may implement them
15:26:44 <MattChan> ivan: i think none of the two are a good fit for answering this issue
15:26:53 <mgarrish> q+
15:27:01 <MattChan> ... the feeling is that legacy features may disappear from future versions of epub
15:28:00 <MattChan> ... deprecated is saying that we are discouraging users from using them, and this may be a strong statement because we may still hope that some of the features that lack implementation today may find implementations in the near future
15:28:28 <MattChan> ... I think we should introduce a 3rd option, yet to be defined, maybe "Optional". Something that authors may use, and RS should implement.
15:28:49 <MattChan> ... i.e. they are not normative, but maybe in a later version of spec they may become normative
15:28:53 <dauwhe> q+
15:28:59 <dauwhe> ack mg
15:29:02 <MattChan> ... (and we'd remove the optional classification at that point)
15:29:26 <MattChan> mgarrish: generally agree, but wanted to clarify that we're not going to start labelling new things as legacy
15:29:38 <MattChan> ... only epub 2 things can be legacy
15:29:52 <MattChan> ... and agree that we're not going to start deprecating things that we still want to keep alive
15:29:57 <dauwhe> ack da
15:30:14 <MattChan> dauwhe: its hard to talk about this in the abstract
15:30:37 <duga> q+
15:30:42 <MattChan> ... so using fallback as an example, my understanding is that the feature as described is not implemented anywhere, yet it affects rendering of epubs today
15:31:44 <MattChan> ... i don't like the idea of Optional because it gives the wrong impression; if a feature isn't implemented, then it doesn't work, and you shouldn't use it
15:32:23 <mgarrish> q+
15:32:28 <dauwhe> ack du
15:32:37 <MattChan> ... not sure what we should do, but I don't want to leave things in the spec without discouraging people from using them
15:32:56 <MattChan> duga: Google Play supports fallbacks btw
15:33:02 <MattChan> ... but maybe "At Risk"?
15:33:21 <MattChan> ivan: At Risk has a specific meaning within W3C process
15:33:24 <mgarrish> q-
15:33:43 <dlazin> q+
15:33:48 <MattChan> duga: okay, then something at suggests the risk of using those features that have not received implementations then
15:34:07 <dauwhe> ack dl
15:34:23 <MattChan> dlazin: I think Optional and May have the same normative meaning, but May implies "you can do this" while Optional implies "you can do this, but not sure why you would"
15:34:27 <MattChan> ... so can we just use May instead?
15:35:36 <dauwhe> q+
15:36:22 <dauwhe> ack d
15:36:36 <MattChan> ivan: the exact word we use to label these sorts of features is kind of an editorial question, we need to decide whether we need a category for these
15:36:51 <MattChan> dauwhe: and what would epub check do with these?
15:37:00 <MattChan> s/epub check/epubcheck
15:37:04 <Bill_Kasdorf> How about simply "strongly discouraged"?
15:37:43 <MattChan> ... i think we should continue to align with epubcheck on these issues. So if we introduce a new category, there should be a corresponding category of flag in epubcheck
15:38:16 <MattChan> ... based on the tests we've done so far, what else might end up in this category?
15:38:46 <MattChan> wendyreid: the reading system object
15:38:59 <MattChan> dauwhe: i think ibooks does something with that?
15:39:21 <MattChan> duga: i thought it was implemented among RS that support scripting
15:40:08 <MattChan> wendyreid: some of the FXL properties, like mixed layouts (i.e. where a single book has fixed and reflow content)
15:40:39 <MattChan> ivan: we have to specify what happens to these features in advance of CR
15:41:13 <MattChan> dauwhe: we will be influenced in our decision based on what sorts of features will fall into this bucket, as determined by testing results
15:41:28 <MattChan> ivan: that's kind of chicken and egg
15:41:54 <MattChan> ... and are we sure that all package metadata are used by enough publishers?
15:42:44 <MattChan> ... today there are some properties that are deprecated, might be the case with some of the properties we still have
15:43:13 <ivan> q+
15:43:16 <MattChan> dauwhe: given that this is about CR exit criteria, this depends on the judgement of the Director
15:43:54 <MattChan> ... do we have any sense of what the feeling is, especially given all the history of epub
15:44:26 <MattChan> ivan: I have a weekly meeting with that level of the W3C, so the channel of communication is open
15:44:48 <dauwhe> ack iv
15:45:18 <mgarrish> q+
15:45:28 <MattChan> ... to be specific, I think we should add a 3rd category in appendix A (beside legacy and deprecated), and make it clear that this category is meant for features that we don't want to deprecate, but authors must use with care due to their risky status
15:45:37 <dauwhe> ack mg
15:45:39 <MattChan> ... I can present this to the Director
15:45:55 <George> q+
15:46:15 <MattChan> mgarrish: is there a timeline for this? When is the classification determined?
15:46:27 <MattChan> ivan: when we leave CR
15:46:37 <dauwhe> q++
15:46:44 <MattChan> ... so the classification will be valid for the next recommendation
15:46:45 <dauwhe> q+
15:46:51 <dauwhe> ack +
15:47:21 <MattChan> mgarrish: so should we say that these features have been given a pass for this version, but that they might be deprecated in the next version if we don't find additional support?
15:47:36 <dauwhe> ack Geo
15:47:40 <MattChan> ivan: we've gotten into trouble with this sort of thing in the past. Don't want to say what will happen in future.
15:47:49 <CharlesL> q+
15:47:56 <MattChan> George: are these experimental features we'd like to see implemented? Or is this something that we want to get rid of?
15:48:32 <dauwhe> ack dau
15:48:35 <MattChan> dauwhe: unclear, the testing would answer those questions. There won't necessarily be any sort of pattern. Obviously we thought all the features were good ideas at the time we wrote them
15:48:36 <dauwhe> ack ch
15:49:22 <MattChan> CharlesL: what is the difference between "risky" and "at risk" if we're applying these labels at the point we go into Rec?
15:50:10 <MattChan> dauwhe: at risk is a term of art in W3C, could cause backwards compat issues
15:50:36 <MattChan> ivan: if we label something at risk, then we're required to remove that feature from spec before Rec, and we cannot do this because of the backwards compat mandate
15:50:51 <MattChan> ... if something is simply risky, then its up to us whether to remove it
15:51:42 <MattChan> dauwhe: seems to be consensus that we need 3rd category, though the language is to be determined, it would be tied to epubcheck with a flag that is something less severe than a warning
15:54:14 <wendyreid> Proposal: Label "risky" features in the spec with a name TBD, would correspond to a flag in EPUBCheck, close issue 1944
15:54:25 <wendyreid> +1
15:55:00 <wendyreid> Proposal: Label "risky" features in the spec with a name TBD, would correspond to a flag in EPUBCheck
15:55:06 <dauwhe> +1
15:55:10 <BenSchroeter> +1
15:55:11 <wendyreid> +1
15:55:12 <toshiakikoike> +1
15:55:16 <CharlesL> +1
15:55:20 <MasakazuKitahara> +1
15:55:21 <avneeshsingh> +1
15:55:23 <mgarrish> +1
15:55:25 <MattChan> +1
15:55:27 <duga> +1
15:55:32 <Bill_Kasdorf> +1
15:55:41 <wendyreid> RESOLVED: Label "risky" features in the spec with a name TBD, would correspond to a flag in EPUBCheck
15:55:57 <dauwhe> https://github.com/w3c/epub-specs/issues/1942
15:56:32 <wendyreid> Proposed: We will not be adopting the HTML terminology for risky features, close issue 1942
15:56:34 <dauwhe> +1
15:56:35 <ivan> +1
15:56:37 <mgarrish> +1
15:56:37 <MattChan> +1
15:56:37 <BenSchroeter> +1
15:56:37 <duga> +1
15:56:37 <wendyreid> +1
15:56:40 <toshiakikoike> +1
15:56:40 <MasakazuKitahara> +1
15:56:40 <Bill_Kasdorf> +1
15:56:47 <avneeshsingh> +1
15:56:48 <wendyreid> RESOLVED: We will not be adopting the HTML terminology for risky features, close issue 1942
15:57:08 <MattChan> ivan: who has the action on #1944?
15:57:11 <George> +1
15:57:31 <MattChan> mgarrish: I can take it, starting with the name "risky"
15:58:01 <MattChan> wendyreid: there's only one more meeting this year before we go on break
15:58:15 <avneeshsingh> When we think we would go to CR?
15:58:45 <MattChan> ivan: we still have security review issues
15:59:16 <MattChan> dauwhe: TAG may have issues
15:59:35 <MattChan> ivan: I think CR before March is not realistic, though I would be happy to be proven wrong
15:59:43 <dlazin> q+
16:01:12 <dlazin> No problem at all; my zoom was being very unreliable today.
16:01:13 <ivan> rrsagent, draft minutes
16:01:13 <RRSAgent> I have made the request to generate https://www.w3.org/2021/12/03-epub-minutes.html ivan
16:01:20 <dlazin> That was Sumi Clements who I introduced.
16:01:22 <dlazin> Bye!
16:02:09 <ivan> zakim, end meeting
16:02:09 <Zakim> As of this point the attendees have been MasakazuKitahara, ivan, dauwhe, avneesh, avneeshsingh, george, BenSchroeter, wendyreid, toshiakikoike, MattChan, ubbink, Jen_G, mgarrish,
16:02:12 <Zakim> ... duga, charles, Bill_Kasdorf, dlazin, CharlesL
16:02:12 <Zakim> RRSAgent, please draft minutes
16:02:12 <RRSAgent> I have made the request to generate https://www.w3.org/2021/12/03-epub-minutes.html Zakim
16:02:14 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
16:02:19 <Zakim> Zakim has left #epub
16:02:23 <ivan> rrsagent, bye
16:02:23 <RRSAgent> I see no action items