# DPUB IG F2F first day, 2015-10-29, Sapporo

Agenda

## Attendees

Present
Charles LaPierre, Tzviya Siegman, Vlad Levantovsky, Dave Cramer, Karen Myers, Rob Sanderson (azaroth), Heather Flanagan, Liam Quin,  Jeff Xu, Bert Bos, Chris Lilley,  Peter Linss, Ivan Herman, Shinyu Murakami, Johannes Wilm, Benjamin Young, Markus Gylling, Ted O'Connor, Florian Rivoal, Brady Duga
Guests
Lars Svensson (LarsG), Daniel Glazman (glazou), myles, csarven, Richard Ishida, Lea Verou, Taketoshi, Yamane, fantasai,  Rossen, Dean Jackson, David Baron, Daniel Weck, Jake Archibald, Judy Brewer, Bobby Tung, Ben Whittam Smith, Steve Zilles, Takao Baba
Regrets

Chair
Tzviya
Scribe
liam, dauwe, karen, chris, azaroth, glazou

## Contents

### Intro

tzviya: let's get started
... intros first

tzviya Sigman, co-chair DPUB

Dave Cramer, Hachette, and also CSS WG

Murakami-san, Vivliostyle

Jeff Xu, Kobo

Charles Lapierre, Benetech

Daniel Glazman, Disruptive Innovations, ex-cochair CSS WG, BlueGriffon author

Lars Svensson, german national library

Karen Myers, W3C Staff

Bobby Tung

<Bobby> Bobby Tung, invited Expert

Liam Quin, W3C

Florian Rivoal, Vivliostyle

Myles Maxfield, Apple

<tzviya> rob sanderson, stanford University

<dauwhe> Benjamin Young, Hypothesis

<azaroth> Rob Sanderson, Stanford University, co-chair of Annotation WG, editor of annotation use cases doc for DPUB

<Karen> Ben Whittam Smith

<tzviya> Ben Whittman-Smith, thomson Reuters

Ted O'Connor

(apple)

Judy Brewer, A11Y

Johannes Wilm

<baba> Takao Baba, BPS.

Heather Flanagan

Ivan Hermann

and Markus Gylling, IDPF and DAISY

(digression about the timbl speech-rate unit)

### Summary of current work

tzviya: Markus already knows what we deal with, we can move on
... summary of current work
... what we want to accomplish in near future
... don't want to speak alone
... use the queue
... I put together some notes in last 10 minutes
... we rechartered and shifted focus
... we're an IG, we publish notes
... Portable Web Publications published

<dauwhe> http://w3c.github.io/dpub-pwp/

tzviya: EPUB+WEB
... we want to have ability to have pubs available online AND offline
... almost at full functionality of the web
... right now, most ebooks don't have web-level functionality
... no URI to a book or to resources in a book
... only ISBN

tzviya: CSS functions in limited capacity
... searching is limited too
... we also want good offline experience like archiving
... there's a premium focus on a11y in the epub world
... not sure everyone here is familiar with EPUB
... EPUB is the format of the IDPF
... primary format of ebooks today
... Amazon Kindle does not use EPUB but take it as an input format
... this is main focus of PWP
... so many things have to happen to have offline/online equivalent
... for now, it's mostly an offline package
... we want to improve that experience
... CSS there's been a lot of work there, dauwhe being the liaison
... has published some modules like GCPM
... thousand of years of print typography not represented in CSS right now
... we'd like that to happen too
... html+CSS to be used for print requires more work in CSS

(mgylling on phone now)

(tzviya summarizes for mgylling )

tzviya: dauwhe added a method for initial letters for instance

dauwhe: "drop caps" is the right term

tzviya: another area is our FPWD publishing module of ARIA
... publishing has a lot of things there, chapters, glossaries, etc.
... in EPUB world, we have some old XML-based vocabularies 200 elements
... need a way to express these terms
... in the html world
... we spent a lot of time looking for a way to do that well
... how can we declare a given element is this or that?
... so FPWD now
... cleanup to do, already reviewed

tzviya: formal review period done
... second WD soon
... questions?

ivan: maybe one comment
... we always refer to EPUB but everything we do is for publications in general and not only EPUB
... we hit a project in italy that uses a profile of html
... they use the same ARIA terms we defined
... that's good, exactly what we want
... publications in general

tzviya: good point, thanks
... similar example in US
... ok, we have an a11y TF
... doing a lot of work despite not lot of output
... longdesc for instance
... affects significantly publishing community
... all students need to access content equally for instance
... our a11y TF researching with the ARIA people about that

Judy: thank you tzviya for mentioning that joint activity
... something we try to get right
... the general case we try to help is extended type desc for *complex* image types
... originally dpub's request was to piggy-back this on the longdesc feature that was restored to html5 by extension
... not well supported by browsers
... trying to evolve that into new ARIA feature, describedAt
... but same architectural concerns
... we were able to get more interest in one of Apple's proposed solution, details than previous efforts
... more interest this time but still lacking browser interest and implems
... yesterday we had confirmation it's coming from MSFT and Moz
... so thanks DPUB

clapierre: let me mention those descriptions are not only for images but any element
... can be also a file representation and not only a description
... multiple things can be attached to a single element
... may have to add things to details

Judy: my understanding is that it's looking pretty good
... some groups want to add more complexity to details

tzviya: other things we're exploring
... (list minute taker did not get)
... lot of exploratory work
... future of mathml on web and maths in general
... lot of work in coming year from this work
... another clear area is identifiers
... big issue with PWP is idents
... and fragment idents

ivan: one of first work we did was collect use cases for annotations
... separate note published a year ago
... very important for educational world

<tzviya> annotation use cases: http://www.w3.org/TR/dpub-annotation-uc/

ivan: what happened there after publication, we established a separate WG on annotations
... not part of this IG any more
... first spin-off from here
... we also published a year ago another note on metadata
... enormous importance for publishing world
... whole biz workflow relies on enormous amounts of metadata
... we try to understand if there are issues around W3C tech
... so series of interviews with different people in this are (~15)
... to get an overview

ivan: two interesting outcome
... what we have at W3C for metadata is perfectly adequate for pub industry
... they have major problems with vocabularies
... but we decided it's not something for W3C
... not the right org for that
... there are orgs out there better adapted to that work
... second outcome, there is a need for standard language for right management and rights expression
... we're in the process now to look if we should start a WG about that
... breakout session about that yesterday
... this IG has some influence
... mgylling anything we forgot ?

Florian: wrt STEM (sp?) math exploration
... CSS has the Houdini TF to explore low-level primitives that can help
... one thing on radar is maths
... not high priority for browser vendors
... being in touch with Houdini TF would be a good idea

ivan: current liaison comes from mathjax
... not impersonating Peter, mathjax is looking at th whole platform
... we have given hope on implementing of mathml by browser vendors
... but reality is that
... not happened in years and years
... approach they're looking at is creating a layer on client-side based on html and css
... down-side is that mathml a11y is forgotten a bit
... mathml module with ARIA to bridge the gaps
... industry has been longing for mathml implementations forever
... just did not happen the way we wanted

Florian: I'm afraid I share those concerns
... unlikely to happen
... houdini is not about mathml
... but primitives that would help
... we'll see if it reaches success

ivan: mathjax looks at that too
... pages rendered with mathjax are slow

tzviya: reach out to Peter

Karen: I've a question and a comment
... question is what type profile people would be useful for houdini ?

glazou: houdini tf is something we've needed forever
... the rendering engines are pretty open on the upper layers
... and have been black boxes at low level
... which prevents us from prototyping new stuff
... when you have a layout polyfill
... you can't do that without reaching the rendering engine
... something like MathML need such primitives to create the specific rendering
... which is not the normal html rendering
... houdini is not specifically about these other languages like MathML
... the implementors may not have the right knowledge of what could be done with houdini
... so the best thing is to bring them use cases and feedback
... the mathjax community looking at houdini is excellent
... but we need more data

tzviya: they're publishing a white paper

glazou: any strong expression of interest will help
... houdini is not one doc
... it's lots of different things
... parser, the box tree, painting...
... we are in exploration mode with some authoring of specs
... any input is good input
... if publishing needs, if math needs, and we're aware
... I agree Houdini TF is not visible enough
... maybe you can help
... input input input requirements (x3)

Florian: agree with what daniel said
... because we are exploring
... in person input is effective
... being around the whiteboard
... is important

tzviya: so we need updates from houdini
... houdini itself is a black box
... we need more info from then on how to get involved

glazou: well taken

tzviya: florian can help

SteveZ: houdini is amorphous
... it's a bunch of different things
... and it's very informal
... so even csswg folks don't have a good idea of what's going on

johannes: there are meetings
... we need people who implement stuff
... Peter could show that I couldn't put this charatcter there because reasons

tzviya: ivan reminded me that Dave, with input from the IG, put together a CSS priorities list

glazou: one more bit of info
... houdini started as corridor conversation during tpac last year
... there was strong interest by some individuals in browser vendors
... then the vendors realized it was a good thing
... but not all vendors are interested in all parts
... moz could be seen as reluctant to suppy access to the frame tree

tzviya: but they support math, so we good

glazou: but there are many other things like music
... hard to express with regular box model
... you have books about music

tzviya: we have a member from Note Flight

glazou: input from potential customers does matter

Dauwhe: You mentioned it's helpful to provide feedback to Houdini standing around the white board

...there are some challenges to that

..those are by people who are writing the rendering and layout code

...There are not that many people in the world who understand that

....So some challenges of many levels of translation

...to get to the language we want inside the renderers

Daniel: We have same problem in CSS WG

...problem of making web designers and CSS developers, implementers discuss because we don't speak the same language

...An industry that reaches out with this message

...the current languages of the web are not enough; we need an extension of that

...will be a good enough message

florian: if we have people who have been implementing polyfills

... these people are sufficiently technical to engage with houdini devs

<Zakim> liam, you wanted to note performance

... they can understand the problem and the white board

liam: some of the proposed apis could math mathjax massively faster

... since you don't have to create lots of extra DOM elements

.. although it sounds like it's adding more scripting

... it's eliminating other scripting

glazou: something that karen could do

... is like the industry meet-up

... could be houdini meet-up with industry(s)

... who are interested in extending the rendering

Karen: when is the next F2F

glazou: next is in Sydney

SteveZ: but there will be one in May in the US

glazou: yes, that will be easier

<Florian> Sidney early february

ivan: peter won't go to australia

<Florian> US west coast early may

tzviya: let's take logistics offline

... what is it

glazou: it's a joint task force between CSSWG or TAG

glazou: and we can liase

Florian: just show up

<myles> Houdini

glazou: observing houdini meeting is likely OK

jeff_xu: we are often patching rendering engine

... we are likely to explore features useful for epub

... if we can convince browser engine to implement low layer

... so we can implement high layer on top

... we can cooperate more with browser vendors

ivan: to close this discussion

... mathjax should have this white paper out

... it's not on houdini

... it's on the future strategy of mathjax as organization

... that will help with discussion

tzviya: coming pack to DPUB

... i'm finding it interesting that the only thing that generated conversation was intersection of math and CSS

ivan: i see two areas that will generate lots of tech discussion

... one is identifiers

... and how they fit into web architecture

... the other area which is exciting is on borderline of magic and mystery

... the generic architecture for portable web publications is based on heavy use of service workers

... they carry the magic to hide difference between online and offline

... as well as between packaged and unpackaged

... we had a discussion last week with jake archibald

... and our needs are in line with what that community is looking

... at

... but non-trivial

... these are the two areas where we can have quite some discussions

tzviya: I think so too

... is everyone eager for coffee?

Tzviya: Everyone say hi to Markus

Everyone: Hi Markus

Markus: Hi!

### IDPF's EPUB3.1 Working Group

tzviya: Shares projection of static
... [Epub 3.1]
... We talked about EPUB in he last session. You may have noticed some overlap, so good idea to tell you about what's happening in the IDPF
... In the past few months IDPF has started EPUB 3.1, the first major revision of EPUB 3
... Dave and I are working on that. Markus is the CTO of IDPF
... He doesn't sleep
... I co-chair that group with Markus
... Dave is actively involved, so we're going to do an overview
... I apologize for the ugliness of the slides
... This does not reflect on Dave's ability to make beautiful slides
... So. [Formal Work Plan slide]
... Formal work plan is at the link. (Link Plz) Based on a request to IDPF membership for what they want to see
... Boiled down the pages and pages into a few areas
... IDPF has main specs and satellite ones. Some confusion as to what goes hwere. Requests to consolidate and simplify
... A few different ways to implement scripting.
... A lot of OWP alignment, some of which from this group, but also from dig pub world
... Plus limited set of new features
... EPUB is widely adopted. 3 was published in 2011. A huge change from 2. Took a long time to shift, some publishers still haven't shifted
... Intended to be backwards compatible, but not everyone has taken advantage of this
... Not being backwards compatible would crash the industry, so people wouldn't do it
... Hope to have WD in January

dauwhe: Thankfully not holidays before then ;)

tzviya: Good that there are multiple religions :)

glazou: Comment on adding scripting to reading agents. In EPUB world there are so many profiles of web specs with restrictions and additions
... Afraid that there will be restrictions in what readers will accept
... And extensions would be worse.
... I expect there will be strong resistance to this from rendering engine vendors
... If scripting is added to readers, it must be full scripting. All of it. Period. If not it's doomed to fail
... Saw such restrictions in Florian and it didn't work
... No editors able to handle it, and authors won't look at hte spec to see what can be done or not
... Second comment: schedule. Don't laugh yet. One of the biggest issues for epub 3.0 was the speed of delivery. Was written and reviewed and delivered quite fast
... so a LOT of bugs remained in the spec. Ones that no one noticed. No errata, and some made it almost unimplementable
... so huge that it made the spec useless from some points of view
... Here we have FPWD in Jan, and Rec in October, so no tests and a process that will be faster than 3.0
... Very concerning.
... I don't think this is reasonable.

tzviya: We didn't show you the rest of the slides yet. Markus?

mgylling: Finish the slides

Florian: I just wanted to know if you plan to speak about * on backwards compatible

dauwhe: Lets do that later
... There's only 10 subgroups, so very manageable
... There were more, we closed one that distributed its requirements to other groups
... Metadata is a big one. Some people have opinions about how it works.
... The reality of the industry is that most md is handled externally, and the least MD inside the package the better
... no process for fixing it inside the epub
... So looking at links to external records
... Browser-friendly manifestation. If you open it in a browser, it just downloads the file
... some RS unzips the bundle, so more useful for garden browsers. Exploring exploded Epubs
... for browsers that dont' support EPUB manipulations. Big, controversial group. Source of some of the *.

dauwhe: Serialization -- should we allow html5 in epub? half the people in the room have HTML5 stickers. Huge potential change.
... accept both serializations, but not mandating support for HTML serialization
... More *, so OWP alignment, this is the big issue
... Lots of issues around scripting
... Restructuring the specs themselves. People who wrote them are confused.
... Matt Garish working on reorg of the specs.

tzviya: Matt Garish is wonderful

dauwhe: A11Y subgroup. Metadata into EPUB for assistive technology
... to make better choices about what content there is
... Consolidation - possibility of umbrella spec that links to the specs that comprise css3

Florian: similar to CSS snapshot? Could it be?

ivan: I don't think that it's a fair comparison
... The various epub docs are stable documents. Snapshot is because there should be a new one every year, it evolves

dauwhe: There's a subgroup looking at more core media types to epub. Want a 3d type, but there don't seem to be any [or too many]
... also csv files, scientific data

ivan: One of hte things that came up, scientific pubs want to include csv data as part of the book
... currently a list of types that are allowed and shouldn't be

tzviya: Q about what we mean by media types
... what we mean is that epub restricts the type of files allowed inside the package

tzviya: XHTML is allowed, CSS is, fonts, etc. are called core media types
... Right now you can't just throw any sort of file in to the package. Requests to expand the list
... so you don't have to point out of the file

Chris: A whitelist of media types

dauwhe: Yes, or one that doesn't require a fallback
... there's a css group that hasn't started yet. Currently have a list of properties that are allowed, wonder if there's a better way giving the changing nature of the css landscape
... and everyone's favorite subgroup, deprecatable elements

LarsG: Want to ask about the metadata. Interested in consuming it. Are there libraries represented in the EPUB WG?

tzviya: If only. Generally the MD is split between supply chain and library/bib metadata. Lots of input from supply chain, none from the library side

LarsG: Work with onix, which works, but issues with vocabularies.

<Zakim> LarsG, you wanted to ask if libraries (which) are discussion metadata

LarsG: will take it home and see if there can be something done

glazou: A comment on number 10. Deprecation doesn't work. Will never work.

tzviya: We know that if we deprecate something, it needs to be replaced with something else

dauwhe: Or if there are things that were never implemented

Chris: that's just killing it then

glazou: Deprecate means SHOULD NOT use it
... and that UAs MUST support it still
... when people can do something, they'll abuse it.
... everything relies on the validator, if it's just a warning that's not enough, needs to be an error
... so don't deprecate things, just remove them or leave them

tzviya: Daniel likes the death sentence

HeatherF: Library community concern, member of special libraries association, can try to help bridge

tzviya: Let's talk about EPUB and DPUB
... alignment with OWP is a major goal
... Have been working on browser friendly manifestation. Major step towards portable web pubs
... some big issues to solve. Largest are identifier for the package, and for the components and subcomponents. Some form of a fragment ID
... need to talk about serialization
... if we shift away from XHTML, lots of XML vocabs
... SMIL, many others. Would need to replace them. A11y is dependent on XML
... working with ARIA, would need to explore working with other groups
... implemented perhaps exclusively in EPUB

Chris: Is that full SMIL, not just animation?

tzviya: Not dropping it in 3.1

ivan: I don't remember the details, but I don't think it's full SMIL

Chris: Could replace with CSS anims?

ivan: there's a switch from SMIL that can't work with CSS. Used in practice, I don't know

dauwhe: Short term issue is that there's some NS vocabs, lexicons, that we need replacements for in HTML serialization
... full SMIL is OWP alignment, and out of scope for 3.1
... last slide. Aggressive time line. Have to finish DPUB work soon.
... identifier schemes might be dependent on Anno WG
... conversation?

Steve: Wanted to +1 daniel's point about schedule
... and lack of ability for testing
... or even comparing alternate implementations
... CSS began with a reasonable set of things. Not all got implemented. CSS2 is the second generation -- put in everything that didn't get to v1
... catch was that implementations would sample from the space, and wouldn't consistently implement across the space
... took 7 years to get to 2.1 subset
... importantly an interoperable subset
... much more precisely tested subset
... without interop, specs are dangerous
... they break features. Had to give up on some because they're not interoperable [or implementable]
... so dont' take lightly the comment about the insane schedule
... they want results, but results that work.
... CSS 2 example of spec that didn't work

tzviya: Will say that we're in early days and not commited to everything on the list
... may decide that it's not feasible to do some things
... will explore it tho
... might kill more subgroups

SteveZ: Restructuring, but only one group for removal, but none that say interoperable
... that's the piece I think you're missing
... How do you ensure what's in 3 is interoperable across implementations

glazou: second what SteveZ said
... don't know the exact meaning of restructuring or details of work, but seems that there are high level issues that should be fixed before that
... main one is editorial work
... 3.0 suffer from severe editorial problems
... need to navigate between docs all the time

ivan: That's the subgroup

glazou: also the vocab used to describe features is poor

tzviya: feedback welcome

glazou: spine? landmark? if you're not english speaker you're doomed
... rewritten by tech writer, not an implementer
... inside or outside the group, but something that's readable
... tech work in 3.1 is unrealistic. will end up with issues
... 3.0.1 there's a link to dev.w3.org
... how is that possible? no link checker?
... a spec linking to an unstable doc that can change overnight
... do we want to replicate this by working too fast?
... would accept a 3 year schedule, but 9 months... wow.

ivan: different things
... lets realize that this is work done in another organization
... so lets not bash them please
... not our responsibility, we can have an opinion, but lets not go too far
... Schizophrenic, because part of the IDPF WG too.
... Need to look at how this IG can help the IDPF WG process for 3.1 or after
... start with draft from last week, looks at lots of general things
... a number of things there for good reasons because the industry needs it
... SMIL adopted because of a need for that
... not really adopted at large outside of publishers
... so something has to be done to replace it
... CSS animation works for some, need to find for others

... in process of doing that for IDPF, if we identify issues and problems that can't be changed in 3.1, but could flag it as longterm needing solutions
...
all those issues should come to this group for further work
... as we're closer to the OWP issues
... a systematic listing of the issues. may come up in subgroups now, or later

tzviya: a good point. if the schedule needs to be reviewed, then that's the place for it
... here is what's relevant to the W3C, not scheduling
... if you want to join the EPUB WG, that would be great
... should talk about alignment between the groups

dauwhe: this kind of input from ppl with real experience is useful
... I think especially the interesting question of what is the interoperable core of 3.0.1 right now
... answering that question could go a long way to answering what we should kill
... could go towards answering what work do we need to do to fix things in 3.1
... maybe it's a matter of cutting out stuff, 3 has a checkered history of slow adoption, implementation
... we've sent only 3 to the supply chain for a while, but sending stuff compatible with 2
... all those are useful to look at as we try to figure out what we want to work on

tzviya: I think valuable to find out from testing platform folks, working with 70 user agents rather than 5
... IOS, Android, linux, mac, pc, ... proliferation of RS ... sometimes you have one organization with 12 instances

dauwhe: with significant differences between the same system on different platforms. much worse than browsers

SteveZ: I think the key thing with testing, you enable orgs to do their own self testing and certification
... the point was that we, css group, we don't test browsers
... vendors can test themselves and others, but we rely on others reporting the results. We just make the tests available and easy to run
... Not saying you should have a certification program, but it makes sense at some level

tzviya: We have a suite of tests with BISG to run a suite of tests. WOrking to make site more friendly. participation from RS on the site is low to very low

Chris: Disagree on self cert. self testing is okay though. Each test needs to indicate what part of what spec it's testing
... not enough to be clear to the person that wrote it
... worse than no tests is bad tests pushing people in the wrong direction

Florian: Coming back to earlier point. Allowing HTML rather than X*
... if you allow both serializations you can write it with the X and it's backwards compatible, but non-XHTML is not compatible
... non-X agents will completely fail

tzviya: only consideration of HTML is that browser version might have HTML and packaged version have XHTML

dauwhe: We've also run informal tests. Concern on ingestion process of RS that may require XML tool chains

dauwhe: rendering engine might be happy at the end of that chain

Florian: Web world loves HTML, but browsers can consume XHTML
... don't see how you can drop the X

tzviya: Decided against polyglot

Edward: Difference between defacto and de juris compatibility

<csarven> Can someone summarize why it was decided to not to use HTML5 Polyglot?

Edward: on paper it shouldn't work, probably does in practice.
... the process is the big deal.

tzviya: You can fake out most tools

Florian: readers based on browsers, no surprise. The ones that aren't are the worry

dauwhe: Larger question, we have to allow HTML at some point in the future
... don't see a way around and the more time that passes the harder it becomes
... have to dive in at some point

sarven: could you summarize why not polyglot?

glazou: polyglot was a contentious point
... only editor is mine, not apple not MS, that's why it failed
... no one knows how to do it

Chris: disadvantage of both, advantages of neither, needed a new tool chain
... needed special purpose tools, and not worth while

glazou: It would be okay if HTML5 main dialect was polyglot
... but it's not
... If I take a regular web dev conference, a month ago, I ask about it. If I ask what it is, 1/100th of the room would know

<Zakim> Request, you wanted to discuss summary for -1 on Polyglot

csarven: I trust your study, but find it odd from my experience. I haven't found any issues with the tools, and easier to work with.
... So was curious to see why

tzviya: Aside from the toolchain, so many restrictions
... iframes, interactive content, etc. Figuring out the restrictions in a spec from a few years

Ed: polyglot requires a profile of javascript that's ??

dauwhe: Sounds perfect

<Zakim> SteveZ, you wanted to say "Can I Use"

SteveZ: related to testing, there's a valuable resource to drive compliance, and that's sites like Can I Use
... a public site that shows where you can use given features

<dauwhe> http://epubtest.org/

SteveZ: by publicly exposing it, there's pressure on the vendors to fix problems that show up there
... part of the problem with 70 people, they don't have anything pushing them
... not necessarily the vendors
... public sites that make some systems look better than others helps compliance

<dauwhe> http://epubtest.org/results/

tzviya: epubtest.org does some of that. Working on improving it. Aware of caniuse
... Pushed epub3 further

SteveZ: Have you explored if can i use would help?
... not connected

Chris: On github, so take PRs
... can fork it too

tzviya: take aways: Crazy to do it quickly, need testing maybe forking canIUse, we'd love help
... any suggestions to take back to IDPF for alignment

Florian: CSS profiling. Moving away from a specific profile is good. Moving on to snapshot not obviously good
... maybe better

ivan: pushes the corpse into the CSS group's courtyard
... not present for the profile being defined, but same problem of what is stable
... external trying to catch up is more complex than CSS doing it

Florian: Profiling itself is an issue

tzviya: allow all?

Florian: You do by using browsers already. Saying that you should support stuff is okay, but not MUST support all of this
... TV world tried and didn't have much success either
... snapshot is what the browser world has, not everything is relevant
... ideally it would be good to support everything
... but not going to happen

tzviya: should be talking about conformance criteria

Florian: authors will include what works, what they hope willl start working soon
... profile that creates extensions is a big problem
... or forbidding going beyond the profile
... iput the focus on supporting page related stuff, maybe that work work

ivan: my understanding of the snapshot is that those are the css docs that from the WG's point of view are stable
... that's different statement to what you're saying
... doesn't say that those are implemented docs

Florian: correct

ivan: Not sure what else can IDPF external group do, other than to say whatever the CSS group declares as being stable is what we use
... if CSS WG decides that this and this are still experimental, then don't use it

<Bobby> tzviya I'll try after lunch

ivan: plan is to issue snapshot every year, so don't see a better option for IDPF
... than to rely on what the WG says

Chris: Take the snapshot as the base and add what's stable in readers
... even if the browsers are behind

ivan: EPUB readers may have implemented unstable docs from the WG PoV? the list is not implementation specific?

FLorian: won't declare something stable unless there's implementations
... not quite rec level but close

ivan: Not clear in snapshot doc
... very important differnce

tzviya: could do with input on css task force

Florian: briefly, snapshot good to point to, but careful what you say about it . what does we use this mean.
... [... too fast ...

]

<Bert1> (From CSS Snapshot 2015: " This profile includes only specifications that we consider stable and for which we have enough implementation experience that we are sure of that stability.")

dauwhe: Looking at snapshot, css is defined by list of specs
... then a couple of other lists of things that are good but not official
... proposal was to say UAs must support 2015 snapshot

tzviya: I think we can discuss in IDPF

r12a: My understanding -- certain extensions supported eg for vertical text
... how does that fit with what we've been saying
... and how does it fit with writing modes
... could be used to replace proprietary approaches

dauwhe: would add to first statement that epub UAs must support snapshot plus these other things for CJK

r12a: Other half of q, was that writing modes progressed, and ereaders using something similar, how do we harmonize approach to vertical text

<Florian> The CSS snapshot is a good representation of the state of stable CSS as of today (where stable includes the fact that based on implementation experience, we know that they are), so pointing at it is a good thing. Requiring conformance either from authors or UA vendors is a very different proposition

dauwhe: good q, don't know much about the state in EPUB

brady_duga: we took a snapshot of writing modes, prefixed some properties and said you have to use this syntax
... but the semantics change with the writing mode specs
... problematic
... one reason was the syntax changed. so didn't map to any semantics as the properties and values changed
... did do an update at some point to correct some that changed .... and then they changed again
... so can't do ??? correctly as the names/values move

Edward: Rendering engines have ability to alias properties to each other
... so as CSS move, the prefixed versions get dragged along

So I don't think that works

Florian: writing modes expeced to hit in 2016
... close but not quite there. small doc, with not quite so aggressive schedule
... also no browser would match the full snapshot

tzviya: Come back at 1pm

### Meeting with the CSS WG

Tzviya: Welcome CSS people

... handing over to Dave to give a walkthrough

... and in the context of epub 3.1 as to what RSes should support (and how to specify it)

... This group has done work on our wishlist for CSS

... have been sneaking around TPAC trying to get people to implement some of those features

... like alignment in tables

<tzviya> +100 for char alignment in tables

... Q: that property is in a draft of a spec

... Do we need to do any spec work here?

fantasai: Not many issues, but not many implementations.

... Keeps moving forward (from CSS 2 to level 4)

... either need to implement or say what is wrong with it

Florian: There are implementations, just not in the web sphere

... implementation experience may be coming, so we may learn from that

tzviya: Does it have to be Chrome, or just anyone at Google (for having weight)

Florian: Any implementation is good, as we learn

rossen: Why this list? How did you come up with it?

dauwhe: Highly unscientific, just asked people I know, asked on lists, etc

Florian: something about priortity of ???

dauwhe: We also considered low-hanging fruit

tzviya: character alignment seems so easy

fantasai: Actually, not that easy.

[general argument among CSS members about how easy/hard character alignment is]

fantasai: Tell me what is missing please

<tzviya> priorities list: http://w3c.github.io/dpub-pagination/priorities.html

dauwhe: Skipping pagination for now as it is so huge

... Generated content is one category, but it is fraught with a11y

... Has there been work to deal with a11y around generated content?

... table numbering, cross reference using counters, etc

<dbaron> fantasai, is it ok if I just add an issue or two to the spec saying what needs to be defined?

... We see the use cases, but are weary of a11y issues around it. Hesitant to push until we understand a11y perspective

fantasai: The spec should cover speech output, the fact that it isn't is a bug

... happy to do any spec work for specific issues in this area

... Can add a box about it in the gc spec, but still has implementation issues

dauwhe: Have heard some people want to use GC for only decorative content, but that is hard to do and define

fantasai: Implementations should make it be accesible. Can in the future use 'display: marker' on in-document elements when the counter needs to be used in the text of the document

tzviya: Harder case: running head needs to be accessible

rossen: Should be accessible by spec

tzviya: But it isn't - what do we do?

fantasai: File bugs

... on implementations

SteveZ: CSS should expose things that aren't in the DOM

<fantasai> SteveZ: Maybe we need extensions to CSSOM to expose this info

Florian: Do we know why specific implementors aren't doing it?

... problems with implementing the spec, or just being passive

fantasai: SteveZ pointed out extensions to CSSOM might help

... May want to expose more APIs for getting counters, etc

SteveZ: There is a CSS meeting on Friday, should raise a11y question then

<fantasai> btw, the fit-to-page feature can be done with flexbox already

tzviya: There is an html mapping document for [something]. That is probably what you are thinking about, but off topic

<tzviya> Core accessibility mappings: http://www.w3.org/TR/core-aam-1.1/

dauwhe: Another topic, having more control over hyphenation

<fantasai> figure { max-height: 100vh; max-width: 100vw; display: flex; } img { flex: 1; } or somesuch...

... several pieces: various users have standards for what is and isn’t acceptable

... need control over smallest word to hyphenate, how many chars before and after, etc

... Conceptually we know what all these controls are from existing editors

... More interesting are dictionaries, exception lists, etc

<rossen> rossen: On the topic of having GC and counters accessible: The accessability tree is currently defined to work on top of the DOM tree. In order to have generated content (including list numbers/counters etc.) impls need to include the computed style tree as well.

... Trying to figure out some way to have a doc author define an exception dictionary the reader engine could use

<tzviya> +1 to rossen

SteveZ: didn't Hakon have a spec for this some time ago?

... But what it points at (format) and languages, etc is hard to define

<fantasai> Hyphenation for non-English has some compexities...

johanneswilm: As I understand how it works, there is a JS library that adds soft hyphens

... given that, it would be hard to get all browsers to ship dictionaries

... Given the current system, what do you really want?

dauwhe: The idea of adding the hyphens horrifies me

tzviya: [showing crappy hyphenation]

johanneswilm: Yeah, but JS could do better job with dictionaries, etc

dauwhe: Really don't like adding soft hyphens

rossen: Back to the question, what do need?

dauwhe: Control over parameters.

Florian: Also how many hypephens in a row

<leaverou> and maximum whitespace between words please :)

<johanneswilm> +q

<fantasai> brady_duga: Browsers just have bad line breaking. Hyphenation gives more breakpoints, but doesn't solve that problem.

<fantasai> johanneswilm: Problems with JS-based hyphenation are that it breaks search, and also it is affecting words that aren't even near the end of the line

rossen: Houdini can address these when we have the view tree

dauwhe: Are you saying this should be at the app level?

rossen: Of ourse- isn't that what you are asking us for?
... You need to show us examples of bad hyphenation today

tzviya: No problem!

rossen: We need specific examples so we know where the current spec has problems, then give requirements

... what would better hyphenation look like?

leaverou: Lots of problems with line breaking, for instance balancing lines

miles: Performance issues with line breaking

<johanneswilm> +q

... letting JS reflow is really slow

<Zakim> LarsG, you wanted to ask if we want to turn ebook readers into dtp systems

LarsG: What are you trying to achieve? Full better line breaking?

dauwhe: Yes

... we want to take that master typographer and embed it in the layout

Florian: Concur with Brady, this is a line breaking problem, not hyphenation

brady_duga: Says maybe performance is not that big a deal

johanneswilm: It's a priortiy thing. Look good or be fast?

<leaverou> FWIW, there are O(n) implementations of Knuth-Plass via SMAWK, but I'm not very knowledgeable on the details

... would still be good to get these primitives in houdini

<fantasai> leaverou: is a good point. IIRC part of the problem was floats

<fantasai> leaverou: but for non-impacted lines...

... being able to measure, etc in JS

... would make it possible to break lines and not be too slow

<leaverou> fantasai: also, in print performance matters much less than the result. Perhaps it could be opt-in?

dauwhe: Next topic. Keeping captions on the same page

... as the image.

... Mentioned it to fantasai and she said maybe flex box would help

fantasai: What do you want to do?

<ChrisL> caption {break-before: avoid-page }

dauwhe: One example, want to keep the caption on the page, then scale the image to fit

fantasai: Let’s say the image should fill the page, and be at least 50% of the size of the page, but in a figure, make it 100vh, display: flex,

... a few other things with flex.

dauwhe: Aspect ratio is preserved?

fantasai: Yes, maybe need to do some stuff with max vh

tzviya: When printed, there are problems

... might be the engine in question

rossen: complain to the implementor!

<fantasai> figure { display: flex; flex-flow: column; height: 100vh; }

<fantasai> img { flex: 1; }

dino: don't want half a blank page, though. May want to make the img a float if it doesn't fit

tzviya: 2 minutes for next steps

dauwhe: And more generally feedback from CSS and how can we help

ivan: we should provide samples and their correct rendering

... that's where we should take the requirement document

ivan: Anything else where we can be helpful?

tzviya: We may ask for some of you to join the calls from time to time

... having direct communication is very helpful

ted: The time of your call sucks

tzviya: We may have occasional calls at better times

... we understand that the time is problematic

<glazou> dauwhe: let's do an IG and a CG first

Florian: Later is terrible for Japan

dauwhe: Simpler solution is cancel the calls and rotate weekly face to faces. [ed note: This may be a joke]

david: there are a lot of new problems reported on char alignment

<dbaron> https://drafts.csswg.org/css-text-4/#character-alignment now has some issues added

<dbaron> fantasai, ^

### Publication Object Model

glazou: describing an idea from implementing epub; framework to to do resources in package, manipulate metadata
... there was no framework available, did not want a java package either

<tzviya> slides are available at http://disruptive-innovations.com/zoo/slides/201510-TPAC/POM.pdf

glazou: so I think we should do something to enable anyone to write a reader, editor, filter, on the web today
... pom publications object model
... abstraction layer to hide the details
... reaching individual resources, each has its own dom,
... adding or modifying metadata is comples. Needs to be hidden from the user
... publucations in name, not epub, so it is publications agnostic
... 2 or 3 layer architecture, register a format assocuiiated to interfaces, which know the deep stuff to do. you call the upper layer which is the abstraction
... publication manager interface, then can reach the individual resources with specific interfaces as needed
... eg an action that is PDF specific, that is on the lower levels only. everything common to all publications is on the higher level only
... manager registers the formats allowed. new formats registered, like aplugin
... add a name and a classs and it is done
... no save, but can load and manipulate
... publication implements all the common stuff, save, manipulate everything inside the resources and the metadata
... mostly when you don't need extra methods, it she regular DOM objects
... but you can add extra methods as needed
... resources allow you to get every file, can be a part of a file or a set of files, in the package. including binary or text. no assumptions here
... what we reach from above should be reachable as a publication resource

(glazou projects a code sample)

glazou: appending metadata, as if it was a regular DOM. set resource type, and save
... easy to manipulate a document. Normally the code is 15x as large as what I showed here which makes it hard to author and maintain
... needs a POM spec, EPUB3 plugin as a Publication spec, lastly an Ooen Source framework that mplements it, in C++ and again in JavaScript. Common source for both
... maybe in Swift
... but a single source transpiled. Then we have easy maniplation

Florian: makes a lot of sense, curious about the last part on implementation. who implements this?

glazou: yes I will write an implementations

Florian: but what class of people should implement at this level

ivan: I prefer it in Python

Florian: not the users of it, but the implementors of it

ivan: building on top of this would be good

tzviya: could even go beyond publications
... branch with special requirements

Florian: so it is not for browsers only

glazou: why not a WG on this topic, then you have members who implement it

ivan: browsers would not do this at first , but we could have non-browser imple,entations

glazou: as a javascript framework

brady_duga: sounds very reasonable, question the need for a spec though
... is it just a library, do we expect multiple implementations?

glazou: yes, i do

<myles> dauwhe: don't worry i got this (re: swift implementation)

dauwhe: is this for authoring & editing tools, or something for a browser to use to display/

glazou: multipurpose. can do converson filtering for example
... could do a validator

Jeff_Xu: is it like a CMS? For users if we want to export a website as an epub file?

glazou: yes, agreed

clapierre: have you discussed with the Readium?

glazou: yes, I have
... in BG epub it was a burden not having this, and its the only native epub editor. Making it simpler makes it easier to make more tools

<Bobby> sorry for previlege setting error: Japanese EPUB check items translated version here again: https://docs.google.com/spreadsheets/d/1s60yFQ6V1vqNDCErOQW-VRcwUIL5wnIhAiOmMayJe64/pubhtml

ivan: for my project it would have been great to have this. practical issue is 3.1 is coming, expect to see in analysis of 3.1 what asre the features which are generally important and wat are epub specific or historical
... so the details of what is publication agnostic and what is epub specific needs to evolve and be re-examines over time
... formulate in more generic terms

glazou: need to know 3 or 4 types of publications to abstract out the generic parts
... finding what is common across all formats is hard
... this is why I am presenting it

tzviya: what are the next steps? do you need more details of workflow and formats?

glazou: yes, and what is the basic missing info inside, where can i read about it. mutiple documents and pages, how they all link together. need to compare multiple formats

ivan: mayne some format is not in scope as too different and not worth the trouble

tzviya: we can give you more info. then what do we do
... can i wite the spec with you?

glazou: it is IDL and code mostly. but review would be very helpful

ivan: this group can publish text docs but only as notes

glazou: what about a member submission?

ChrisL: or make a CG to do initial spec work

tzviya: we may have some people to contribute code, but they did not make it to japan

Florian: vivliostyle would be a user , review rather than contribute
... the JS part specifically, maybe C++, not Python

glazou: could be differences in zipper tools, file access. the rest is all DOM manipulation

???/if the CG is broader then I would be interested, had planned to make a CG but from a different angle

Sarven: seems to treat a document with an API, to me that is less than the RDF to get access to it, independent of program language. query an RDF store

<jeff_xu> Not looks very difficult. I can help implementation, C++, javascript, or anything else if want.

glazou: there are some soecifics to the press, metsadata for example, not always the case in other formats. Not sure it fits well with an RDF store

ivan: when you get inthe guts of the package, the DOM is well defined. Then it is a traditional DOM manager. RDFa is defined on the DOM, give it to an RDFa extractor but that is not needed here

tzviya: assuming you were writing to JATS
... once we have the container, no reason not to add the RDFa

glazou: could be extended to annotations etc over time.

<Zakim> LarsG, you wanted to talk about single- vs multidocument publications

tzviya: not just publications, any container

LarsG: mismatch between a monolithic document with RDFa and a container API

Sarven: so needs an HTML export of the source format?

glazou: resource could be a zip, or an html document, a PNG image, anything
... an email with text and images could be seen as a publication in this context

Sarven: I am covering this

action glazou to create a POM CG

<trackbot> Error finding 'glazou'. You can review and register nicknames at <http://www.w3.org/dpub/IG/track/users>.

ivan: hard to manage the abstraction level

glazou: needs t work for epub at least, for other formats it needs help

tzviya: and we owe you some info about workflow and formats

fantasai: object-fit: contain on the img really helps with the flex example

skk: we also have an epub3 viewer and made some abstraction layer so we would like to contribute
... C++

glazou: wonderful

(break, 45min)

<tzviya> POM CG: https://www.w3.org/community/groups/proposed/#pom

<glazou> community group supported by more than 5 (required) in less than 30 minutes ; achievement unlocked

### Service Workers

[people introduce one another]

Ivan: does what we wrote make sense?

Jake: yes, makes sense, uses common patterns, offline first

tzviya: OK, then we're done ;-)

Jake: but service workers need an https protocol, not local file
... or if it's localhost you can have http instead of https.

ivan: I think our model is that it is the local file system, e.g. I downloaded a book
... Now, what does that mean exactly? If I mounted some remote filesystem then it's still local I guess?

Jake: right.

The only thing tht'd make a difference'd be if it was running a local http server

Ivan: ah, so you can't use file: protocol.

Jake: the spec is hand-wavey, yuo send a request and get a response but file system doesn't fit that

<tzviya> we are referring to the http://w3c.github.io/dpub-pwp/#arch section of PWP

Daniel: I'm wondering what you people mean by local file system. E.g. we make use of HTML 5 file system

and I think only supported fully by Chrome, but means we can unpack an epub in the local "file system"

We can load content into iframes transparently

scribe: so that's what we used to cache out exploded [zip files],
... But there's also a built-in cache api to service workers.

Jake: the file system stuff doesn't seem to be going anywhere, whereas this cache is in chrome & [firefox nightly?]
... Even from a window you can get into a cache and then you can get a "blob" and get a URL for it.

Ivan: Because I'm not sure of all the detail, Daniel, could you write this and put it as an issue on github?

Daniel: OK
... with blob URIs you have to know all the assets but this breaks streaming; in Readium we have to preprocess the full DOM tree and feed it to the iframe
... You either do the local [html] file system or the service worker + cache, but blob URI doesn't really meet our needs.

Jeff: Before we pushed the cache,

Jake: you can't use XHR within a service worker

it's turned off because of efficiency and because yuo can use it synchronously

but there are other methods

<DanielWeck> q

<DanielWeck> qw+

<tzviya> ACTION DanielWeck to file GitHub issue about local "file system" and cache

<trackbot> Error finding 'DanielWeck'. You can review and register nicknames at <http://www.w3.org/dpub/IG/track/users>.

scribe: If yuo want to process a zip, e.g. yuo ahve a JS implementation of unzip code yuo can do that;
... we're introducing streams so you could do that in a streaming way, pull things out of the zip & put them in the cache.
... that's not implemented in chrome yet - we're hoping for Q1.

[question also about HTTP Range requests - yes, you'll get a range response back, if it's supported by the server]

Florian: you say service workers don't work on the file protocol; is it architectural or just underspecified?

Jake: the service worker always has to exist on an independent URL, so should be possible on the file system, but I think the main problem is defining what a request object would look like
... There may also be security concerns.

Florian: so this hasn't been fully explored

Jake: yes.

DanielWeck: Going back to file URI protocol, agree, file: isn't really designed for the web, so for readium we launch a local web server

We also have native apps that launch their own internal http server within the app itself to feed the content to the app.

There isn't a security https requirement when the URI is bound to the local IP address but it has a same domain policy & has to be https when remote.

Jake: the same origin policy - a SW must be on the same page as the app, but the SW gets to intercept all the subresource requests on that page and you can catch those

So if you're fetching content from another server - images, scripts, XHR - then your SW will intercept that. An iframe is different, not a sub-resource.

DanielWeck: once code runs in the context of a SW, XHR is not available, but when you use a library that uses XHR under the hood we had to polyfill XHR using the request API!

Jake: may be politics in disabling XHR in SW; it's possible we could bring it back & just ban the synchronous element of it.

Ted: also have to ban the DOM access.

Jake: yes.

Jake: the cache api, you can delete stuff. the http cache, with the fetch api, you can specify how it should interact with the cache, an option is to bypassit.
... not all implementedin Chromium.

ClearSiteData API is a header-based way to clear caches & storage and there's a JS API for that too.

It acts as a panic button if you detect XSS, or on logout.

Ivan: what we have here, is it something that the existence thereof, and what Daniel etc have done in Readium, is it the kind of application interesting enough to be a use case to push other browsers?

Jake: any feedback around the API is very valuable, along with feedback we're getting from Facebook, The Guardian, etc

tzviya: it's a use case that has the potential to support the entire publishing industry so it's a big use case.

ivan: saying anything they put on the Web must be on https, will that be OK?

Jake: it's not just about what you send to the server, it's what the server sends to you too.

DanielWeck: I was wondering, why is this group considering the need to access the raw filesystem from the browser?
... My experience is that a hybrid app will expose a custom URI scheme
... Is there a diagram?

Ivan: I didn't realize until half an hour that aspect, the use case I had is I download a book e.g. via dropbox and now I want to read it in the browser.

The trick you had of starting a local server solves the issue.

Jake: what's the benefit of using a local server?

Ivan: because I can receive the article from a friend by email, many ways a publication can be sent around.

tzviya: another use case is archiving, needs to be an archival format.

Jake: Archival format could be generated by a service worker.

Florian: Having downloaded the various assets, the SW could use the kind of API Daniel was describing

myles: Maybe I'm eing naieve
... but if I need a server in order to read a publication, seems like that might be a security problem.
... E.g. on Apple platform we grant rights to the network as opposed to the file system.

Jake: Yeah, if you run a page on the file system you can XHR within that folder (directory) and down. But can't reach out.

(don't get an html file on / and open it!)

I agree there's a massive security consideration.

Jake: What's the benefit of the SW when you already have the publication on the user's disk?

Ivan: from my point of view the fact that the SW abstracts out the difference of the publications being local or remote, packaged or not, is what I gain
... All the rest of the reader, conceptually, works as if the publication was unpacked & on the Web.
... That has consequences on e.g. what is the canonical identifier of a publication. If the local fs vanishes from the equation and we think in terms of URIs, that's a major win.

Jake: might be possible to do some of that, I'm hoping we can get to a point where we can do a fetch to a page & ipe the stream into a handler

That would work around the memory issues.

scribe: If you navigate to a fs location that didn't exist but you wanted to make it exist, that'd be hard, and has security issues.

Especially with a Web-based OS.

Myles: So Ivan mentioned benefits of using service worker. There are drawbacks - security issues & added complexities of running a Web server inside your layout program. I don't think it's worth it.

Jake: if you're wanting to present publications online with an endpoint that works offline then I think SW is a good option.
... If you're saving to the fs a zip of content yuo could then unzip...

[discussion of whether Web server and SW is suitable, or too heavy-handed]

Brady: today many reading systems are already doing this, e.g. playbooks, puts HTML content in a [native] WebView
... and we make requests for resources & grab them from the fs. Can't store books on fs, have to encrypt. So stuff happens, and this is common for a Web-based reading system.
... Requests are going to a notive app that fulfills them from local storage.

Other case is you have content on the Web

We want to serve the images for a book [on the Web] in an encrypted way so they don't end up in the browser cache.

scribe: You download the content in the context of the SW & transform it before putting it on the screen.

You don't *need* SW but there are nasty workarounds you have to do in that case.

Jake: If we're talking about a directory with an HTML file in it, I don't think that would work. The SW requires a static location, and it woudn't be static if you moved the files around.

Brady: SW makes sense when the book lives on the Web & you [use local fs as a sort of offline cache]

<dauwhe> scribenick: dauwhe

LarsG: comment:
... the encrypted connection to downloaded images, why don't you just use cache control

brady_duga: I don't know impl details
... there were concerns about intercept content
... i don't know details

JakeA: http resources can be cached

JakeA: on the encrypted data side we're storing data in a database on a disk, but unencrypted
... the web crypto api is there
... chrome says if you've installed something on your file system you've lost security

DanielWeck: from a RS perspective
... there's a separation between native apps and hybrid apps
... native apps vs pure web readers
... in native app you can do anything
... use custom url handlers
... we work around owp platform limitiations
... in that context SWs are brilliant
... in the context of a native app you don't need service workers
... we use a combination of mechanisms
... in order to strongly obsfucate
... so user can't access content
... usually users can steal data from developer tools
... another example is with chrome we can access html5 file system
... we cache content locally in html5 filesystem
... it's security by obscurity
... files themselves are clear
... but the file paths are obsfucated
... we've combined different mechanisms so users can't easily access unencrypted content
... it's a mitigation effort

JakeA: i'm working on a course to teach offline first
... there's a series of coding tasks
... with gif prizes
... so I added null byte to the start of each image
... then strip it off
... so you can do smarter things
... there's a plugin

<DanielWeck> (combination of mechanisms to protect content / intellectual property: e.g. security by "obscurity", obfuscation of file paths within the local cache or HTML5 filesystem)

JakeA: i like using the web instead of native
... on chrome team we want to hear what's hard on web platform but easy on native + web view
... tell us about those things so we can fix them

jeff_xu: whhen we run out a resource, how can we clear the service worker

JakeA: browser makes no promises about retaining storage
... it can clear out origins
... a full origin at a time
... there's a storage API
... where you can request persistent storage
... which requires permission from the user
... but that is then permanent, essentially installed by owner
... we're working on what those steps by me
... perhaps based on being added to home screen

jeff_xu: it is possible to set priority between service workers
... some we want to keep running, some we want cleared

JakeA: there are different kinds of workers with different live cycles
... started by events, killed once event ends
... browser may keep running to save on startup costs
... idea is for them to disappear soon
... if you want something to hang around, you want worker or shared worker

jeff_xu: how to check health of current service works

JakeA: there are error listeners
... you can check state of registration
... that's all observable
... we have open issue if service worker fails when there are no pages

skk: the future of SW on top of web tech, but we can choose another mechanism
... for simple thing, we can install cache server (?)
... not sure if this design choice is appropriate for this domain
... but SWs are useful for other web services
... before talking about tech details
... I want to know pros and cons of this design choice
... but there might be another presentation

JakeA: I agree
... SW isn't answer on filesystem with self-executing bundle
... you could have an ebook reader website that uses SW to work offline
... either by a click or drag and drop
... and it could give you the bundled format if you ask

tzviya: that's why we had this meeting

<tzviya> to log issue on GitHub: https://github.com/w3c/dpub-pwp/issues

tzviya: to find out if we're on the right track
... if you have other suggestions add issues

JakeA: is the user flow documented anywhere?

tzviya: how they open a book?

ivan: there isn't one; there are several
... we give use cases in the doc
... if I have an online sci journal
... might have lots of goodies
... but then I want to annotate it on the train, so I want it on my machine
... or publisher wants to sell me this thing, they want to sell one unit
... that's where the package comes in
... whether it's offline or online...
... these are all situations user may hit when interacting with publishing today
... the difficulty is that we can of course come up with smart ideas about doing it one way
... but there is a billion dollar industry that has its own publishing habits
... we must adapt to what is out there
... maybe a smooth transition to where everything is on the web

JakeA: I'm not suggesting that, I just wanted to have the pattern in my head

ivan: there are several

JakeA: SWs would be useful for publishers to host books so they would work offline
... and for making a web-based app

ivan: for me the SW is a tool or approach to unify these different patterns
... some of which are awkward
... but I have a way to mmove forward without destroying what's out there
... there's a practical aspect

tzviya: thank you everyone
... thanks to Jake

JakeA: thanks for inviting me

## Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.143 (CVS log)
$Date: 2015/10/29 21:18:06$