- From: Cramer, Dave <Dave.Cramer@hbgusa.com>
- Date: Wed, 16 Nov 2016 01:37:30 +0000
- To: Leonard Rosenthol <lrosenth@adobe.com>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
- Message-ID: <D4512084.D959%dave.cramer@hbgusa.com>
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 01:38:05 UTC