16:17:18 <RRSAgent> RRSAgent has joined #pwg
16:17:18 <RRSAgent> logging to https://www.w3.org/2018/02/05-pwg-irc
16:17:19 <ivan> rrsagent, set log public
16:17:19 <ivan> Meeting: Publishing Working Group Telco
16:17:19 <ivan> Chair: Tzviya
16:17:19 <ivan> Date: 2018-02-05
16:17:19 <ivan> Regrets+
16:17:19 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-publ-wg/2018Feb/0006.html
16:17:19 <ivan> ivan has changed the topic to: Meeting Agenda 2018-02-05: https://lists.w3.org/Archives/Public/public-publ-wg/2018Feb/0006.html
16:40:07 <ivan> ivan has joined #pwg
16:44:21 <baldurbjarnason> baldurbjarnason has joined #pwg
16:44:45 <wolfgang> wolfgang has joined #pwg
16:48:47 <ivan> regrets+ rdeltour
16:48:59 <jasminemulliken> jasminemulliken has joined #pwg
16:52:41 <Teenya> Teenya has joined #pwg
16:53:32 <dkaplan3> dkaplan3 has joined #pwg
16:53:46 <Teenya> Present+
16:54:06 <cmaden2> cmaden2 has joined #pwg
16:54:26 <baldurbjarnason> Present+
16:55:16 <Avneesh> Avneesh has joined #pwg
16:56:41 <tzviya> present+
16:57:04 <jasminemulliken> present+
16:57:20 <NickRuffilo> NickRuffilo has joined #pwg
16:57:45 <jbuehler> jbuehler has joined #pwg
16:57:55 <pkra> pkra has joined #pwg
16:58:38 <Evan_Owens> Evan_Owens has joined #pwg
16:58:40 <pkra> pkra has joined #pwg
16:58:44 <pkra> present+ pkra
16:59:10 <gpellegrino> gpellegrino has joined #pwg
16:59:22 <dauwhe> present+ dauwhe
16:59:27 <dkaplan3> present+
16:59:54 <wolfgang> present+ wolfgang
17:00:16 <timCole> timCole has joined #pwg
17:00:20 <laudrain> laudrain has joined #pwg
17:00:27 <Bill_Kasdorf> Bill_Kasdorf has joined #pwg
17:00:29 <Bill_Kasdorf> present+
17:00:57 <Avneesh> present+
17:01:00 <josh> josh has joined #pwg
17:01:03 <cmaden2> present+ Chris_Maden
17:01:08 <laudrain> Present+
17:01:21 <timCole> present+ Tim_Cole
17:01:22 <BenWaltersMS> BenWaltersMS has joined #pwg
17:01:24 <MustLazMS> MustLazMS has joined #pwg
17:01:29 <ivan> present+
17:01:29 <evan> evan has joined #pwg
17:01:34 <MustLazMS> present+
17:01:40 <NickRuffilo> scribenick: nickruffilo
17:01:41 <josh> present+
17:01:43 <evan> present+
17:01:45 <gpellegrino> gpellegrino has joined #pwg
17:01:49 <BenWaltersMS> present+
17:01:57 <gpellegrino> present+
17:01:57 <NickRuffilo> present+
17:02:17 <George> George has joined #pwg
17:02:34 <Rachel> Rachel has joined #pwg
17:02:34 <George> present+ George
17:02:40 <Rachel> present+
17:03:01 <garth> garth has joined #pwg
17:03:11 <Hadrien> Hadrien has joined #pwg
17:03:16 <garth> present+ Garth
17:03:20 <Hadrien> present+
17:03:28 <JunGamo> JunGamo has joined #pwg
17:03:30 <tzviya> https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-01-29-minutes
17:03:30 <ivan> present+ NickRuffilo
17:03:35 <baldurbjarnason> baldurbjarnason has left #pwg
17:03:45 <baldurbjarnason> baldurbjarnason has joined #pwg
17:03:46 <NickRuffilo> Tzviya: Minutes from last week - any comments?  ... Minutes approved
17:03:48 <mateus> mateus has joined #pwg
17:03:54 <mateus> present+
17:04:12 <lsullam> lsullam has joined #pwg
17:04:26 <jasminemulliken> https://www.w3.org/2018/01/30-pwg-new-minutes.html
17:04:32 <JunGamo> present+
17:04:47 <lsullam> present+
17:04:50 <BenSchroeter> BenSchroeter has joined #pwg
17:04:51 <Vlad> Vlad has joined #pwg
17:04:58 <BenSchroeter> present+
17:05:09 <Vlad> present+
17:06:11 <zheng_xu> zheng_xu has joined #pwg
17:06:12 <NickRuffilo> ...: Next item - we had a meeting with new members last week.  Minutes did go around but they are not in the agenda.  If someone can paste them, great.  Thank you to all who joined.  The most important part of that meeting is that we seems to have - lost touch with reality.  We go into technical detial in the call and on github but we have difficulty linking it back to use-cases and the specifications
17:06:12 <NickRuffilo> .  Something at TPAC and was suggested last week is that when we talk about a technical detail is that we bring it back to a use-case.  Ivan refreshed the use-case repostory - which goes back to the DPUB group.  Laurant had discussed working on this.  Josh Piel offered to work.  When we talk about super-technical details, lets make sure that we take a step back and make sure there is a use-case
17:06:13 <NickRuffilo> about how it would work on the real world.  Starting today, we're going to keep a living docoument of use-cases.
17:06:16 <zheng_xu> present+
17:06:20 <marisa> marisa has joined #pwg
17:06:28 <laurentlemeur> laurentlemeur has joined #pwg
17:06:30 <ivan> present+ laurent
17:06:38 <marisa> present+
17:06:44 <wolfgang> s/Laurant/Laurent/
17:06:46 <NickRuffilo> ...: Lets make sure we work on this together, and we iron out logistics.  The main point is that technical details are not the focus - but something usable is.
17:06:49 <tzviya> q?
17:06:57 <Hadrien> q+
17:06:58 <ivan> github repo for use cases: https://github.com/w3c/dpub-pwp-ucr
17:07:05 <tzviya> ack Hadrien
17:07:35 <rkwright> rkwright has joined #pwg
17:07:38 <NickRuffilo> Hadrien: One comment, we have been very abstract up to now - with an infosec.  Working on affordances will be helpful as we will ahve to connect more directly to the use cases.  It will get better in the next few weeks.
17:07:43 <josh> s/Piel/Pyle
17:07:52 <ivan> zakim, who is here?
17:07:52 <Zakim> Present: Teenya, baldurbjarnason, tzviya, jasminemulliken, pkra, dauwhe, dkaplan, wolfgang, Bill_Kasdorf, Avneesh, Chris_Maden, laudrain, Tim_Cole, ivan, MustLazMS, josh, evan,
17:07:55 <Zakim> ... BenWaltersMS, gpellegrino, NickRuffilo, George, Rachel, Garth, Hadrien, mateus, JunGamo, lsullam, BenSchroeter, Vlad, zheng_xu, laurent, marisa
17:07:55 <Zakim> On IRC I see rkwright, laurentlemeur, marisa, zheng_xu, Vlad, BenSchroeter, lsullam, mateus, baldurbjarnason, JunGamo, Hadrien, garth, Rachel, George, gpellegrino, evan, MustLazMS,
17:07:58 <wolfgang> s/infosec/infoset/
17:07:59 <Zakim> ... BenWaltersMS, josh, Bill_Kasdorf, laudrain, timCole, pkra, Evan_Owens, jbuehler, NickRuffilo, Avneesh, cmaden2, dkaplan3, Teenya, jasminemulliken, wolfgang, ivan, RRSAgent,
17:07:59 <Zakim> ... Zakim, plinss, tzviya, Karen, dauwhe, astearns, dbaron, github-bot, jyasskin, bigbluehat
17:08:07 <rkwright> present+
17:08:08 <garth> https://github.com/w3c/wpub/issues/32#issuecomment-362273649
17:08:16 <tzviya> https://github.com/w3c/wpub/issues/32#issuecomment-362273649
17:08:24 <BillM> BillM has joined #PWG
17:08:34 <ivan> Topic: TAG comments
17:08:56 <NickRuffilo> Tzviya: Hopefully everyone had a chance to read this - or not. (issue #32)
17:09:14 <duga> duga has joined #pwg
17:09:22 <duga> present+
17:09:42 <Hadrien> q+
17:10:57 <NickRuffilo> Garth: The key is the question posed in the middle of the 2nd paragraph.  Is it the goal of the group to make a new packaging format for reading, or to gain support for missing features and first-class support for items related to publishing.  It may not be universal, but the argument there is that if we are in the second piece of the question - which matches with our charter - then there is a
17:10:57 <NickRuffilo> strong push to base off the web app manifest and proposing extensions - over rolling our own.  If we roll our own, the likelyhood of getting takeup in the browser community is much lower.
17:12:16 <jbuehler> q+
17:12:19 <dauwhe> q?
17:12:22 <NickRuffilo> Ivan: I think that's the core of the problem.  There are references to the packaging spec and format.  Because that is in a much earlier stage.  It's a bit different and I don't think it's at the core of our discussions.  In general - the relationship to browser acceptance and implementations is the core question.  The answer to the question is - it's not both.  We are not in the business of
17:12:22 <NickRuffilo> defining a new packaging format.  Our goal is to have something that works in a browser AND can be used in a packaged format in other environments.  It's not exclusive or questions.
17:12:23 <gpellegrino> gpellegrino has joined #pwg
17:12:33 <tzviya> ack Hadrien
17:12:35 <NickRuffilo> Garth: PWP is the first of those two, and WP might be the second.
17:13:15 <ivan> q+
17:13:55 <tzviya> ack jbuehler
17:13:56 <NickRuffilo> Hadrien: I'm a bit conflicted.  I'm hearing that we should be adopting the WAM and extending it, and on the other side, we're getting notes that we shouldn't expect browsers to handle offline, or other things we need.  So it seems unfair that adapting WAM would get us any extra features or support.  It was in another issues - and baldur raised a bunch of questions that do not seem to be answered
17:13:56 <NickRuffilo> .  If we use the WAM - there has to be some benefit, but if we don't get implementation, why is it better to use the WAM instead of something else.
17:14:07 <garth> q?
17:14:21 <NickRuffilo> Jeff: Why do we care if the browser accepts the manifest?  How does that affect the packaged web publication?
17:14:24 <dauwhe> q+
17:14:50 <NickRuffilo> Tzviya: we need the browsers to recognize what we're doing.
17:14:54 <bigbluehat> present+
17:16:10 <NickRuffilo> Garth: I don't know whether - to what level of realism - one mode that we hear from some of the - there was the conference following TPAC - and you want to eventually have it so that a browser understands what a publication is - such as reading modes in some browsers.  There is an argument that if you use the WAM - there's an argument that if you're using something that browsers are already using
17:16:10 <NickRuffilo> in some case - eventually browsers could understand web publications and paging between resources - which makes them native.
17:16:40 <NickRuffilo> JefF: So we want native support at a browser level - that runs the risk of limiting what the publisher may want to do.  Do we have to design something that is adopted by browsers?
17:16:45 <tzviya> ack ivan
17:16:45 <garth> q?
17:16:51 <NickRuffilo> Garth: I'm not sure we'd take that as a fact, but it's a potential perspective.
17:17:11 <garth> q?
17:17:36 <gpellegrino> gpellegrino has joined #pwg
17:17:56 <NickRuffilo> Ivan: It's more an answer to Hadrien - but it's related.  I think we have to realize that not everything is purely a technical issue.  By giving the impression that we at least - try to reinvent lots of things - it will be more difficult to get things accepted by browsers -we have some browsers who can speak from their point of view.  There is an element of social context here - to try to go as
17:17:56 <NickRuffilo> much as we can towards what is already there and implemented
17:17:57 <NickRuffilo> q+
17:18:10 <NickRuffilo> ...: and do whatever is possible to rely on whatever is there.
17:18:17 <tzviya> ack dauwhe
17:18:20 <garth> ack dauwhe
17:18:35 <BenWaltersMS> q+
17:19:16 <NickRuffilo> Dave: We talk about something working in the browser - but there is alot behind that phrase.  Ebub works in the browser for some values on browser - such as edge.  By itself, throw enough programming at something and you can make anything happen.  So the question is how far do we want things to go, so is it having a publisher not need to write code?
17:19:19 <tzviya> ack NickRuffilo
17:19:21 <garth> ack NickRuffilo
17:19:26 <tzviya> s/ebub/epub
17:20:33 <tzviya> q?
17:20:58 <tzviya> ack BenWaltersMS
17:22:20 <NickRuffilo> Ben: The points here and questions here are right.  Publishers favor existing specs/techs.  It's not clear that WAM is close enough to be useful.  I'll agree with what the onramps for browsers are.  Does it makes sense to package scripts?  Do we make standardized extensions - do they align with WAM?  I don't have any answers, but I think we need to keep going along the lines of these questions -
17:22:20 <NickRuffilo> do we reuse WAM or something in the same vein.
17:22:21 <bigbluehat> q+
17:22:40 <tzviya> https://www.w3.org/2017/04/publ-wg-charter/
17:23:27 <NickRuffilo> tzviya: we need to review the charter and make sure we all agree with it.  Also - are we packaging what's on the browser, or are we doing something differnet.
17:23:37 <tzviya> ack bigbluehat
17:24:25 <tzviya> DPUB IG use cases https://www.w3.org/TR/pwp-ucr/
17:24:28 <Teenya> are we talking about 4.3 Input Documents- Packaging on the web Section in the charter?
17:24:58 <david_stroup> david_stroup has joined #pwg
17:25:36 <ivan> q+
17:25:40 <NickRuffilo> Ben: I would love for us to confirm some things - rather than operate on assumptions and dove right into spec'ing of assumptions.  Alot of strain has been around the fact that we have different assumptions about what, who, and how it should happen.  Clarifying those things - which the IG attempted with the use-cases.  If we can map any specs we can write to map to those use cases, then we can make
17:25:40 <NickRuffilo> the case to browsers much easier.  The TAG has their things they want us to use, and we have to have our reasons why we may not use them.  WAM is incomplete for our needs, but we can go back and say why we need to iterate.  We need to ask 'why are we spec'ing and what' - the who experience around having a publication.
17:25:41 <tzviya> ack ivan
17:26:10 <bigbluehat> q+
17:27:28 <NickRuffilo> Ivan: Following what Ben said - it's true that what we want is something that can be followed through with affordances, but we've also heard that all this can be done by clever javascript on the web - so what are we doing?  The important point we're doing is that it should be easy to create the environment that we are talking about.  Even if it is doable by a clever javascript - we can and should
17:27:28 <NickRuffilo> try to standardize a kind of layer - that can be implemented once and for all, so others (in the general sense) could generate those publications very quickly and easily.  That aspect of things - the fact that it's realizable on top of the web platform today is not enough to say.  That's not the full answer.  it should be realizable easily and quickly by laypeople - well relatively.
17:27:29 <gpellegrino> gpellegrino has joined #pwg
17:27:30 <tzviya> ack bigbluehat
17:28:35 <tzviya> q?
17:28:39 <jbuehler> q+
17:29:09 <tzviya> ack jbuehler
17:29:16 <NickRuffilo> Benjamin: That's fabulous and should be shared.  Publishers have long-sightedness when looking backwards.  Our publisher made books 200 years ago - for which the JS does not need to be updated.  A sample that I created throws tons of features that are deprecated, and features that are not yet designed.  You want to create something that things 200 years from now can read it.  Javascript is not
17:29:16 <NickRuffilo> that.  We need to declare if we want descriptive formats instead of prescriptive formats.
17:30:11 <gpellegrino> +1 descriptive
17:30:37 <NickRuffilo> Jeff: Browsers will continue changing - constantly.  In my experience, no matter what we design, the more specific we get, the more people will break out of specifications.  I constantly have built epubs that break specifications because publishers need something that breaks the spec.  People are going to do what they need.  Not in terms of creating specifications, but hardwaring in notions of
17:30:37 <NickRuffilo> what a publication looks like.  Whether in JS or what, but it's important we keep flexibility.  Lets not assume hard specs.
17:31:12 <Hadrien> q+
17:31:20 <ivan> q+
17:31:22 <pkra> q+
17:31:27 <NickRuffilo> Tzviya: So we want things as simple as possible - but we might be conflating the web publication with the packaged web publication.  I'd like my web publication to work in 30 years, but are we creating something new if we say it's just HTML?  What are we adding?
17:31:28 <tzviya> ack Hadrien
17:31:44 <ivan> +1 to Hadrien
17:31:58 <garth> q?
17:32:02 <NickRuffilo> Hadrien: We're inventing the concept of a collection of resources - and saying something about it.  On the web, we just know about resources, but not a collection.  That's pretty much all we're doing.  The rest is based on existing specs.
17:32:03 <NickRuffilo> +q
17:32:04 <NickRuffilo> -q
17:32:05 <NickRuffilo> +1
17:32:06 <tzviya> ack ivan
17:32:48 <bigbluehat> q+
17:32:59 <josh> q+
17:32:59 <tzviya> ack pkra
17:33:01 <NickRuffilo> Ivan: I agree with Hadrien - but it has some practical consequences - which Benjamin called 'affordances' which are based on that concept that Hadrien referred to - that we can continuously go through things - is all based on collection.  Where we are adding somethign new, the only thing is what Hadrien said,, but it has practical consequences that we need to specify to make possible to use.
17:34:13 <NickRuffilo> Peter: I wanted to counter=point the arguments earlier - if you can still read a book from 100 years ago, you cannot read a book 100 years after gutenberg - what you most likely have read is a reprint.  I'm only saying this so that when we think about solutions, we shouldn't think about the current state of the web, but what we expect to provide are solutions to a future.
17:34:22 <tzviya> ack bigbluehat
17:35:50 <NickRuffilo> Benjamin: The things we do with this collection - what do we stick in the format, etc.  Knowing we need a collection of documents is insufficient.  Beyond that is where the devil is in the details.  It gets complicated when we need to go to a browser and ask for things, especially if we don't really know.  For example, the WAM.  One thing it prevents is documents that lie outside of a scope URL,
17:35:50 <NickRuffilo> so you can't make a publication from different URLs.  Some have said it's needed, some have said it's not, but we don't know if it's an issue...
17:35:56 <tzviya> q?
17:35:59 <tzviya> ack josh
17:36:02 <dkaplan3> q+
17:36:35 <bigbluehat> https://w3c.github.io/manifest/#navigation-scope -- any link not "under" a URL, opens outside of the stripped-down browser
17:37:23 <tzviya> ack dkaplan3
17:37:25 <NickRuffilo> Josh: I think we've fallen into the trap to talk about behavior rather than content.  I don't really care what a browser 100 years from now might do, but if we have good descriptive metadata, then leave it up to the browser.  We have use cases, but if we build all these things into the standard - then we can defer all this behavior stuff.  As far as javascript goes, i hope we don't wind up with
17:37:25 <NickRuffilo> something that requires someone to include javascript ot make it work - then we really haven't done our job?
17:37:29 <NickRuffilo> q+
17:37:35 <tzviya> ack dkaplan
17:38:34 <pkra> anyone have a copy of their company website the way it looked this morning?
17:38:35 <garth> q?
17:39:49 <tzviya> q?
17:39:53 <tzviya> ack NickRuffilo
17:39:53 <NickRuffilo> Deborah: I'm an archivist - physical preservation are things that can be recovered.  So much of digital preservation is 'we will never get that back' either media storage, dead links, file formats, etc.  We shouldn't say 'this book isn't readable because of javascript' but we should make the defintion of a readable book is that something is...  In order to read this book you needs a R/G/B
17:39:54 <NickRuffilo> transparency...  Come up with a set of rules that says: 'this is readable and will continue to be readable in 10 years'  How many times have we worked on something fancy that were super-cool but broke because they required a verison of flash that browsers simply stopped supporting...  Write a simple, semantic spec that does not assume publishers are going to go crazy...
17:40:10 <wolfgang> +1 to dkaplan
17:42:05 <wolfgang> s/verison/version/
17:42:05 <ivan> q+
17:42:08 <Bill_Kasdorf> what I'm hearing is that we should specify how to describe and structure a publication in a way that is agnostic as to how a given technology, now or in the future, would render it.
17:42:08 <tzviya> ack ivan
17:42:50 <jbuehler> +1 to agnostic, flexible, clear and simple spec
17:43:43 <dkaplan3> q+
17:43:44 <pkra> q+
17:43:56 <NickRuffilo> Ivan: The problem I have is not technical - lets say we built a completely decorative standard - which defines the usage of HTML, CSS, and whatever.  We do it in a way that it contains all the metadata - then we say 'this is our standard' - it would be great, but it's also our job to ensure it can be and it is implemented.  If it's a standard that no browsers will implement because what we say is
17:43:56 <NickRuffilo> not implementable, then the whole thing is a nice intellectual exercise.  That's the tension we have.  We are fine to do a pure content specification, but we have to make sure it's implementable and implemented.
17:43:59 <dkaplan3> q-
17:44:04 <pkra> q-
17:44:11 <pkra> np
17:45:14 <garth> q+
17:45:21 <pkra> q+
17:45:55 <dkaplan3> q+
17:45:59 <NickRuffilo> Tzviya: As Ivan said - I'd love to write a spec that had just the ideals... One idea that was tossed around - what do people think of the concept of a document that proposes basic HTML, CSS (externalized) and any interactivity be set as external, then we have a polyfill (however it's implemented TBD) so someone writes it - so as a publisher - I put one line of script in my file, and call the
17:45:59 <NickRuffilo> polyfill, and yes, I include the script in every file, but if the User Agent ignores it, fine, but the book can function without the script in the User Agent has ability - but that means it can function with the script.
17:46:01 <tzviya> ack garth
17:46:58 <ivan> q+
17:47:01 <tzviya> ack pkra
17:47:05 <NickRuffilo> Garth: I say no because you go down the path of 'where does the polyfill live' and then 'do publishers need to include that polyfill' before this conversation, the question of there being NO requirements for any JS - and we're closer to agreement on that.  I do think the 1 line is taking happy pilss, but it's a slippery slope
17:47:06 <NickRuffilo> q+
17:48:18 <tzviya> ack dkaplan3
17:48:18 <NickRuffilo> peter: I could see some path, and it could be modular enough - but pushing back against JS is weird as it's something that is part of the web.  At the same time, I find it difficult to image - from a resouce list - as being adopted by the WAM - you just need a service worker - but why should a browser use your caching mechanism...  But i can't see a way without a polyfill...
17:48:24 <Bill_Kasdorf> q+
17:50:23 <tzviya> q?
17:50:27 <tzviya> ack dkaplan
17:51:01 <laurentlemeur> +1 to Deborah
17:51:03 <NickRuffilo> Deborah: I agree to what people say, You should be able to get content without JS.  But, you should be able to add functionality.  We don't want to take functionality away, but I would counter that when it comes to things being basic - such as page turning - right now we're defining a spec, but Tzviya, you have often heard my long rant about one thing we've done wrong is that we have allowed a
17:51:04 <NickRuffilo> ton of functionality that is common to nearly every page still remain as modular (such as menus, and all the javascript).  but, we need to define the limited amount of functionality.  As opposed to every publisher needs to write a polyfill and their own javascript.  But I would want to be in the business to say that 'these features are required'  And what would be a compliant reading system, that
17:51:04 <NickRuffilo> meets those minimums.
17:51:06 <wolfgang> +1 to dkaplan
17:51:09 <jbuehler> +1 dkaplan - its the core functionality that seems to be the question
17:51:24 <tzviya> ack ivan
17:52:41 <Hadrien> q+
17:52:51 <tzviya> ack NickRuffilo
17:52:51 <NickRuffilo> Ivan: Wow, action items...  On this whole issue about scripts added to a publication or not.  I think realistically, we have two possibilities - either we produce ebooks on the web, and for those books to be properly consumed, we ask all the readers to include an extension/polyfill, OR for an intermediate period, the publishers add that type of polyfill - so the user has to do nothing.  At least
17:52:51 <NickRuffilo> for a temporary period - this is the choice.  Ideally I would like that nobody has to do that, but we have to be realistic
17:53:32 <laurentlemeur> third way: between the publisher and the browser, open-source developers create the required polyfills.
17:55:00 <tzviya> ack Bill_Kasdorf
17:55:12 <rkwright> See also   https://readium.firebaseapp.com/?
17:55:39 <garth> q?
17:55:48 <tzviya> ack Hadrien
17:55:52 <NickRuffilo> Bill: Epub is supposed to most use present technologies that works now.  So we're talking about one thing when we're chartered to do 3.
17:57:08 <NickRuffilo> Hadrien: I don't think we need a polyfill or the affordances on every single page of the publication.  We've talked about the web publication address for a user-agent that doesn't know about things.  So the only page that needs the affordances is that page.  We don't need to polyfill the resource of that publication, but the only thing that needs the polyfill for that specific address.  In the
17:57:08 <NickRuffilo> concept of readium, that's the case.  If you have a different link that works in browser, that's great.
17:57:17 <NickRuffilo> Tzviya: you might not even need it in the content.
17:57:27 <Bill_Kasdorf> WP should be the most technology agnostic, adaptable to future developments, EPUB should be the most practical using presently available Web technologies, PWP should be somewhere in the middle.
17:57:42 <josh> q+
17:57:46 <NickRuffilo> Ivan: I don't think - hadrien - that anyone said the polyfill would need to be present in all files.  It can be referred to in the manifest, but only in one place.
17:58:25 <jbuehler> +1 polyfill should not be required to be part of a publication
17:58:26 <NickRuffilo> Tzviya: In these last few minutes, garth is anxious to take this boat...  Do we agree that a polyfill or a script (for rendering of a publication) should not be part of the publication
17:58:27 <dkaplan3> +1
17:58:33 <Bill_Kasdorf> Should not be in WP, but could be in EPUB 4
17:58:35 <josh> +1
17:58:44 <zheng_xu> +1 not required to be part of publication
17:59:00 <NickRuffilo> +1 - no polyfill should be required to be included in a publication for the publicaiton to be read
17:59:06 <NickRuffilo> q+
17:59:39 <david_stroup> +1 - not required
17:59:56 <laudrain> +1 to Nick
18:00:24 <wolfgang> +1 to Nick
18:00:27 <baldurbjarnason> +0 I have no idea. Too early to tell. Depends a lot on what pathways browser vendors are interested in taking for publication support.
18:00:53 <duga> +0, echo baldurbjarnason
18:01:03 <ivan> present+ baldurbjarnason
18:01:19 <tzviya> https://github.com/w3c/wpub/pull/130
18:02:12 <NickRuffilo> Ivan: the first question is whether it is good enough to be merged into the main document - if it's a good direction for the pull request to be merged.  Maybe we can agree by the end of the week via email.  There is a much smaller pull request on internationalization.
18:02:15 <NickRuffilo> q-
18:02:24 <zheng_xu> zheng_xu has left #pwg
18:02:29 <cmaden2> cmaden2 has left #pwg
18:02:35 <dkaplan3> dkaplan3 has left #pwg
18:02:42 <BenWaltersMS> BenWaltersMS has left #pwg
18:02:48 <MustLazMS> MustLazMS has left #pwg
18:02:58 <evan> evan has left #pwg
18:03:06 <ivan> rrsagent, draft minutes
18:03:06 <RRSAgent> I have made the request to generate https://www.w3.org/2018/02/05-pwg-minutes.html ivan