Re: A followup/writeup on our Monday discussions (was Re: Continuing discussion on Polyfills)

> On 7 Feb 2018, at 17:23, Matt Garrish <matt.garrish@gmail.com <mailto:matt.garrish@gmail.com>> wrote:
> 
> I'm just catching back up with these discussions, but would it make sense for there to be a scripting API for the affordances that exposes the supported "publication" features and/or exposes other aspects of the reading mode?

Yes, thinking in terms of API makes a lot of sense IMO.

Generally, I believe one of our core issue is to consider Web Publications as a monolithic beast. It’s good enough for defining use cases and work out a list of potential affordances, but it becomes limiting when trying to envision the technical solution(s). We’re not necessarily in an either/or situation, where a Web Publication is either read in a separate app providing all the affordances (web app or native client), or else read as web content with none of these.

I would strongly suggest to think in terms of extensible web [1], at least if we want Web Pubs to ever be considered by web consistuencies other than those involved in the current EPUB ecosystem (in other words, the former = web devs and web browsers).
 
Having a way to specify a fallback app might be a good idea, I don’t know. But it certainly doesn’t rule out thinking about some publication-oriented features/affordances as individual, possibly low-level, capabilities (which may or may not be polyfillable, let’s figure this out later when we’re closer to actual tech solutions).

I hope this makes sense.

Best,
Romain.


[1] https://extensiblewebmanifesto.org/ <https://extensiblewebmanifesto.org/>

Received on Thursday, 8 February 2018 00:26:27 UTC