5 ms·
I believe it a good thing that the EPUB standard will henceforth be further developed by and within the same body that develops the standards on which EPUB reli
by rhythmvs 10y ago
I believe it a good thing that the EPUB standard will henceforth be further developed by and within the same body that develops the standards on which EPUB relies. After all, EPUB is “stripped down html5” anyway. As a developer of Web-based html5 books, I can certainly see the benefits of becoming enabled to re-use my static html and css ‘as-is’ and repackage into EPUB-based books for offline consumption by e-readers.
But there’s some fierce objection against the merger of IDPF into the W3C [1][2], the key (?) argument being formulated as:
> “The W3C is focused on promoting the Web, but eBooks are not websites. When the IDPF is gone, who will advocate for readers?”
Maybe a fair point, but I don’t think I can agree. While it is true indeed that reading long-form content like books requires enduring focus, and that having to read them in a browser where linkbait always is luring to have you click away into a never ending feed of distraction, the problem is not the underlying technology.
[1] http://www.publishersweekly.com/pw/by-topic/digital/content-and-e-books/article/72492-overdrive-s-steve-potash-moves-to-block-idpf-merger-with-w3c.html http://www.publishersweekly.com/pw/by-topic/digital/content-...
[2] http://futureofebooks.info/ http://futureofebooks.info/
- staz 10y agoI thought that WhatWG were actually the ones developing HTML5?
- kuschku 10y agoWhatWG is just rubberstamping "whatever Chrome implements" (sometimes with feedback from Firefox) as HTML5. The actual development is entirely controlled by the browser vendors, causing pain for everyone trying to parse HTML programmatically.
- andybak 10y agoBecause everything went so well when the W3C was left to their own devices...
- kuschku 10y agoCertainly better than bullying cURL into accepting their idiotic URL specification. Especially considering what they want would rather be specified as a parser for generating URLs from user input, and not to simply demand every tool interacting with URLs to be able to parse malformed URLs.
- jcranmer 10y agoWHATWG didn't bully cURL into URL, people complaining that cURL didn't match browsers did that. The WHATWG made a decision long ago that its standards would be descriptive (describe how people parse it), not prescriptive (describe how people should write it). Anyone who attempted to write a web browser would have had to reverse-engineer how other browsers treated crap, because it was the only way to get websites to work. If you think the definition of URL was stupid, you should see what they had to do to support document.all: define a new concept in JS to represent the notion of "this looks and acts like undefined but you can actually use it as an object."
- kuschku 10y agoAnd a descriptive standard is entirely useless. The entire point of a standard is that implementors agree on a design definition, then implement it, and it stays consistent, forever. If you look at standards that work and fail, you’ll quickly notice a pattern. Prescriptive are Metric, the A-series of paper, the entire SI system, most open standards, etc. Descriptive are the imperial / US standard, Letter paper, Microsoft "Open" XML, etc. And before you complain that prescriptive standards are useless because you can never change legacy systems: Several countries have prescriptive language design, with legal authorities how the language has to be used, and they manage to deal with centuries of legacy data.
- jcranmer 10y agoThe email RFCs are prescriptive, and totally useless. I actually have evidence, for example, that RFC 2047 is more often violated than not, and I wonder if message/global will ever see usage as a Content-Type. Prescriptive attempts at tackling memory models in languages have generally failed. Also, your delineation of prescriptive/descriptive is laughable. The imperial standard, letter paper, and OOXML are all prescriptive standards (albeit OOXML is a very badly written one). Prescriptive language standards aren't necessarily well-applied--ask how many people follow the 1996 German spelling reform, or how many use «le hashtag» instead of the "official" «le mot-dièse» (hint: look at the name of the Wikipedia page is). OOXML did poorly not because it was descriptive but because it wasn't precise. It was an XML rendering of internal Office file formats, and its description of terms were no better than internal documentation. Something like the TNEF format is much closer to a descriptive document, since it spends a lot of time discussing the differences between Outlook 2007, Outlook 2010, and Outlook 2013 at various steps.
- deleted 10y ago[deleted]