SoylentNews is people
SoylentNews
from the documents-definitely-need-javascript dept.
Daniel Glazman believes that EPUB has reached a technical dead end.
- It is impossible to aggregate a set of web pages into a EPUB book through a trivial zip, and it is impossible to unzip an EPUB book and make it readable inside a Web browser even with graceful degradation.
- Despite the International Digital Publishing Forum merging with W3C in January 2017, EPUB continues to diverge from web standards.
- The EPUB 3.1 specification has been rescinded because it is too costly and complex for the eBook industry to adopt.
Mr. Glazman's solution? The WebBook format. From the announcement:
I have then decided to work on a different format for electronic books, called WebBook. A format strictly based on Web technologies and when I say "Web technologies", I mean the most basic ones: html, CSS, JavaScript, SVG and friends; the class of specifications all Web authors use and master on a daily basis. Not all details are decided or even ironed, the proposal is still a work in progress at this point, but I know where I want to go to.
[...] I have started from a list of requirements, something that was never done that way in the EPUB world:
- one URL is enough to retrieve a remote WebBook instance, there is no need to download every resource composing that instance
- the contents of a WebBook instance can be placed inside a Web site's directory and are directly readable by a Web browser using the URL for that directory
- the contents of a WebBook instance can be placed inside a local directory and are directly readable by a Web browser opening its index.html or index.xhtml topmost file
- each individual resource in a WebBook instance, on a Web site or on a local disk, is directly readable by a Web browser
- any html document can be used as content document inside a WebBook instance, without restriction
- any stylesheet, replaced resource (images, audio, video, etc.) or additional resource useable by a html document (JavaScript, manifests, etc.) can be used inside the navigation document or the content documents of a WebBook instance, without restriction
- the navigation document and the content documents inside a WebBook instance can be created and edited by any html editor
- the metadata, table of contents contained in the navigation document of a WebBook instance can be created and edited by any html editor
- the WebBook specification is backwards-compatible
- the WebBook specification is forwards-compatible, at the potential cost of graceful degradation of some content
- WebBook instances can be recognized without having to detect their MIME type
- it's possible to deliver electronic books in a form that is compatible with both WebBook and EPUB 3.0.1
Compatibility with EPUB 3.0.1 is a good way to start adoption. Now to see if WebBook catches on. The GitHub repository is here.
(Score: 2) by Apparition on Monday April 23 2018, @12:13AM (18 children)
JavaScript being part of the WebBook spec is no surprise, since Daniel Glazman was a JavaScript programmer for Mozilla. If used sparingly, it shouldn't be a problem. The problem is that that is a big "if."
(Score: 5, Insightful) by RS3 on Monday April 23 2018, @12:33AM
I agree with you, but there are evildoers out there in many forms, so you can't expect everyone to play fair and write proper code. I've railed against javascript for 20 years, but the problem is not javascript. The problem is what the browser is willing to do, and what the OS allows access to.
(Score: 5, Insightful) by The Mighty Buzzard on Monday April 23 2018, @12:57AM (16 children)
Nope, not even then. The only thing about a book that needs to be interactive or change in any way during runtime is which page you're reading. Which means every little bit of it can be done with plain old HTML. Not even HTML5; HTML3.2 would be sufficient for nearly every book ever published. I'll grant you CSS would make styling it less verbose but even that isn't strictly necessary.
My rights don't end where your fear begins.
(Score: 4, Interesting) by frojack on Monday April 23 2018, @03:52AM (7 children)
Which page you are reading, type face. and font size.
Everything else will be use for advertising and spyware. Even if you suppose no internet connection during reading, there will be one there sooner or later.
This whole issue here is capability beyond what is needed for an e-reader.
They are thinking Newspaper replacement.
I am thinking get out of my face.
No, you are mistaken. I've always had this sig.
(Score: 2) by zocalo on Monday April 23 2018, @06:38AM (3 children)
Still, if this goes ahead as proposed, I suspect there is going to a good deal of interest in ebook converters that strip this kind of crap out and ebook readers that make it click to play, no matter what the standard says. A growing number of people have had enough of the all pervasive use of ads and tracking on the web and will go to quite considerable lengths to block it, if they're expecting that group to feel any differently about the same stuff in ebooks then I suspect they're going to be disappointed.
UNIX? They're not even circumcised! Savages!
(Score: 2) by The Mighty Buzzard on Monday April 23 2018, @10:24AM (2 children)
Calibre can already convert from epub 3 to plain old text, or most any other non-interactive ebook format.
My rights don't end where your fear begins.
(Score: 2) by zocalo on Monday April 23 2018, @11:12AM (1 child)
UNIX? They're not even circumcised! Savages!
(Score: 2) by The Mighty Buzzard on Monday April 23 2018, @11:21AM
Yup to calibre's built in reader. As far as I can tell, it's mostly there to make sure the conversion went off without a hitch. I don't read ebooks much on my desktop anyway though, so that's pretty much all I need it to do.
My rights don't end where your fear begins.
(Score: 2) by Arik on Monday April 23 2018, @11:45AM (1 child)
Should be set by the user, not the book.
If laughter is the best medicine, who are the best doctors?
(Score: 2, Insightful) by Anonymous Coward on Monday April 23 2018, @02:27PM
That's idiotic. Those should be set by the book with the reader being able to override it if need be.
Depending upon the content of the book, the font size shouldn't always be the same, if you're looking for more of a light breezy read, then something like Times New Roman 10, is a great choice, but if you're reading something where you need to read slower or you need a larger font, you'd want something else. Then there's computer manuals where they often times use multiple fonts to differentiate between book content and what you actually type at the prompt.
In short, the people making most of these books do spend time considering the needs of the readers when setting those defaults, if don't let them do it, then all sorts of weird things can happen. What's worse, is that you may not even be making the correct choices for an enjoyable read, but if it defaults to something from the publisher, you can easily go back and forth as appropriate.
(Score: 0) by Anonymous Coward on Monday April 23 2018, @05:19PM
they just need to put the ability/requirement for a webbook to include details in it's file format in the spec. kind of like exif in images.
'uses_js' -> '1',
'has_remote_resources' => '1',
you get the idea. then you could choose whether to use certain books based on their technical aspects.
(Score: 2) by JNCF on Monday April 23 2018, @05:11AM (5 children)
Frojack points to some stylistic toggling the user might like to do without reloading the page, but it should all be doable -- if a bit clunky -- with some CSS selectors and radio buttons. There are some things that could be added to his list, most obviously annotations.
As for what can't be done, I see an argument for built in note-taking in ebooks. I write in the margins of (some) dead tree books, why shouldn't I be able to do the same with an ebook? Yeah, I could keep these separate, but if and when I read the book again I'd like to be able to read the notes of my previous iteration and edit them as I go. Sometimes I have insights the first time that I don't have the second time until I read them again, and other times I just mark out my stupid ideas that were incorrect and addressed by the author later in the same work. I own at least two books with five different colors of ink in them, each corresponding to a different read-through. I'm usually hesitant to loan out books I've written in, since the notes are harder to replace than the books (and potentially embarrassing, when they're stupid notes), but I have done it when asked. So I would like to be able to insert my own text at any point between lines, ideally I would like to be able to distinguish between different categories of notes using a color scheme or some similar visually distinct tagging, and I would like to be able to export and share my notes with other people. I would like to do all of this without reloading the page. Is this functionality worth the price of JavaScript? There are no shoulds, and I can't that answer that for you, but it is an interactive aspect of a normal book that I can't see implementing with just HTML and CSS.
(Score: 2) by zocalo on Monday April 23 2018, @07:00AM (1 child)
Alternatively, you could just have the annotations as a byte offset in the sidecar file if you don't mind a little more overhead when you re-open each chapter as they get re-inserted. Optionally, you could also add a user ID tag so multiple people could annotate the same ebook (who doesn't like reading the notes of a reference book's previous owner?), and since all of the annotations would be in a sidecar file it would be fairly straightfoward to redistribute the ebook with or without the notes. All the code required could then be natively compiled in the ebook reader, rather than providing a potential attack vector for malicious JavaScript embedded in the book. The only real gotcha I can think of so far would be if you manually shared the ebook without the sidecar file as it would then still have any inline annotation markup in place in the source, so an annotation supporting reader would need to be able to clean up or work around the orphaned annotation markup.
UNIX? They're not even circumcised! Savages!
(Score: 2) by JNCF on Monday April 23 2018, @07:49PM
I like your proposal. I'd really like there to be something of this nature for webpages in general, though I'm sketchy on the details (tradeoffs are difficult). Of course, we're no longer strictly dealing with existing web technologies. That's fine, perhaps desirable, but I think my original post is still valid in context.
(Score: 1, Informative) by Anonymous Coward on Monday April 23 2018, @09:20AM (2 children)
The pencil you use to write in the margin of the dead-tree books isn't part of the book. It's the e-reader software that should enable you to make notes, not the e-book itself.
(Score: 0) by Anonymous Coward on Monday April 23 2018, @02:30PM
Yes, or there could be a dedicated side car file that keeps track of that along with the other user specific data like some digital cameras do. Making changes to the original file is asking for data corruption issues if you're unfortunate enough to have the device crash, run out of batteries or otherwise be prevented from finishing the write. At least if it's in a separate file, it's a lot easier to prevent corruption of the book which you may or may not have a different copy of. Not to mention that it makes it easier to identify if the backup is the same as the one you're reading.
(Score: 2) by JNCF on Monday April 23 2018, @07:54PM
I'm not opposed to this solution (see my response to zocalo above), but arguing it based on a pencil analogy is ridiculous. Is bookmarking a function of a book, or a bookmark? Don't we still call it bookmarking when we use the dog-eared corner of a page? Ergo, sites and browsers should both implement bookmarking independently. Huzzah!
(Score: 2) by TheRaven on Monday April 23 2018, @11:44AM
I can think of lots of things I'd like to see be interactive in a book, but they should all be under the control of the reader, not the book. For example, being able to colour parts of speech, be able to pop up definitions of words, highlight different speakers in different typefaces or background colours, show the last time a particular topic was mentioned, and so on. These are all possible of more metadata is included in the book, they are not helped by the addition of a general-purpose programming languages.
sudo mod me up
(Score: 3, Insightful) by Wootery on Friday April 27 2018, @09:39AM
Seconded. Shouldn't EPUB just be a narrow subset of the web standards (decidedly not including JavaScript) + 7zip? Am I missing something?
There are entire operating systems that are smaller and simpler than modern web browsers. There's no call for this complexity when publishing documents.