16:21:16 RRSAgent has joined #pwg 16:21:16 logging to https://www.w3.org/2018/01/22-pwg-irc 16:21:17 rrsagent, set log public 16:21:17 Meeting: Publishing Working Group Telco 16:21:17 Chair: Tzviya 16:21:17 Date: 2018-01-22 16:21:17 Regrets+ George, brady 16:21:17 Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2018Jan/0069.html 16:21:17 ivan has changed the topic to: Meeting Agenda 2018-01-22: https://lists.w3.org/Archives/Public/public-publ-wg/2018Jan/0069.html 16:22:22 regrets+ pkra 16:45:34 ivan has left #pwg 16:45:44 baldurbjarnason has joined #pwg 16:47:44 wolfgang has joined #pwg 16:50:33 mateus has joined #pwg 16:51:23 present+ 16:53:58 present+ 16:55:42 BillM has joined #pwg 16:55:54 present+ 16:56:31 scribenick: mateus 16:57:23 cmaden2 has joined #pwg 16:58:05 evan has joined #pwg 16:58:35 laudrain has joined #pwg 16:58:42 jbuehler has joined #pwg 16:58:42 Avneesh has joined #pwg 16:58:59 present+ 16:59:09 present+ Chris_Maden 16:59:16 present+ Bill McCoy 16:59:25 present+ wolfgang 16:59:35 present+ 16:59:46 present+ 16:59:54 josh has joined #pwg 17:00:05 dkaplan3 has joined #pwg 17:00:10 present+ 17:00:21 present+ 17:00:24 EvanOwens has joined #pwg 17:00:29 laurab_ has joined #pwg 17:00:40 bendugas has joined #pwg 17:01:12 lsullam has joined #pwg 17:01:14 rkwright has joined #pwg 17:01:20 present+ 17:01:27 present+ 17:01:29 jasminemulliken has joined #pwg 17:01:29 present+ 17:01:30 Vlad has joined #pwg 17:01:48 toshiakikoike has joined #pwg 17:01:54 ivan has joined #pwg 17:02:01 HeatherF has joined #pwg 17:02:07 present+ 17:02:10 present+ 17:02:17 present+ 17:02:17 zakim, who is here? 17:02:17 Present: mateus, baldurbjarnason, tzviya, Avneesh, Chris_Maden, Bill, McCoy, wolfgang, laudrain, evan, dkaplan, josh, mattg, lsullam, rkwright, toshiakikoike, rachel_, ivan 17:02:20 On IRC I see HeatherF, ivan, toshiakikoike, Vlad, jasminemulliken, rkwright, lsullam, bendugas, laurab_, EvanOwens, dkaplan3, josh, Avneesh, jbuehler, laudrain, evan, cmaden2, 17:02:20 ... BillM, mateus, wolfgang, baldurbjarnason, RRSAgent, Zakim, mattg, tzviya, rachel_, Karen, plinss, bigbluehat, github-bot, astearns, dbaron, jyasskin, dauwhe 17:02:45 GoToMeeting is working for me. 17:02:47 clapierre has joined #pwg 17:02:52 present+ 17:02:54 present+ vlad 17:03:04 scribenick: dauwhe 17:03:09 present+ 17:03:15 tzviya: let's get started 17:03:15 present+ 17:03:18 timCole has joined #pwg 17:03:25 rdeltour has joined #pwg 17:03:31 https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-01-08-minutes 17:03:34 tzviya: minutes from last meeting... 17:03:38 ... any comments? 17:03:48 tzviya: Minutes approved. 17:03:49 present+ Tim_Cole 17:03:49 Hadrien has joined #pwg 17:03:53 present+ dauwhe 17:03:56 present+ 17:04:00 tzviya: we have some new members here 17:04:13 ... anyone else here for the first time today? 17:04:17 present+ rkwright 17:05:16 marisa has joined #pwg 17:05:24 garth has joined #pwg 17:05:43 Present+ Garth 17:05:46 TOPIC: DPUP-ARIA 2.0 17:05:48 present+ 17:05:52 BenSchroeter has joined #pwg 17:06:02 Bill_Kasdorf has joined #pwg 17:06:03 tzviya: part of our charter is moving on from DPUB-ARIA 1.0 17:06:04 s/DPUP/DPUB/ 17:06:04 present+ 17:06:05 present+ 17:06:12 ... matt and I spoke with Garth and Ivan about this 17:06:33 ... some of the issues are to provide more background 17:06:37 laurentlemeur has joined #pwg 17:07:12 tzviya: DPUB-ARIA 1.0 took EPUB SSV terms, winnowed them down, and put the most useful in the ARIA vocab 17:07:20 ... we bit off more than we expected to chew 17:07:34 https://www.w3.org/TR/dpub-aria-1.0/ 17:07:34 ... DPUB-ARIA 1.0 is a PR (provisional recommendation) 17:07:45 ... complete with AAM 17:07:56 ... they map to assistive technology APIs 17:08:01 ... so they can really help 17:08:07 ... or really hurt if you use them wrong 17:08:20 present+ 17:08:24 ... some role="doc-epigraph" has meaning in HTML 17:08:36 ... are there missing terms? what else do we need? 17:08:55 q+ 17:08:56 ... do we need a 2.0? a 1.1? is what exists today good enough? 17:09:00 present+ teenya 17:09:05 ack wolfgang 17:09:12 q+ 17:09:17 q+ 17:09:29 wolfgang: as a dictionary and glossary publisher, we need those sorts of terms 17:09:36 ... headwords, phrases, translations 17:09:43 laurent_ has joined #pwg 17:09:44 ... perhaps as a module 17:09:55 present+ dkaplan3 17:10:01 tzviya: those were never finalized in EPUB 17:10:17 zakim, who is here? 17:10:17 Present: mateus, baldurbjarnason, tzviya, Avneesh, Chris_Maden, Bill, McCoy, wolfgang, laudrain, evan, dkaplan, josh, mattg, lsullam, rkwright, toshiakikoike, rachel_, ivan, 17:10:20 ... and we need to consider the effect on accessibility 17:10:20 ... jasminemulliken, vlad, clapierre, rdeltour, Tim_Cole, dauwhe, Hadrien, Garth, marisa, Bill_Kasdorf, BenSchroeter, bigbluehat, teenya, dkaplan3 17:10:20 On IRC I see laurent_, laurentlemeur, Bill_Kasdorf, BenSchroeter, garth, marisa, Hadrien, rdeltour, timCole, clapierre, HeatherF, ivan, toshiakikoike, Vlad, jasminemulliken, 17:10:24 ... rkwright, lsullam, bendugas, laurab_, EvanOwens, dkaplan3, josh, Avneesh, jbuehler, laudrain, evan, cmaden2, BillM, mateus, wolfgang, baldurbjarnason, RRSAgent, Zakim, mattg, 17:10:24 ... tzviya, rachel_, Karen, plinss, bigbluehat, github-bot, astearns, dbaron, jyasskin, dauwhe 17:10:24 q+ 17:10:28 q? 17:10:32 ack laudrain 17:10:32 ... I'm not sure ARIA is the best home for those terms 17:10:44 NickRuffilo has joined #pwg 17:10:50 present: nickruffilo 17:10:57 fyi EPUB Indexing looks final: http://www.idpf.org/epub/idx/ 17:10:59 laudrain: we had with @epub-type several higher-level semantic types, like bodymatter, frontmatter, backmatter 17:11:00 present+ NickRuffilo 17:11:15 ... how can I help the reading system to know where bodymatter starting, the true content? 17:11:22 q+ 17:11:22 zakim, who is here? 17:11:23 Present: nickruffilo 17:11:23 On IRC I see NickRuffilo, laurent_, laurentlemeur, Bill_Kasdorf, BenSchroeter, garth, marisa, Hadrien, rdeltour, timCole, clapierre, HeatherF, ivan, toshiakikoike, Vlad, 17:11:23 ... jasminemulliken, rkwright, lsullam, bendugas, laurab_, EvanOwens, dkaplan3, josh, Avneesh, jbuehler, laudrain, evan, cmaden2, BillM, mateus, wolfgang, baldurbjarnason, 17:11:25 ... RRSAgent, Zakim, mattg, tzviya, rachel_, Karen, plinss, bigbluehat, github-bot, astearns, dbaron, jyasskin, dauwhe 17:11:33 ... in recent EPUB 3 files, we have made high-level epub:types mandatory 17:11:56 q+ 17:11:57 ... we gain some way of saying that there is a document that is body matter and chapter 17:12:10 ... and we can say frontmatter + cover, frontmatter+ title page 17:12:19 present+ mateus, baldurbjarnason, tzviya, Avneesh, Chris_Maden, Bill, McCoy, wolfgang, laudrain, evan, dkaplan, josh, mattg, lsullam, rkwright, toshiakikoike, rachel_, ivan 17:12:30 present+ jasminemulliken, vlad, clapierre, rdeltour 17:12:33 ... today I find in aria @role that there are significant roles like chapter, but I can't build the heirarchy 17:12:49 ... I cannot say where is the front matter, where is the body matter, where is the back matter? 17:12:59 s/heirarchy/hierarchy/ 17:13:04 zakim, who is here? 17:13:04 Present: nickruffilo, mateus, baldurbjarnason, tzviya, Avneesh, Chris_Maden, Bill, McCoy, wolfgang, laudrain, evan, dkaplan, josh, mattg, lsullam, rkwright, toshiakikoike, rachel_, 17:13:04 present+ 17:13:07 ... ivan, jasminemulliken, vlad, clapierre, rdeltour 17:13:07 On IRC I see NickRuffilo, laurent_, laurentlemeur, Bill_Kasdorf, BenSchroeter, garth, marisa, Hadrien, rdeltour, timCole, clapierre, HeatherF, ivan, toshiakikoike, Vlad, 17:13:07 ... jasminemulliken, rkwright, lsullam, bendugas, laurab_, EvanOwens, dkaplan3, josh, Avneesh, jbuehler, laudrain, evan, cmaden2, BillM, mateus, wolfgang, baldurbjarnason, 17:13:09 ... RRSAgent, Zakim, mattg, tzviya, rachel_, Karen, plinss, bigbluehat, github-bot, astearns, dbaron, jyasskin, dauwhe 17:13:21 present+ wolfgang 17:13:35 ... I think it would be more complete if we had these in 1.1 17:13:41 tzviya: thanks Luc 17:13:42 ack dkaplan3 17:13:58 present+ laurent 17:14:07 dkaplan3: we can always perfect it, always add more semantics 17:14:11 ... but there's a lot of work in that 17:14:25 ... and I care about the practical value of this to people with disabilities 17:14:51 ... so first, we should work on the things for necessary for AT providers to pick up on what we've already done 17:15:03 +1 to Debora's comments. 17:15:13 ... fine-tuning a spec that's not used yet is not the best use of our resources 17:15:16 q? 17:15:21 +1 to Debora 17:15:21 ack dkaplan3 17:15:22 scribenick: mateus 17:15:29 ack mattg 17:16:01 mattg: the other thing is, we need to separate accessibility functionality that ARIA provides, the semantic model; can't just be overloading things because we want them there for data modeling 17:16:14 +1 to Matt. ARIA is mainly for accessibility. 17:16:14 ... there needs to be a clear a11y reason for the semantics we are adding 17:16:31 ... there's a host of problems with getting these validated and accepted 17:16:54 ... some parts are probably beyond the scope of this group, should probably be built into the HTML platform itself 17:17:12 ... can't just be putting in things that sound good but have no practical applications 17:17:28 q- 17:17:36 ack Bill_Kasdorf 17:17:44 Bill_Kasdorf: i'm in alignment with dkaplan3 17:18:03 q+ 17:18:03 ... the answer will probably come out of the A11y Task Force 17:18:13 ... we should ask them what they need 17:18:20 ack lsullam 17:18:29 present+ lsullam 17:18:34 lsullam: I don't disagree, but on the publishing level we have been incorporating epub:type and role in books 17:18:49 +q 17:18:57 ... very specifically, there's value in "title page" and "copyright" which seem not to be part of the spec now 17:19:02 ack Avneesh 17:19:02 +1 17:19:08 present+ BillM 17:19:14 Avneesh: just to clarify on what the others said 17:19:34 ... when ARIA roles work was going on, the general idea is that epub:type will become ARIA 17:19:46 ... but ARIA is specific to a11y, not necessarily focused in publishing 17:20:02 ... this is not useful if we don't have a11y tech supporting it 17:20:21 ... this WG can't take responsibility over it all 17:20:38 q+ 17:20:45 tzviya: this is very important; there was significant pushback from ARIA WG to add some publishing terms 17:21:13 ... although there is value within publishing, the a11y community might not want to add it to spec that applies to all a11y tech 17:21:39 ack clapierre 17:21:42 ... you could use data-* attributes to add vocabulary specific to your toolchain 17:21:57 clapierre: just a couple things; i agree with what others said 17:22:18 ... adding vocabulary to allow reading systems to jump to different locations--like copyright--could be useful 17:22:38 ... Benetech is doing a certification program that looks into these things, and that promotes these issues to publishers 17:22:53 ... definitely something we're willing to push, as well as to ATs and reading systems 17:22:55 ack ivan 17:23:06 ivan: not disagreeing, but i do see one problem 17:23:15 ... we don't really have a standard place for the semantic information 17:23:18 q+ 17:23:22 ... we're not chartered to do so, so I can push against it 17:23:33 ... but we have a problem because the data attributes aren't for that 17:23:44 ... RDFa is heavy and not necessarily the right solution 17:23:53 q+ 17:23:57 ... as an industry, we have a problem of not having these possibilities offered 17:24:04 ... need to think about it; maybe in a community group 17:24:19 ack dkaplan3 17:24:20 Scholarly HTML? 17:24:21 ... but we should not just forget about the semantic aspect, even if it's not closely related to a11y 17:24:26 +1 to Ivan 17:24:32 ack dkaplan3 17:24:32 dkaplan3: happy to move towards that idea 17:25:04 ... but it's important, in an ideal world, to come up with publishing semantics ... that provide interactions between industry-specific semantics and the a11y tree 17:25:10 ack dkaplan3 17:25:19 ack dkaplan3 17:25:24 ack dkaplan 17:25:25 ... right now, the problem is the only way to encode semantics is in ARIA, but that's not the place for semantics that won't be used by AT 17:25:48 ... if there's a CG, a question could be... can we have a pipeline between the publishing ideas and the a11y community? 17:25:52 q+ 17:26:01 ... doesn't mean that we should put the semantics in DPUB-ARIA 17:26:03 ack tzviya 17:26:07 q- 17:26:21 tzviya: our immediate issue is we need to figure out how to deal with this item in our charter 17:26:23 q+ 17:26:25 q- 17:26:34 ... there don't seem to be a lot of items people see as compelling to add to ARIA 17:26:40 ... let's thing about it over the next week 17:26:41 q- 17:26:56 ... anything that's in the existing EPUB Structural Semantics that belong in ARIA? 17:27:09 ... one thing that's come up in the past is "learning objective", for example 17:27:23 ... we need to think about aspects that are relevant to the whole community 17:27:35 http://www.idpf.org/epub/profiles/edu/structure/ 17:27:41 ... do we have a list? if we have more than, say, five, we will need to think harder about it 17:27:54 q? 17:27:55 ... are there things in the EPUB Structural Semantics that make sense in ARIA? 17:28:03 mattg: where do we record that? 17:28:13 tzviya: email works, or github repo 17:28:31 q+ 17:28:31 there is already a dpub aria repository! 17:28:47 https://github.com/w3c/dpub-aria-2.0 17:28:48 mattg: the main ARIA repo wouldn't be the place 17:29:02 tzviya: there is already a dpub-aria-2.0 repo 17:29:10 ivan: yep, I set it up! 17:29:19 ... we should use that one 17:29:34 ... what's misleading is that the current document there is the old ARIA draft 17:29:41 ... mattg should replace it with an empty page 17:29:48 mattg: i thought we did that... 17:29:53 main role is for a single document, there is no main role for the publication that would say the same as body-matter ! 17:29:55 ... but i'll take a look 17:30:20 q+ 17:30:26 ack laudrain 17:30:29 tzviya: but the main message is: add an issue or comment on the repo if you think there are items in the EPUB vocabulary that should be in ARIA 17:30:56 laudrain: was just going to say that the main role relates to the main tag in HTML... to describe that in a single HTML document, it identifies where the main content starts 17:31:17 ... but we need to encompass several documents, and to differentiate between front and back matter 17:31:31 https://github.com/w3c/dpub-aria-2.0/issues 17:31:32 ... there is probably no relationship to current a11y technologies 17:31:33 q? 17:31:38 ack dauwhe 17:31:41 tzviya: makes sense, let's start making issues in the repo 17:31:55 dauwhe: we need to be careful; this sounds great, encoding semantics in the document 17:32:05 ... but we need to show that UAs will do something useful with this info 17:32:29 ... i don't expect that my reading system will do something magical with these semantics that it's not already doing 17:32:35 TEI exists. And TEI is a problem for a reason, and the reason is that is does *everything* and thus is no standardizable 17:32:40 ... this sounds kind of cool, but we can't add them gratuitously 17:32:47 tzviya: thank you. moving on... 17:32:53 ... implementations update 17:33:08 Topic: Implementation update 17:33:24 Hadrien: as a followup to the last call, where I explained the experiments on Reading app manifest and web app manifest... 17:33:32 ... a number of people posted updates in the issue tracker 17:33:51 ... we have a good set of examples in Readium and others, including epub.js and NYPL's platform 17:34:03 q? 17:34:14 ... not all examples have offline support; some rely on service workers, others on appcache 17:34:48 ... in the same issue, we discussed manifest lifecycle with ivan; i created a draft of the lifecycle if we rely on Readium web app manifest if we rely on it as the ideal 17:34:57 ... I'd like more feedback on these two items 17:35:19 ... we also raised questions for who would be willing to help, and a number of Readium people are interestd 17:35:20 https://github.com/w3c/wpub/issues/121 : lifecycle related issue 17:35:27 ... if there are any others, comment on the issues 17:35:27 q? 17:35:29 q+ 17:35:29 q+ 17:35:42 tzviya: any comments on issues 119, 121, 122? 17:35:45 ack ivan 17:36:24 ivan: this is great; i would like to request that all those who have other types of implementations, in the web or RSs, to look at the lifecycle described by Hadrien, and try to see if it is in line with what they do 17:36:52 ... the point is, many of the lifecycle entries he described are in fact not strongly related to the specific syntax Readium uses 17:37:15 ack dauwhe 17:37:15 ... for example, if garth could contribute what Google Play does, that would be very useful 17:37:47 q+ 17:37:51 dauwhe: this is my weekly reminder that many of these implementations are creating internal information for use of the RSs, and not for authoring needs; we need to think of that too 17:37:52 ack bigbluehat 17:38:32 bigbluehat: just ++ on the value of the lifecycle; the use of JSON is great and it's cool seeing people doing interesting things with it 17:38:53 q? 17:38:54 ... but the process of interpreting and describing this is where the rubber meets the road, and will be a challenge 17:38:56 q+ 17:39:00 ack Hadrien 17:39:27 Hadrien: just pointing out that the draft I created so far is inspired by the WAM, but it's interesting that the result is very different from WAM 17:39:40 ... there's very little from WAM that ends up being relevant for us 17:39:46 q+ to discuss default reading order 17:39:55 ... the infoset in in the FPWD is different from that of the WAM 17:40:15 ... and this has an influence in the lifecycle; it continues to show that we're dealing with very different info from that of the web app manifest 17:40:17 ack tz 17:40:17 q+ 17:40:17 tzviya, you wanted to discuss default reading order 17:40:51 tzviya: one comment on the lifecycle-- the default order duplicates information that becomes irrelevant and annoying to create/interpret 17:40:55 Karen has joined #pwg 17:41:09 Hadrien: it takes a lot of additional processing to create a second document with default ordering 17:41:12 q- 17:41:33 q+ 17:41:34 q+ 17:41:46 ... also, if we have them separate, it's not a matter of serialization, but keeping them in separate documents doesn't feel good from an efficiency and design point of view 17:41:50 q+ 17:41:59 ack ivan 17:42:02 ... it's better to keep all key info in one place. this is regardless of HTML vs JSON 17:42:29 ivan: what we have to look at is, which of the approaches is best for possible authors 17:42:37 ... that was one of the driving efforts at the start 17:43:01 ... the original thing is that people need to have an HTML TOC because this has to be displayed, and we don't want the author to repeat that info in a JSON file 17:43:08 ... i think that was the origin of this difficulty 17:43:15 ack bigbluehat 17:43:37 me/ Dave has to use Ivan’s accent. 17:43:46 bigbluehat: this was something i wanted to get to in the browsing context issue (104?)... it comes down to who's using it and when 17:43:59 ... it's something we're exploring in the lifecycle document 17:44:15 ack dauwhe 17:44:17 q+ on getting back on the WAM issue 17:44:19 ... there's probably more than one actor here, accessing this info, but there are bigger things we need to deal with 17:45:21 dauwhe: since we talked a bit about the difference between Readium manifest and WAM... one of those differences is that WAM, if you access a component of the app, the manifest will apply and open in context in a browser 17:45:28 q+ 17:45:30 q? 17:45:35 ... how does this work for publications, if i access an arbitrary chapter on the web? 17:45:50 ack ivan 17:45:50 ivan, you wanted to comment on getting back on the WAM issue 17:45:52 ... we should avoid a world where publications look different depending on how they were discovered 17:46:26 ivan: the one issue, re Hadrien and WAM, at some point in time we need a separate note or wiki page to give clear arguments and facts on why we don't use the WAM 17:46:34 ... we're not supposed to add new things to the web if we can avoid it 17:46:40 q+ we can't use WAM without requiring building Web Apps for *every* publication 17:46:42 ... if we say we cannot avoid it, we need a good argument 17:46:57 a different thing, re Dave, i am not absolutely sure this is a solvable issue 17:47:31 ... first of all, it may happen that a webpage is part of two different publications, so yes, depending on how you accessed the page, it may look different, as it may be accessed as part of a different publication 17:47:44 ... i'm not sure we should prescribe how this should be handled 17:47:56 ... there is also a link consistency problem 17:48:04 q? 17:48:06 ... i'm worried about getting into that same problem 17:48:08 ack Hadrien 17:48:14 q+ 17:48:42 Hadrien: dauwhe is right that we don't have anything in the draft about how these resources are fetched... brings up these questions about browsing context and reading orders 17:49:03 ... that said, the WAM also doesn't solve the problem of a chapter and its browsing context 17:49:16 ... you're not forced to have a link to the manifest in every chapter 17:49:22 ... and this is true in WAM as well 17:49:37 ack bigbluehat 17:49:45 ... we do need something to describe how resources are fetched, but the problem, as described by dauwhe, is not solved 17:50:05 q+ 17:50:10 bigbluehat: they're not related at all; the WAM does not describe a web app, it just creates an icon and channel for access to the web app 17:50:29 ... you can build the web app without a manifest at all, but it does need to provision the entire experience 17:50:48 ... publishers would ultimately have to provide a reading experience if we were to just extend WAM 17:51:09 ack dauwhe 17:51:10 ... we can iterate on WAM and provide new things, if browsers are on board with supporting collections, reading order, etc... 17:51:15 ... WAM doesn't solve this 17:51:29 https://www.w3.org/TR/appmanifest/#deep-links 17:51:38 dauwhe: WAM does describe deep linking, so if you navigate to within a scope within a web app, the manifest will apply 17:51:39 yeah but that's not discovery 17:51:50 tzviya: we should avoid repeating old meetings 17:51:56 ... we do have a few other items on the agenda 17:52:09 ... garth, ok to leave packaging for next week? 17:52:13 Yes 17:52:18 ... *crickets* 17:52:23 ... I'll go with yes 17:52:27 Topic: FPWD outreach 17:52:42 ... we started asking for feedback on FPWD, but we need more input\ 17:52:55 ... dauwhe has friends in the CSS community 17:53:08 ... I'll be in contact with TAG and Web Platforms 17:53:18 q+ 17:53:22 ... would be good to reach out to others, like Kindle, etc. Kobo... 17:53:22 ack ivan 17:54:00 ivan: it's a little bit more than feedback; it would be very important to have people from, say, the Edge team, coming in and looking at, e.g., Hadrien's draft, and joining the working group and collaborating on it 17:54:10 ... please bring in any contacts you may have 17:54:23 ... they're probably already W3C members 17:55:07 I'd be happy to pull someone in here at Kobo to share some feedback - can someone send me an email with some bullets specifically with what sort of feedback were looking for? 17:55:17 garth: Ok to postpone packaging... and, yes, I will reach out to Edge folks 17:55:21 q+ 17:55:23 thanks! 17:55:28 ack Hadrien 17:55:36 present+ bendugas 17:55:55 Hadrien: I know we pushed packaging, but something that's also relevant... the Google AMP team published a blog post on their future use of web packages on Chrome... 17:56:10 ... we used to think it was far off in the future, but it looks like the Chrome team will use it soon 17:56:25 ... this is unexpected, and is moving quicker than I thought 17:56:33 Intent to implement: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/n7cZXSTwBTY 17:56:40 ... there's a conference coming up, but there might be additional info presented there 17:56:53 tzviya: garth, any news on that? 17:57:10 AMP’s announcement https://amphtml.wordpress.com/2018/01/09/improving-urls-for-amp-pages/ 17:57:14 garth: no, but i just posted the intent to implement from Google 17:57:42 tzviya: any news anyone has on this would be useful, in case any of us are attending meetings pertaining to this 17:57:58 ... also need outreach to Chrome team, maybe duga can do that? 17:58:14 garth: yes, probably, and maybe we can discuss that on Wednesday 17:58:17 q+ 17:58:22 ack ivan 17:58:22 "WebPackaging opens up various compelling use cases, including offline peer-to-peer webapp sharing, web publications, and integrity-preserving distribution of content from non-authoritative server. " 17:58:25 tzviya: anyone else have any other contacts? 17:58:33