PWG Weekly Telco — Minutes
Date: 2018-09-17
See also the Agenda and the IRC Log
Attendees
Present: Chris Maden, Romain Deltour, Jeff Buehler, Avneesh Singh, Franco Alvarado, Wendy Reid, Benjamin Young, Nick Ruffilo, George Kerscher, Jun Gamou, Deborah Kaplan, Teenya Franklin, Gregorio Pellegrino, Hadrien Gardeur, Ric Wright, Ben Schroeter, Bill Kasdorf, Lillian Sullam, Juan Corona, Charles LaPierre, Joshua Pyle, David Stroup, Mustapha Lazrek, Marisa DeMeglio, Brady Duga, Rachel Comerford, JeanKap, Derek Jackson, Tim Cole, Karen Myers, Evan Owens
Regrets: Ivan Herman, Dave Cramer, Luc Audrain, Laurent LeMeur, , Garth Conboy
Guests:
Chair: Tzviya Siegman
Scribe(s): Benjamin Young
Content:
- 1. reviewing the agenda
- 2. Issue Review
- 3. New GitHub Project
- 4. primary entry page must be added to reading order when reading order not specified
- 5. WP rendering in non-WP Aware browsers https://github.com/w3c/wpub/issues/271
- 6. TPAC agenda
Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-09-10-pwg
Tzviya Siegman: wecome everyone
1. reviewing the agenda
Tzviya Siegman: any objections? no. great. minutes approved
… someone pointed out that last week there was some confusion about the incubation topic
… and that there was desire to continue that discussion
… can someone clarify the discussion around incubation from last week?
Benjamin Young: it was a very brief end of meeting discussion, so not much said yet.
Tzviya Siegman: k. let me give an overview then
Tzviya Siegman: https://discourse.wicg.io/
Tzviya Siegman: the Web Incubation Community Group was setup as a formal place to incubate ideas
… toss around ideas, discuss them, and point to exploration projects, etc.
… other WG’s have done this differently
… for instance the Web Annotation WG started out as the Open Annotation Community Group
… some of them are more scattered like the Web Payments WG and their related CGs
… so there are a few different models for this
… we have a lot of great ideas that have been discuss here
… but as yet there’s not an incubation location to explore them further
… we’ve talked about some of those explorations here, but they’ve not really been given a place to continue
… and that’s what we’re exploring here
… perhaps that’s not another CG, but we do want some area where we more formally incubate them
… and when they reach greater maturity, and then present them to the WG
… I recognize some people are reluctant to using the WICG as it’s wide open to the public and not always focused on a single topic
… any thoughts?
Tzviya Siegman: the goal of this is to have folks interested in exploring implementations and related ideas, this gives them a home
… if we say WICG is the home, are there objections?
George Kerscher: are the threads segmented there?
… or do you get sucked into a massive amount of other things being incubated
… how easy is it to track work there?
Tzviya Siegman: there is a tag and a dpub label
Benjamin Young: https://discourse.wicg.io/search?q=dpub
JeanKap: yes. It’s a threaded forum conversation
Tzviya Siegman: if I remember correctly, you can follow specific labels
… I’d suggest we start with the WICG
JeanKap: It’s a dicourse forum. you can turn email on and off.
Tzviya Siegman: it does generate a lot of email
… but you can subscribe to a specific topic
… JeanKap I think the question is can you track a single label
JeanKap: you can do one label too, I believe.
Benjamin Young: I’d prefer a CG mapped to a WG–similar to JSON-LD CG & WG or the Open Annotation CG & WG
Tzviya Siegman: there are political reasons we might want to start with the WICG and then possibly consider a CG
… we could then consider other options
JeanKap: I’d echo that. Starting with the WICG means its already up and running
… if there are limitations to it or people have trouble participating there, then we could consider something else
… but all of this is public
… so that shouldn’t be a decider
Deborah Kaplan: I’m in favor of the WICG option. However, we’ve already got a massive list of places we have to look
… and we’re already in a state where very few WG memebers are actually involved in these places
… I’m not sure yet-another-place is going to improve that situation
… while I see the need, I think we need to also look at solving how to get the folks less active/interested into the activity
… more noise doesn’t seem to be the solution
Tzviya Siegman: I’m hearing that folks aren’t keen on the WICG
… what do you think about a GitHub repo under w3c?
Deborah Kaplan: My point is less “don’t do WICG” and more ‘once we open any extra communication channel, we need to be doing a better job of encouraging the quiet folks to participate in the channels we have.’
Benjamin Young: CG’s do get repos automatically, fwiw.
Deborah Kaplan: and I am happy with a new repo
Benjamin Young: plus it could attrack new implementer interest, etc.
Tzviya Siegman: would another WG related GitHub repo work?
… we’re not going to make a CG right now, but perhaps just another repo is sufficient
… thank you for that discussion. let’s get back to the planned agenda
2. Issue Review
Tzviya Siegman: https://github.com/w3c/wpub/pull/331
Tzviya Siegman: for some of this I used Rachel’s format–which is very helpful
… but for some of them I did not
Tzviya Siegman: https://github.com/w3c/wpub/issues/325
Tzviya Siegman: please take a look at these issues and make sure you’re OK with them
… sometimes I get the sense that no one looks at these.
… PR 331 is “title element is a MUST for embedded manifests”
Gregorio Pellegrino: for me ok
Hadrien Gardeur: -1
Tzviya Siegman: anyone have objections on this one? or even know what this is about?
… Hadrien what’s your -1 about?
Hadrien Gardeur: if it’s the issue I’m thinking about, then I’ve already explained why I’m against it
Tzviya Siegman: then how should we move forward?
Hadrien Gardeur: I don’t think we should close it because there isn’t resolution
Tzviya Siegman: so… ivan’s comment about getting title via a fallback…is that not sufficient?
Hadrien Gardeur: if you look a few comments above that, I’ve already written why I think that’s not ideal
… forcing the fallback pretty much defeats the purpose of having the title being not required in the infoset
… a lot of the time we’ll be getting information that’s not meant to be the title of the publication
… I believe we’re conflating the entry page with the publication itself
… we’ve had similar discussion before.
… we’re using info that not clearly about the publication as if it were meant for the publication
Tzviya Siegman: could you write up your alternative?
Hadrien Gardeur: I believe I already have.
Tzviya Siegman: could you write it as a resolution to the discussion?
Hadrien Gardeur: ok
Tzviya Siegman: I’m realizing I skipped the first item on the agenda
3. New GitHub Project
Tzviya Siegman: https://github.com/w3c/wpub/projects/4
Tzviya Siegman: we’ve started using a project structure
… thanks to Rob Sanders from the JSON-LD WG for pioneering this
… we’ve started curating our issues lists in this project
… it should help give a sense about when things will be explored, etc.
… we may also introduce “propose-closing” as a label or a column
… and the plan is to use this project to further structure our calls going forward
4. primary entry page must be added to reading order when reading order not specified
Benjamin Young: https://github.com/w3c/wpub/issues/334
Tzviya Siegman: so this is closely related to the PR 331 which Hadrien was objecting to earlier
… I believe Matt’s comment was just that was clarification needed, but otherwise this was ready
… are there any other objections to this?
… no? k. I’ll put the editorial label on this, and leave it for Matt to complete
5. WP rendering in non-WP Aware browsers https://github.com/w3c/wpub/issues/271
Tzviya Siegman: https://github.com/w3c/wpub/issues/271
Tzviya Siegman: I did summarize this issue https://github.com/w3c/wpub/issues/271#issuecomment-422052891
… please take a moment to digest this, and we’ll discuss it
Deborah Kaplan: just to clarify, what is the exact topic of discussion that you want to have happen in the call?
Tzviya Siegman: basically, we have things in the current spec that require things beyond today’s browsers
… but what happens when you open this in a non-WP aware browser?
… what is the minimum to provide a useable and accessible publication that works in a browser today (which is non-WP aware)
… basically, how can we focus on building this progressively?
Avneesh Singh: basically, what we’re proposing is a WP that could work in any kind of browser without any additional scripts
… that may be some years away
… but what we’d like in the meantime is that a non-WP aware browser should still be able to read them
… the proposal is to ensure that nothing in the specification development prevents the expression of a usable and accessible publication for use today
Hadrien Gardeur: I feel it’s difficult to address these things at the spec level
… some of this might fit better in a best practice document
… rather than the spec itself
… although we want to provide accessible publication
… this may still be something better put in best practices rather than in the spec
Tzviya Siegman: this gets to the heart of one of the things we continue to discuss, but haven’t decided
… what must a user agent do and what type of user agent must be used to read them
Hadrien Gardeur: this is the sort of push back we get whenever we try and restrain HTML
… and I expect the same sort of push back if we suggest some sort of template
Avneesh Singh: the idea was to make non-WP aware friendly Web Publication which is accessible
… it’s meant to be a precaution to avoid WP’s that only work in a future WP-aware browser
Deborah Kaplan: it doesn’t due the conversation a service to think about real edge cases
… HTML has always allowed people to do things like require certain fonts for rendering
… there’s no rule in HTML that says that what’s produced in it will be usable by everyone
… I think Avneesh’s concerns are bigger than accessibility
… it’s never been possible to meaningfully force actually accessible documents…you just can’t
… like meangingful alt text…for example.
… something we can enforce is making sure that a WP can still be viewable in a non-WP aware browser
… like making sure you can at least get to the Table of Contents
… you can absolutely enforce that via the spec
… folks will certain break that, and do all kinds of random things, or make it only work in a single reading system
… none of that is new
… but I don’t think we would try to police that
Joshua Pyle: I tend to agree with dkaplan3 and Hadrien and all
… that we may not be able to demand that a WP would always be a progressive enhancement from a Web Page
… but I think it is a practical consideration for how this will work now, today
… like a WP should work in today’s browser
… or to state that in some sort of non-normative–you’re a fool if you don’t make this work
… I’m not sure how to do this from a pure specification writing perspective
… but I can’t imagine why someone wouldn’t want them to work in non-WP aware browsers
Tim Cole: I believe I agree generally, but I’m a little concerned about the tenor of the discussion
… there should be something that makes it clear that these aren’t just a collection of normal web pages
… when you open it, you should see something, and it should be usable
… but we should also say what’s different between a web publication and the rest of the web pages on the web
… and there will be sometime in the future where people will want these additional things
… and developers will start to take advantage of these things in their publications
… we should be careful, then, what things are WP-specific
Tzviya Siegman: I think makes an excellent point
… what steps are required, then, to make a non-WP aware browser become a WP-aware one
Brady Duga: I agree with timCole. I believe this goes beyond what the browser/readers will do
… you will want these to be usable in a non-WP aware user agent
… I might put next/prev and up to ToC links in all the pages
… when I now view them in a WP-aware browser, I’d really not want to see those on ever page
… because presumably the WP-aware reader would provide those features
… what things then do we provide authors to make them work in a non-WP aware UA, but will still look good in a WP-aware one
George Kerscher: it seems to me that there is one item that is essential here
… and that’s the Table of Contents
… in an unaware browser, once you leave the ToC, you can’t necessarily get back to it
… say you have a collection of materials, and they’re reused all over the place
… so you can’t link back to that ToC from those because those materials are used in several publications for example
Bill Kasdorf: +1 to George: that’s a fundamental thing that distinguishes a publication from a web page
George Kerscher: I don’t know what we can do beyond saying “bookmark this ToC” so you can return to the publication
Benjamin Young: +1 George
Avneesh Singh: I think we’re all roughly discussing the same thing
… the ToC, as George mentioned, is the center piece, and then the ability to move next and previous through the items of the publication and then back to the ToC
… there are already many discussions around requirements for non-WP aware browsers
Deborah Kaplan: what people are saying is alright
… but I don’t think we’re the first people to discuss this
… these are the basic principles of progressive enhancement
… here are some examples–I know I’m not the only person who does these things
… if I use elinks, I may also use wget, curl, Opera 12, and Sumatra PDF
… these all have varying funcationality
… sometimes if you want something newer, you have to use a newer tool
… progressive enhancement says, do we make content if this JS doesn’t work
… and people who make tools who don’t allow the JS to work, deal with that reality
… the process is content and tool creators decided if they want to write for less, full-featured tools
… and users deciding if they want to use more full featured tools or not
Hadrien Gardeur: the difference is that we’re talking about progressive enhancement for a complete (currently “non standard”) rendering mode, not a single feature/API
Deborah Kaplan: like Avneesh was saying, we need to define what will happen in a non-WP UA
… it may be that you can’t get to parts of the publications
… or maybe you’ll do it the other way and write script to hide non-WP content from WP UAs
Tzviya Siegman: I see Hadrien disagrees with this fundamentally
… I think this gets to the core, underlying reason that we disagree about how we approach this spec
… some of us believe that we can take the same approach as progressive web apps
… while others believe we’re building a new rendering/reading mode
… something from what timCole said, is if you open a WP in a non-WP aware browser, the following will happen
… however, if you do the same thing in a WP-aware UA, then the following will happen
Deborah Kaplan: what Tzviya just said plus a gazillion.
Tzviya Siegman: so we’re talking about both worlds
Hadrien Gardeur: if we’re truly creating “progressive enhancements” then we’re writing our spec the wrong way, we should divide it into individual features
Tzviya Siegman: both the present as it is today, and what we want from UAs in the future
… these sorts of publications exist today
… plus things provided in an additional reading layer
… we need to define what “WP-aware” means
Joshua Pyle: I just wanted to second, third, and forth what you just said about not having done a very good job explaining what we get from WP
… as you know tzviya I’ve just started trying to convince my employer on what this is
Tzviya Siegman: because we don’t know
Joshua Pyle: it’s like…some meta data on a web page
… I’d appreciate some help trying to explain and sell what this thing is
… having said that, I’m also very interest in hearing an answer to what we’re building here
Tzviya Siegman: since no one else is on the queue, I’ll try and sum it up
… remember timCole’s annotations work from earlier in this group
… I’d like addressibility
Deborah Kaplan: if we’re talking about what a WP-aware browser means
… I’d like to say that everything that all of this can be done without polyfills
Tzviya Siegman: so what would those polyfills be accomplishing?
Deborah Kaplan: whatever that list of things that we say are WP-aware UA features must be done by the UA for it to be considered a WP-aware browser
Avneesh Singh: packaging, offlining, accessibility enhancements like annotations, bookmarking, highlighting. these all go beyond today’s browsers. These can be identified from use case document.
Tzviya Siegman: I do think many of these features are documented in the use case document
Joshua Pyle: I’m not doing well with it at the moment as my focus has been on an implementation
… because part of the sales job is to show what this is and what value you get
… what Avneesh just said about packaging, this is what I get back from my management is EPUB4
… that’s all they want is EPUB4
Tzviya Siegman: this is a good segway to the agenda at TPAC
6. TPAC agenda
Tzviya Siegman: https://docs.google.com/document/d/1Mt9PTcOdmrCwIsgfxbGMGjwHlUsySU01I0D4oBkSbcA/edit?usp=sharing
Tzviya Siegman: on Monday we have half a day on EPUB4
… please let us know if there is anything we’re missing on the agenda
Avneesh Singh: I think marisa had mentioned wanting to discuss synchronized media
… as well as other talks with other groups
Tzviya Siegman: as far as the synchronized media group goes, the last updates were from TPAC from last year
Marisa DeMeglio: we’re just about to ping the group again after having done some research, and we’re going to wake them up this week
Tzviya Siegman: I have a note that with the APA meeting, at 2:30
… and that they’re including synchronized media also
… is that the same discussion?
Marisa DeMeglio: they might have a broader take on it
… I’ve talked to them a bit
Tzviya Siegman: how much time would you like for this?
Marisa DeMeglio: it doesn’t need to take too long. maybe 30 minutes?
Tzviya Siegman: hopefully. we haven’t gotten any requests for incubation and demos
… jbuehler sent around his table of contents
… but I’ll put you marisa in there–which is tuesday morning
… Avneesh as far as APA we’ll try and leave that up to others to decide
Tzviya Siegman: one other thing. we’ve launched the fund raiser for epubcheck
… here’s the link
Tzviya Siegman: https://www.w3.org/publishing/epubcheck_fundraising
Tzviya Siegman: thank you to everyone at Daisy for helping make this happen
… I’m out the next two weeks, but you’ll be in good hands