14:01:34 <RRSAgent> RRSAgent has joined #epub
14:01:34 <RRSAgent> logging to https://www.w3.org/2022/02/25-epub-irc
14:01:36 <Zakim> RRSAgent, make logs Public
14:01:37 <Zakim> please title this meeting ("meeting: ..."), ivan
14:01:37 <ivan> ivan has changed the topic to: Meeting Agenda 2022-02-25: https://lists.w3.org/Archives/Public/public-epub-wg/2022Feb/0015.html
14:01:38 <ivan> Chair: dauwhe
14:01:38 <ivan> Date: 2022-02-25
14:01:38 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-epub-wg/2022Feb/0015.html
14:01:38 <ivan> Meeting: EPUB 3 Working Group Telco
14:01:38 <ivan> Regrets+ tzviya
14:09:01 <dauwhe> dauwhe has joined #epub
14:45:41 <wendyreid> wendyreid has joined #epub
14:58:52 <avneeshsingh> avneeshsingh has joined #epub
14:58:57 <MattChan> MattChan has joined #epub
14:58:59 <avneeshsingh> present+
14:59:05 <MasakazuKitahara> MasakazuKitahara has joined #epub
14:59:17 <MasakazuKitahara> present+
14:59:37 <toshiakikoike> toshiakikoike has joined #epub
14:59:41 <toshiakikoike> present+
14:59:47 <MattChan> present+
14:59:50 <dauwhe> present+
15:00:57 <ivan> present+
15:00:58 <dlazin> dlazin has joined #epub
15:01:03 <dlazin> present+
15:01:11 <ivan> present+ wendy
15:01:34 <ivan> present+ makoto
15:01:42 <MattChan> scribe+
15:01:54 <mgarrish> mgarrish has joined #epub
15:01:59 <ivan> present+ ben
15:02:06 <mgarrish> present+
15:02:07 <ivan> present+ brady
15:02:11 <ivan> present+ george
15:02:17 <duga> duga has joined #epub
15:02:22 <duga> present+
15:02:55 <CharlesL> CharlesL has joined #epub
15:02:55 <ivan> present+ charles
15:02:59 <GeorgeK> GeorgeK has joined #epub
15:03:07 <MattChan> TOPIC: CSS Prefixes
15:03:08 <GeorgeK> present+
15:03:10 <dauwhe> https://github.com/w3c/epub-specs/issues/2003
15:03:31 <MattChan> dauwhe: ivan wondered if we should label these as deprecated
15:03:34 <ivan> github-bot, bye
15:03:34 <ivan> github-bot bye
15:03:34 <github-bot> github-bot has left #epub
15:04:19 <MattChan> ... i will remind the wg of the definition. Deprecated feature is one which is not recommended for use in this version of spec. Generally have no support in RS. Authors should not use in epubs, RS may support. Validators should alert when encountered in epubs.
15:04:22 <Jen_G> Jen_G has joined #epub
15:04:24 <MattChan> ... i would argue that is not the case here
15:04:28 <Jen_G> Present+
15:04:47 <MattChan> ... these are widely used and somewhat widely supported. I'm also not sure what benefit we get from deprecating them.
15:04:59 <ivan> q+
15:05:18 <MattChan> ... also, the behaviour of prefixed properties in css is pretty well defined, and its common web dev practice to have both prefixed and nonprefixed version of property for widest compat
15:05:26 <dauwhe> ack iv
15:05:49 <MattChan> ivan: we have lets say 15 of those prefixed properties, quite a large number
15:05:59 <MattChan> ... at the moment they are required features, i.e. every RS must implement
15:06:14 <MattChan> ... if we agree with that, then we need to create tests for each of those
15:06:57 <MattChan> dauwhe: one way to phrase this is that these are epub specific features which don't yet have tests
15:06:58 <MattChan> ivan: yes
15:07:22 <MattChan> ... and before we start making tests, we should ask whether it is worth the trouble of doing that work
15:07:25 <MURATA> MURATA has joined #epub
15:07:29 <MURATA> +present
15:07:35 <MattChan> ... agree that the term 'deprecated' may not be correct here
15:07:36 <BenSchroeter> BenSchroeter has joined #epub
15:07:42 <BenSchroeter> present+
15:07:54 <zheng_xu_> zheng_xu_ has joined #epub
15:08:03 <zheng_xu_> present+
15:08:06 <duga> q+
15:08:09 <MattChan> dlazin: is the reason that we want to deal with this that the testing status is unclear?
15:08:11 <MURATA> I'm surprised to see "MUST support all prefixed properties defined"
15:08:15 <MattChan> ... this is motivated mostly by testing?
15:08:22 <Bill_Kasdorf> Bill_Kasdorf has joined #epub
15:08:39 <MattChan> ivan: there are appendices in testing for vocabs, including for this, and i'm not sure what to do with it
15:08:46 <dauwhe> ack duga
15:08:56 <ivan> present+ billk
15:09:01 <Bill_Kasdorf> present+
15:09:01 <MattChan> dlazin: seems like we just need to write tests for this, rather than consider deprecation/under-implemented status
15:09:39 <MattChan> duga: might be embarrassing to include these in the spec, but we can't really get rid of them because there is content that uses these
15:10:03 <MattChan> ... in reality, I see content that uses all possible prefixes, and other content that uses none of the prefixes
15:10:17 <ivan> q+
15:10:19 <MattChan> ... toshiakikoike did essentially write some tests for these already, they are in the bug report
15:10:35 <dauwhe> ack iv
15:10:41 <MattChan> dauwhe: i'm not embarrassed by these, we needed them back in the day, there was no alternative
15:11:03 <MattChan> ivan: is it correct that each of those prefixed CSS attribute have now a regular CSS attribute?
15:11:24 <MattChan> ... if 'yes', then having it as a required feature in Core seems not a good thing
15:11:54 <MattChan> ... we could say 'for reasons of backwards compat, then RS should implement as well', but we can also say that new epubs created today should not use these
15:11:59 <MattChan> ... they should use the CSS ones instead
15:12:19 <MattChan> ... the same way that new content should not use mozilla and chrome specific prefixes today
15:12:55 <MattChan> dlazin: yes, they all have non-prefixed versions. At least this is what the documentation currently implies
15:13:06 <MattChan> duga: they all have non-prefixed versions, but the function isn't 1-to-1
15:13:38 <MattChan> dauwhe: also, given the nature of epub RSes, we often need to author content that needs to work in RS that have not been updated in a while
15:13:53 <MattChan> ... there might be cases where there are good reasons to do this
15:14:10 <MattChan> ... CSS accounts for this by allowing authors to use both prefixed and non-prefixed
15:14:23 <MattChan> dlazin: don't old RS implicitly not support epub 33?
15:14:39 <duga> q+
15:14:41 <MattChan> wendyreid: no, because epub 33 is a valid epub 3.2, etc. etc. backwards compat
15:14:47 <MattChan> dauwhe: i think we just write some tests here
15:14:50 <dauwhe> ack du
15:14:56 <wendyreid> q+
15:15:19 <MattChan> duga: do we point people to the right way to deal with pre-fixed properties (i.e. also state the non-prefixed properties)?
15:15:37 <ivan> q+
15:15:44 <MattChan> dauwhe: this is just an appendix, we're not necessarily calling attention to the right way to do things in this section
15:15:59 <dauwhe> ack we
15:16:01 <MattChan> duga: i was thinking just a pointer, but okay, this is pretty easy to test
15:16:50 <mgarrish> q+
15:16:57 <dauwhe> ack iv
15:17:00 <duga> q+
15:17:02 <MattChan> wendyreid: i think we might want to add text that says 'we're in a different place now, these css properties are supported in modern web, we recommend that you use both prefixed and non-prefixed'
15:17:20 <MattChan> ivan: the fact that it is an appendix does not mean that it is non-normative, let's not conflate these
15:17:20 <MURATA> "-epub-text-combine: horizontal 3" cannot be rewritten without using prefixes
15:17:26 <MattChan> ... for the time being this is a normative section
15:18:13 <MattChan> ... my proposal would be, in the content document, both entries should be marked 'should not be used', and in the RS doc, we say 'should implement'
15:18:31 <MattChan> ... and if they are 'should', then we should write tests
15:18:35 <dauwhe> ack mg
15:18:51 <dauwhe> q+
15:19:03 <MattChan> mgarrish: it does strike me as strange that RS says you must support all of these properties, but we're also talking about how these are being phased out
15:19:36 <duga> q-
15:19:46 <MattChan> dauwhe: we do have a note about this, but it's in the main section rather than the appendix
15:19:48 <dauwhe> https://w3c.github.io/epub-specs/epub33/core/#sec-css-prefixed
15:19:49 <MattChan> ... i'll post a link
15:20:05 <duga> q+
15:20:14 <MattChan> ivan: i propose to put this in the main text, as normative text
15:20:39 <dauwhe> ack dau
15:20:41 <dauwhe> ack du
15:20:48 <MattChan> dauwhe: i'm opposed to that. I think what we have is good enough. Given how CSS works, and that people have legitimate reason to use these prefixes, I don't think we make a SHOULD not statement
15:21:05 <MattChan> duga: i'm now worried that even the should in the note is too strong
15:21:46 <Bill_Kasdorf> Is "as the Working Group does not anticipate supporting them in the next major version of EPUB" still the case? Probably, because of "major version"?
15:22:08 <MattChan> ... older RS exist that don't support the unprefixed properties, and we're telling authors not to use the prefixes. So are we asking authors to have knowledge of which RS will work with their epub, and which won't?
15:22:22 <dauwhe> q+
15:22:35 <MattChan> ... are we telling authors that they need to do their own research, when they already have a way of making it work everywhere?
15:23:25 <CharlesL> q+
15:23:26 <dauwhe> ack d
15:23:28 <dauwhe> ack ch
15:23:36 <MattChan> dauwhe: we say that they SHOULD use the unprefixed ones, but we don't say they SHOULD not use the prefixed one...
15:24:06 <MattChan> CharlesL: sounds like the unprefixed is a must, but authors may add in these prefixes for backwards compat with older RS, right?
15:24:19 <MattChan> dauwhe: right now RS spec says RS MUST support these, right?
15:24:29 <MattChan> mgarrish: yes
15:24:42 <MattChan> dauwhe: and for the reasons we've mentioned I don't think this should change
15:25:00 <MattChan> ... in general, stuff like this is easy. You're just aliasing something. Browsers know how to do this, do it all the time.
15:25:04 <MattChan> ... no real burden on RS
15:25:05 <mgarrish> q+
15:25:16 <mgarrish> q-
15:25:21 <MattChan> ... and i'm uncomfortable saying RS must support, but authors must not use it
15:25:29 <dauwhe> ack mg
15:25:35 <duga> q+
15:25:39 <dauwhe> ack du
15:25:44 <MattChan> duga: i don't think that's the situation
15:25:47 <ivan> q+
15:26:09 <MattChan> ... if i were to advise someone writing an epub now to get their epub to work on the widest range of RS, i would say include both prefixed and non-prefixed
15:26:28 <dauwhe> ack iv
15:26:40 <MattChan> ... unless you really want to do the work to limit which RS your epub will be compatible with, or you want to do the analysis on different RS
15:27:38 <MattChan> ivan: i see the must support in RS, and grudgingly I agree. For content, we say you may use the prefixed properties.
15:27:56 <MattChan> ... right now I read the content doc to say that you MUST use the prefixes, and I think that is too much
15:28:02 <MattChan> dauwhe: so this would be a normative MAY?
15:28:04 <MattChan> ivan: yes
15:28:14 <duga> q+
15:28:17 <mgarrish> q+
15:28:18 <dauwhe> ack d
15:28:21 <MattChan> ... you may use prefixed properties in so and so situation
15:28:51 <MattChan> duga: i almost feel like if we are giving advice to content authors, then we should make it a SHOULD
15:28:57 <dauwhe> ack mg
15:29:29 <MattChan> mgarrish: going back to the CSS section, we are saying that you MUST support these properties, but you aren't required to support the CSS modules that they are part of?
15:29:34 <MattChan> ... is this inconsistent?
15:29:48 <MattChan> ivan: ouch
15:30:01 <MattChan> dauwhe: looking at snapshot 2021, writing modes is in core
15:30:31 <duga> q+
15:31:05 <MattChan> dauwhe: i'd have a difficult time telling RS they don't have to support CSS text 3
15:31:12 <dauwhe> ack d
15:31:42 <MattChan> duga: i know we cannot remove these properties, we need them to support vertical texts
15:32:00 <MattChan> dauwhe: okay, so consensus is that we need tests, that these aren't going away
15:32:16 <MattChan> ... no consensus yet on what advice/statement should be in the core spec
15:32:39 <MattChan> ... do we want to have someone propose different text for 3.3.1.3?
15:33:11 <MattChan> ... can we do this working out of the language in the issue?
15:33:24 <MattChan> wendyreid: writing the tests will probably help
15:33:53 <MattChan> ... if the person who writes the tests sees that the properties are more or less supported it will inform what we say
15:34:00 <MattChan> ivan: so do we have a test writer?
15:34:06 <MattChan> wendyreid: i can do it
15:35:06 <MattChan> dauwhe: okay, sounds like we have a plan to make progress
15:35:30 <MattChan> ivan: sorry to have raised this so late in the process
15:35:39 <dauwhe> https://github.com/w3c/epub-specs/pull/2002
15:35:47 <MattChan> TOPIC: Package Metadata Reporting Document
15:36:24 <MattChan> mgarrish: coming out of last meeting, we said we needed to report on all the metadata vocab we define in the authoring spec
15:36:34 <MattChan> ... basically same issue we had with DPUB ARIA vocab
15:36:49 <MattChan> ... I created a table that maps each property to the publishers that use them
15:37:03 <MattChan> ... its just a placeholder so far, needs to be filled out
15:37:30 <CharlesL> q+
15:37:33 <MattChan> dauwhe: how would this work? Will we merge this, and then publishers who use the property would add their name via PR?
15:37:49 <MattChan> mgarrish: we ask people to open PR, or they send them lists of which properties they are using, and we can add them
15:38:03 <MattChan> ... also question of if we need to have links from the spec to this table, and how that would work
15:38:07 <dauwhe> ack ch
15:38:09 <MattChan> ... not sure if we need to tackle that now
15:38:11 <ivan> q+
15:38:39 <MattChan> CharlesL: if we need to have any properties that are being used, I can go through the completed CGA reports from publishers and find all the accessibility metadata in there if that's helpful
15:38:48 <BenSchroeter> q+
15:39:01 <MattChan> mgarrish: i'm hoping you can take a look at the a11y document
15:39:15 <MattChan> ... you'd just put the name of the publishers in there
15:39:27 <MattChan> ... i've pre-populated some names based on CGA certification
15:39:29 <dauwhe> ack iv
15:39:49 <MattChan> dauwhe: my proposal is to merge this because what mgarrish referred to about linking
15:40:01 <MattChan> s/dauwhe/ivan
15:40:09 <CharlesL> q+
15:40:12 <dauwhe> q?
15:40:18 <dauwhe> ack ben
15:40:53 <MattChan> BenSchroeter: just a word of caution that we're not violating any NDAs when we're pulling stuff from GCA reports
15:40:59 <dauwhe> ack ch
15:41:10 <MattChan> CharlesL: absolutely, i'll talk to the publishers first
15:41:35 <ivan> q+
15:42:20 <MattChan> ... mgarrish when you mention the certifier report, I actually spoke with folks at Benetech about creating separate reports for publishers who have passed certification, and creating report pages for each publisher
15:42:39 <MattChan> ... the page could be customized for each publisher, to include their support email address, etc.
15:42:56 <MattChan> mgarrish: if you want I can take out the changes to the a11y report and make it a separate PR
15:42:57 <dauwhe> ack iv
15:43:05 <MattChan> ... give you time to talk to publishers
15:43:09 <MattChan> CharlesL: okay, thanks
15:43:27 <MattChan> ivan: we also need the same thing for all the vocab in the package document
15:43:32 <dauwhe> q+
15:43:37 <MattChan> ... maybe its already somewhere, but we need to collect that too
15:43:51 <MattChan> CharlesL: i was just referring the a11y properties
15:44:01 <MattChan> dauwhe: sounds like there is broad consensus about merging these
15:44:16 <MattChan> ... also caution that just because a publisher uses some of these properties, it doesn't mean that it works anywhere
15:44:30 <MattChan> ... e.g. "file as"
15:44:43 <MattChan> ... and just because a publisher uses a property, doesn't mean they are using it properly
15:45:03 <CharlesL> q+
15:45:05 <MattChan> ... in some cases (e.g. dc:rights), not clear how these are to be used
15:45:07 <dauwhe> ack da
15:45:10 <dauwhe> ack ch
15:45:34 <MattChan> CharlesL: not just RS, but libraries and bookstores as well can expose this metadata, as a secondary source for examples of use
15:45:46 <MattChan> mgarrish: we just need to show that these aren't completely fanciful
15:45:56 <MattChan> dauwhe: right, that people want to use these metadata
15:46:27 <wendyreid> Proposed: Merge PR 2002
15:46:30 <ivan> +1
15:46:32 <wendyreid> +1
15:46:33 <MattChan> +1
15:46:36 <mgarrish> +1
15:46:37 <Bill_Kasdorf> +1
15:46:43 <BenSchroeter> +1
15:46:45 <MasakazuKitahara> +1
15:46:45 <dauwhe> +1
15:46:47 <toshiakikoike> +1
15:46:55 <wendyreid> RESOLVED: Merge PR 2002
15:47:16 <MattChan> dauwhe: mgarrish you were going to split out some of the stuff for CharlesL before you merge it?
15:47:18 <MattChan> mgarrish: yes, i will
15:47:21 <dauwhe> https://github.com/w3c/epub-specs/issues/1843
15:47:24 <MattChan> TOPIC: EPUB and Origin
15:47:51 <MattChan> dauwhe: this is issue about external iframe resources, and CORS headers about having this in epub
15:48:19 <MattChan> dlazin: we were talking a few months ago about whether external resources are good idea, and how there are legit cases for them.
15:48:40 <MattChan> ... say you are an educational publisher, and you have a demo that you want to embed, but only in your website and your epubs
15:49:05 <MattChan> ... normally you do this by setting X-frame or CSP in your server
15:49:27 <MattChan> ... not sure how you would do this in epub, since it doesn't have URL
15:49:39 <ivan> q+
15:50:03 <MattChan> ... the internal browser core may have a URL that it uses to refer to the epub, but as an RS developer, I don't know what that is
15:50:32 <MattChan> ivan: i played with this URL area in the spec in Nov, and your supposition is correct
15:50:45 <MattChan> ... an epub document has its own fancy URL which is different from one RS to another
15:51:18 <MattChan> ... there is no way a 3rd party setting up a website could refer to it in a security policy
15:51:36 <MattChan> ... we don't define what the root URL of the package is, we only define it in a behavioural way
15:51:43 <dauwhe> ack iv
15:51:56 <MattChan> ... earlier today I saw in Apple Books and Thorium that some of them use URLs that are non-standard, etc.
15:52:07 <MattChan> ... simply put, you can't do it. And not sure how you would do it.
15:52:18 <mgarrish> q+
15:52:23 <MattChan> dlazin: might be okay for us not to implement it, but it might not be our call whether we implement it or not
15:52:31 <duga> q+
15:52:39 <MattChan> ... security horizontal review might take issue with it
15:52:50 <dauwhe> ack mg
15:52:56 <MattChan> ... should we note this in our security document?
15:53:25 <MattChan> mgarrish: it's not that it's not supported, but as you say, you can't rely on it or it might work
15:53:36 <MattChan> ... it's the same with any web scenario where you can't set the header
15:53:38 <dauwhe> ack du
15:54:30 <dlazin> q+
15:54:39 <MattChan> duga: the way you describe CORS is almost like a DRM mechanism, but it's more like, a script is only allow to request resources from a place that would allow that origin
15:55:12 <MattChan> ... this is only for scripting and a few other places
15:55:47 <MattChan> ... we support CORS, but it might not work. You can use wildcards to set the origins
15:55:52 <dauwhe> ack dl
15:55:54 <ivan> +1 for Brady's formulation
15:56:04 <MattChan> ... we haven't created a security hole, it's more like our security is very restrictive/tight
15:56:25 <MattChan> dlazin: so I would have to allow my server to be iframed by anyone, can't limit to only my own books
15:56:38 <ivan> q+
15:56:50 <dauwhe> ack iv
15:56:59 <MattChan> ... say you had a sign-in page that i wanted to control iframing of, I couldn't do that
15:57:25 <MattChan> ivan: only change I can see is to explicitly add this to the security document somewhere
15:57:32 <dlazin> q+
15:57:38 <dauwhe> ack dl
15:57:42 <MattChan> ... it's otherwise an unsolvable problem
15:57:54 <MattChan> dlazin: duga's point about wildcards means there might be a solution
15:58:19 <MattChan> ... could we for example say that epub origins must always have epub: protocol?
15:58:32 <MattChan> ivan: we'd have to define the protocol, and no current RS uses it
15:59:05 <MattChan> dlazin: at a future point, if we could create some limits on the epub origin that are easily wildcardable, we could make CORS/CSP work in epub
15:59:11 <MattChan> ivan: we can think about this in epub 4
15:59:23 <MattChan> dauwhe: not sure what solution we can implement in 3.3
15:59:37 <MattChan> dlazin: i propose that we add something about this in the security note
15:59:48 <MattChan> ivan: dlazin, you should
16:00:19 <MattChan> dauwhe: okay, good bye for now, thank you for all the interesting discussion!
16:00:30 <ivan> rrsagent, draft minutes
16:00:30 <RRSAgent> I have made the request to generate https://www.w3.org/2022/02/25-epub-minutes.html ivan
16:02:14 <ivan> zakim, end meeting
16:02:14 <Zakim> As of this point the attendees have been avneeshsingh, MasakazuKitahara, toshiakikoike, MattChan, dauwhe, ivan, dlazin, wendy, makoto, ben, mgarrish, brady, george, duga, charles,
16:02:17 <Zakim> ... GeorgeK, Jen_G, present, BenSchroeter, zheng_xu_, billk, Bill_Kasdorf
16:02:17 <Zakim> RRSAgent, please draft minutes
16:02:17 <RRSAgent> I have made the request to generate https://www.w3.org/2022/02/25-epub-minutes.html Zakim
16:02:19 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
16:02:22 <ivan> rrsagent, bye
16:02:22 <RRSAgent> I see no action items