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:

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