Is HTML5 the Future of Book Authorship?

occidental writes "Sanders Kleinfeld writes: In the past six years, the rise of the ebook has ushered in three successive revolutions that have roiled and reshaped the traditional publishing industry. Revolution #3 isn't really defined by a new piece of hardware, software product, or platform. Instead, it's really marked by a dramatic paradigm change among authors and publishers, who are shifting their toolsets away from legacy word processing and desktop publishing suites, and toward HTML5 and tools built on the Open Web Platform."

Comments

Obligatory answer:

[Anonymous Coward]

No.

Re:Obligatory answer:

[catmistake]

No.

This is correct. Mod parent up. No disrespect to HTML5, but it is not going to play any key role for "authorship," (which is, although beside the point, absolutely the incorrect term for the query; "publishing and distribution" is what is meant and what should have been used).

Any writing will be composed however the author feels most comfortable or creative, via pen and paper, dictation, typewriter, or word processor. They're NOT going to compose and tag HTML code for crissakes! I realize some of you supernerds have already, good for you, but no one cares. Write with the method you want to write with, Napoleon. GOSH!

Any written work, or book of images, or any combination of the medium, that is ever intended to be physically printed en mass, is going to be normalized as PDF no matter what the original form of the composition, even if it is a book of mathematics that is typeset in LaTeX, even if it is a small run of physical books and the majority of the tokens are sold as eBooks. If it is going to press, it will be PDF at some point. PDF is fine for digital distribution, but it is not ideal for eReaders, per se, unless the digital consumer desires a digital representation to be identical content to the printed book, in which case PDF is ideal.

IMO, there will be no single winner of the digital formats, because there's plenty of room for all of them, and then some. It's digital... who cares? Let's give the consumer some choice, it will make no significant difference in cost. Publish your book, print and sell the hardbound and softbound editions, and make available PDF, ePub, and Kindle format, Plaintext, DjVu, CHM, HTML, and sure, whiz bang HTML5 with JavaScript and video if you want... and any other versions for the digital consumer. There's no problem. Stop evangelizing the need for a solution to a problem that doesn't exist.

Re:Obligatory answer:

[gigaherz]

"Is HTML5 the future of ?" NO. If HTML is ever the future of anything, it will most probably be a later version, not 5.

In my opinion, HTML as we know it isn't fit for any truly serious work. The current model based on HTML, CSS and JavaScript is too clunky. Ideally, we would need a new content description (modelling) language, that's better designed at describing the content we want to see on the future of the "web", instead of it all being a hack around vertically-scrolling pages. We would need a new presentation language, that's better fit to describe to the User Agent how that content is supposed to look like, and either a much improved version of the scripting language, or a whole new language that's better fit to interact with both the content sources (model), and the presentation patterns (views).

I will list a few of the flaws I can't stand about the HTML model, roughly in order of how simple the concept is:

• You can't vertically-align objects without scripting.
• You can't define a horizontal-scrolling element without scripting.
• You can't define a non-scripted grid-like layout with proportional, fixed and content-dependant sizes mixed together.
• It lacks a simple, integrated, templating and data-binding system.

I will stop here since I'm apparently thinking of WPF too much.

Re:Obligatory answer:

[Anonymous Coward]

HTML is not the future of slashdot

Re:Obligatory answer:

[nabsltd]

Because it is a mistake.

Slashdot is using a <ul> as the basis for their dropdown menus, and for that they don't want any markers. Unfortunately, they seem to have added "list-style: none;" to selectors for all <li> elements.

Re:Obligatory answer:

[Oligonicella]

Answer is still no. I already have a word processor. I will use that. I can *export* to HTML if I desire. It would be one option only.

Re:Obligatory answer:

[Kielistic]

You should probably be aware that ePub is basically a zipped HTML document.

No, But Maybe.

[Great Big Bird]

The obvious answer to this is no, by the law of headlines. However, taking a look at the material does lend itself to the possibility of a good workflow. My own concerns would be with going from LaTeX now — there is some stuff on offer that could be quite excellent once further developed and supported.

Re:No, But Maybe.

[Anonymous Coward]

FFS. Can you please shut up about Betteridge's law of headlines?

No.

Almost nothing supports CSS3 paged media yet

[tepples]

From the article: "HTML5 is actually an excellent source format for producing paginated content, as the CSS3 Paged Media Module can be utilized to design the eqiuivalent of a standard book template for print." But which popular user agents implement CSS3 paged media? It appears to be so obscure that caniuse.com has no results for "paged". This claims that only "labs" (alpha?) builds of Opera support it, and that was probably before Opera switched to being yet another WebKit wrapper. Wikipedia claims that most of the CSS3 paged media properties are completely unsupported in popular browsers.

Re:Almost nothing supports CSS3 paged media yet

[dgatwood]

HTML5 is actually an excellent source format for producing paginated content ...

Which is actually completely untrue. HTML5 is a terrible source format because it is predominantly a visual markup, not a semantic one. You can sort of graft semantics onto it through CSS classes, but any such solution is inherently fragile and at the very least a publisher-specific standard, and likely a book-specific standard.

DocBook is an excellent source format. Its tags are semantic by their nature, which makes it much better as a source format, because it can not only be trivially converted to HTML5 for electronic publication, but also to LaTeX for print publication. It will also be easy to convert from that to whatever format replaces HTML5 ten years from now. And of course you can always add additional semantic tags to extend it if you need some book-specific or publisher-specific functionality.

Re:Almost nothing supports CSS3 paged media yet

[nabsltd]

HTML5 is a terrible source format because it is predominantly a visual markup, not a semantic one.

Actually, HTML elements in ePub have defined semantic roles, primarily to allow assistive technologies to make better use of the content.

Yes, HTML5 is the future of publishing

[Anonymous Coward]

Two weeks ago I published the web edition of the Graphics Codex. It is HTML5, with full LaTeX, SVG, and complex text layout for quality and Javascript + links for interactivity. This is a port of the earlier iOS edition that I wrote, which had similar features but wasn't HTML5. After having written several traditional books and seen them massacred by conversion to PDF, MOBI, and ePUB, I think that HTML5 from the start is the way to go for future publishing.

Re:Yes, HTML5 is the future of publishing

[catmistake]

I disagree, strongly. There is nothing wrong with HTML5. The issue is that it is a non-issue . In physical publishing, the industry has long adopted PDF. It is ideal for printing. PDF is here for the forseeable future. If your book is being pressed, it doesn't matter if it was previously Word, LaTeX, HTML5, chiseled in granite, or you used your finger on a sandy beach and made molds with plaster; it's going to be normalized as PDF before it hits the press.

For digital distribution there is room for all formats, and new formats no one has thought up... there is no purpose in even talking about this. Compose how you feel most comfortable; if physically publishing, send your content to the printers in any form you wish, they will normalize to PDF; make any format available that the digital consumer desires -- the cost of multiple formats is negligible... I imagine a perl or python or ruby script conversion for each format desired is all that is necessary, perhaps with some proofing to iron out wrinkles.

Enjoy your preferred method of composition. But as I pleaded above, please stop evangelizing the need for a solution where no problem exists. HTML5 is not the One True Format, and all others despair in their inferiority. Give consumers the choice of all or any that they wish to use.

Re:Yes, HTML5 is the future of publishing

[dargaud]

In physical publishing, the industry has long adopted PDF. It is ideal for printing.

...but it absolutely SUCKS for reading on any kind of screen. It hardly ever reflows properly. Even on a large PC screen it's a pain to read a multicolumn pdf: you are always going up and down because top and bottom of page are outside the screen. You can imagine on an ereader... It's also very resource intensive on phone/ereader.

Re:Yes, HTML5 is the future of publishing

[Oligonicella]

Both methods of publishing will be around for quite a while. He is correct about physical publishing, you may be right about digital. The two opinions are not exclusive.

Re:LaTeX anyone?

[Anonymous Coward]

The thing is that the current set of problems are not the same set that was solved so well by TeX and LaTeX. The focus of publishing is shifting from the printed page to the mobile digital screen. This brings a host of new issues and opens great new possibilities. Now we look for personalization, user interactivity, multiple media types, and the ability to link to and incorporate material from sources around the net.
    HTML5 though has a ways to go to generate the workflow and ecosystem necessary to support large scale publishing. As noted by Sanders though, O'Reilly seems to be making progress in using HTML5 for significant publishing efforts.
    The current publishing paradigm has significant momentum, not only in technology, but in how may practitioners think about the problem. An amazing amount of digital content carries over the same representations and style that was used when printing to paper. We can do so much more with modern tools.
    Of course I have thought that this shift was due for the past 15 years. Perhaps publishers will now look at the web as an opportunity rather than a threat.

Re:Not really

[Chrisq]

Unless the two dominant sources of e-books (Amazon and Apple) support it: no.

That would be a yes then:

Amazon infuses e-books with HTML5 power with new KF8 format
It’s Official: iBooks Now Supports Epub3 which is based on XHTML1.1 which introduced html5 features to XHTML