W3C home > Mailing lists > Public > public-digipub-ig@w3.org > November 2016

Re: JS - inside or out?

From: Leonard Rosenthol <lrosenth@adobe.com>
Date: Wed, 16 Nov 2016 04:13:43 +0000
To: "Cramer, Dave" <Dave.Cramer@hbgusa.com>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
Message-ID: <EDDD7DC5-A035-44DD-ADB5-BEA9DA433A4D@adobe.com>
> What if a content author wants to intercept a touch event that’s generally used by the UA for page turns or navigation
>
The content author should ABSOLUTELY be allowed to – at least IMO.  In my world (PDF), we believe very strongly that the author is king and their intent takes precedence (except where it conflicts with user needs, such as accessibility or personalization, or security issues).


> There’s a constant desire to have publisher content take over some of the screen real estate used by reading system chrome
>
While I sympathize with that desire, such a thing is a HUGE security risk – and definitely not something I would support.


> What happens if I bundle all the Acme Labs JS into one of my test files, but then try to view it in a similar reading environment?
>I can imagine a Russian dolls scenario of navigation inside navigation inside navigation inside navigation…
>
Clearly that is a concern and I suspect that this would be a good use case for publication metadata..


> I don’t have a solution, but I think we do have some serious issues here.
>
No argument.  I consider that job security ☺.


Leonard

From: "Cramer, Dave" <Dave.Cramer@hbgusa.com>
Date: Tuesday, November 15, 2016 at 5:37 PM
To: Leonard Rosenthol <lrosenth@adobe.com>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
Subject: Re: JS - inside or out?

Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> escrit:

Following up on a comment from the meeting on Monday:

>Ivan: "There is one big choice to be made - and this is whether the javascript that does the heavy lifting
> - is it something deployed as part of the publication, or external to a publication.
>

I feel very strongly that this isn’t something we should be mandating either way.

If a given author wishes to include JS inside their publication to handle pagination or navigation – they should be able to do so.  However, we certainly don’t want to require that, so we need a model that also allows for UA-provided navigation.


There are already significant conflicts in EPUB between user agents and EPUB content. What if a content author wants to intercept a touch event that’s generally used by the UA for page turns or navigation? There’s a constant desire to have publisher content take over some of the screen real estate used by reading system chrome.

What happens if I bundle all the Acme Labs JS into one of my test files, but then try to view it in a similar reading environment? I can imagine a Russian dolls scenario of navigation inside navigation inside navigation inside navigation…

I don’t have a solution, but I think we do have some serious issues here.

Dave
This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.
Received on Wednesday, 16 November 2016 04:14:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:35 UTC