Re: "Do we really care if it's part of the core Web browser engine or not?"

Hello Baldur,

Thank you for this email, I think it's important to have this discussion
openly.

> Do we really care if it's part of the core Web browser engine or not?
>
> The answer for a _lot_ of us is yes, absolutely yes. That is what we
> really care about at the Rebus Foundation. It is the only thing we care
> about. And the fact that it looks exceedingly unlikely to happen at this
> point is a big disincentive to participation for those of us whose mandate
> is primarily to to make the web proper (i.e. what the core browser engine
> supports) a better platform for publications and web sites/services that
> have publication-like characteristics.
>
> It isn’t a question of drive but of economics. I can’t justify spending my
> employer’s time, resources, and money on these specifications given the
> likely outcomes. I suspect the same applies to many others who have dropped
> out of the discussions.
>

I wasn't saying that bringing new features to the core Web browser engine
doesn't matter at all, my point was that:

   - what we're currently working on (WP, audiobooks) IMO doesn't belong in
   the them, we're instead defining a declarative syntax meant to be supported
   using JS on top of existing low level APIs
   - while there are improvements that could be done specifically for
   publications on the Web, such discussions can't IMO happen in a separate
   WG, they need to be discussed within existing WGs at W3C (CSS for instance)
   - aside from a few suggestions from Romain, I haven't seen a good list
   of what these low level APIs improvements could look like



> Again Hadrien Gardeur:
> > For many standards, the politics are not clear. I don't think it's a
> good way to look at this problem.
>
> I think the politics of this WG and this spec are very clear to many
> outside observers. It is primarily for publishing industry use cases, apps,
> and platforms. It is not for extending the core web's feature set to better
> support publications and things that look like publications.
>
> You could achieve the goals of the former by building on the latter but
> that approach would mean that this WG wouldn't be able to achieve its
> stated goals on the timeline it's chartered for and my impression is that
> the needs of the publishing industry are becoming acute.
>

I don't think that the current work on W3C is strictly limited to what we
would traditionally call "the publishing industry".

A lot of academic libraries and institutions are looking for a "IIIF for
publications" to provide an easy way to:

   - distribute publications that they digitize (national libraries) or
   publish (academic libraries, institutions) on the Web
   - provide an easy way to read such publications, no matter where it's
   coming from (national libraries for instance would love to aggregate
   publications from multiple sources, yet offer a consistent reading
   experience)

WP could IMO play that role and foster a similar ecosystem than what IIIF
created.

In fact, a large portion of the publishing industry (trade) barely cares
about WP at this point, as it is not aligned with what they identify as
their "traditional business model".

If you make it publicly at least semi-official that this WG’s Web
> Publication work is focusing on publishing industry concerns and not on
> adding features to web browsers proper then that would probably make
> consensus easier. It would bring expectations in line with the probable
> outcome. By taking potential browser implementation out of the picture, a
> lot of the questions surrounding the spec will become clearer and
> implementation questions become simpler to answer. You only need to deal
> with dedicated reading apps and polyfills.
>
> Such a decision wouldn’t preclude bringing more low level
> publication-oriented features into the web browser core at a later date. In
> fact, having a publishing industry-oriented Web Publication spec
> implemented by the EPUB ecosystem might be help us figure out what browser
> features would be helpful additions to the platform.
>

I certainly agree with you on that point.
Having a thriving ecosystem, even if it's built on top of dedicated reading
apps and polyfills (both built with Web technologies) would certainly help
us to identify limitations and potential new features. Even with very basic
prototypes, some of these limitations become quickly obvious (for example
the lack of support for range request in Service Workers or the limited
cache available).

Best,
Hadrien