Slashdot stories can be listened to in audio form via an RSS feed, as read by our own robotic overlord.

 



Forgot your password?
typodupeerror
Books Businesses

Is HTML5 the Future of Book Authorship? 116

Posted by samzenpus
from the forget-the-paper dept.
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."
This discussion has been archived. No new comments can be posted.

Is HTML5 the Future of Book Authorship?

Comments Filter:
  • Obligatory answer: (Score:2, Informative)

    by Anonymous Coward

    No.

    • by catmistake (814204) on Friday September 20, 2013 @12:18AM (#44899617) Journal

      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: (Score:2, Insightful)

        by phantomfive (622387)
        Indeed, the answer to the question is probably the same as the answer to, "Is HTML5 the future of application programming?"
        • Re: (Score:3, Informative)

          by gigaherz (2653757)

          "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 prese

          • by gigaherz (2653757)
            Why are there no bullets in my <ul>?
            • Re: (Score:2, Funny)

              by Anonymous Coward

              HTML is not the future of slashdot

              • by Anonymous Coward

                I know there are many that desire a site to have a good visual design, but after using slashdot and so many other forums, I find I could not care less about what something looks like. I prefer fast loads and pages that behave to good looking sites. Slashdot, before the recent design change, is very good looking IMO, but neither the new design nor the classic design behave well. You know what I mean. Function preceeds form, dammit. Who gives a shit what something looks like if it behaves like it has multiple

                • evidently you don't feel that bullet points are a useful bit of functionality. fair enough, but there are plenty of people who would disagree with you on that one...

              • by unixisc (2429386)

                HTML is not the future of slashdot

                Nor even its present, by the look of it.

                Okay, I understand why /. doesn't support Unicode, but for the life of me, I don't understand why it can't support simple tags like UL or OL. Especially since the latter is simply having numbered listings. I've seen non-technical blogs support bulleted & numbered lists better.

            • by zidium (2550286)

              CSS, dummy.

              Seriously! You make such a technical answer about HTML and CSS and don't even know about list-style: none?! Come on!

              • by gigaherz (2653757)
                I know about them, I was just wondering why would slashdot have that style on the comments...
                • by nabsltd (1313397) on Friday September 20, 2013 @07:38AM (#44901571)

                  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.

                  • by gigaherz (2653757)
                    Actually, the comment boxes themselves are
                    • s. The thread view is done by nesting lists inside lists. But yeah, they forgot to reset the list-style:none for the comment content.
          • You might add that the problem of content/layout separation would be easily solved with a simple macro system.
            • Isn't it really all a SMOP [wikipedia.org]? (SMOP Means Onomatopoeic Polysyllabry)
              • No, all you'd need is a way to define constants. Then you could say something like:

                cHEADER_TEXT="blah blah blah blah blah blah"
                cBODY_TEXT="blah blah blah2"

                Then you could go on designing your page as normal, and instead of writing your text in the middle like you do now, you could stick the constant there. That way you could have two pages using the same constants but with completely different layouts, except it would be easy, unlike with CSS

                For browser writers it would only take half a day of progra
          • by liamevo (1358257)

            You can't vertically-align objects without scripting.
            Yes you can.

            You can't define a horizontal-scrolling element without scripting.
            I don't even know what you mean. Do you mean like a carousel? You can, but clunky.

            You can't define a non-scripted grid-like layout with proportional, fixed and content-dependant sizes mixed together
            Sure you can.

            It lacks a simple, integrated, templating and data-binding system
            So people build their own, mustache, handlebars, ember.js etc

      • by pr100 (653298)

        Surely the suggestion is not that authors compose and tag raw html... the suggestion is that they use editors/word processors that have html as the underlying document format?

        • 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.
      • by jandersen (462034)

        It's digital... who cares?

        Well, we should care a bit - certainly enough to not lose the ability to decode it and transform information to other formats. There's a science fiction story about this (or probably many), about how we digitized all our knowledge and then lost the key, so to speak.

      • You are looking too much from a technical viewpoint.

        If HTML provides good standards for monetization, (e.g., micropayments), and browser vendors follow them, then I see hope for HTML.

        On the other hand, big players may work against that. For example, Google, Facebook and Twitter have no interest in micropayments, as they depend too much on an ad-based world. Apple is too much into closed technologies.

        Perhaps Amazon could trigger a world of web-payments, but they really need the browser vendors on their side

        • Your argument then is that HTML is good for the promotional and sales portion of the venture, after all writing and editing is done.

          I agree it can be a useful tool in the larger set. It will never become the set.
      • Re: (Score:2, Informative)

        by YttriumOxide (837412)

        I completely agree. Having just published my first book (see my sig), I didn't spend any time considering the design/layout/etc until right near the end. The content is what was important to me, so I wrote that first. Once I was done with the content, THEN I laid it out, made it look "like I feel it should look", and produced a PDF which ultimately got printed to paper.

        For the eBook version, I used RTF which was then converted to the appropriate format (mobi) by the publisher. But again, it was a 'last

        • by mcgrew (92797) *

          I wrote the first several chapters of Nobots straight into slashdot's journal system. Later chapters were in Open Office and copied there. Changed layout quite a bit afterwards. Good luck getting full justification with HTML 5.

          Nobots (full book, what's at slashdot is a crude first draft) will be out shortly.

          • Good luck getting full justification with HTML 5.

            In which browser does CSS text-align: justify fail? This page [mozilla.org] claims it works in Firefox, Safari, and and Chrome since 1.0 and IE and Opera since 3.x. Could you explain the problem you ran into in more detail? Was the problem that lack of automatic insertion of &shy; (which turns into a hyphen at the end of a line) caused rivers of whitespace?

            • by mcgrew (92797) *

              It's been years since I've had a web page and haven't kept up with the newer language features. If that does give full justification, why aren't the newspapers using it? Paper editions do.

              • by tepples (727027)

                If that does give full justification, why aren't the newspapers using it? Paper editions do.

                Probably the lack of automatic hyphenation, as I mentioned, combined with a tendency for columns to be wider (in ems) on the screen than in a printed newspaper. The H&J settings need to be more aggressive for a 15em* newspaper column than for a 32em web column.

                * Based on an 11 pica standard column with an 8.8 point font.

      • by Kielistic (1273232) on Friday September 20, 2013 @09:03AM (#44902397)
        You should probably be aware that ePub is basically a zipped HTML document.
      • 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).

        I respectfully disagree, though not with all of what parent post is suggesting.

        Creative writing is best done in a simple text editor where there is no style and the author/revisionist wrestles with his muse in an empty and barren arena. No witnesses to the bloody mess, and no distractions from the work at hand. WYSIWYG is a terrible distraction when trying to birth some new text into the world.

        That said, the whole point of writing is to get one's words in front of some reader somewhere who will pick up on

        • by invid (163714)

          Having first learned to write manuscripts on a typewriter, I mimic the same style when writing a novel on the computer; using Courier New in manuscript format, underlining where I want italics and double-spacing everything so there is room to write comments on a hard copy. Some younger people have proof-read my work and actually thought that was the way I wanted it published. I had to explain that as an old-fogy, the presentation style is the last thing I do.

          Here's a shameless plug for my latest novel [amazon.com], whe

  • No, But Maybe. (Score:4, Insightful)

    by Great Big Bird (1751616) on Thursday September 19, 2013 @10:05PM (#44899185)
    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.
  • Unless the two dominant sources of e-books (Amazon and Apple) support it: no.

    • Re:Not really (Score:4, Informative)

      by Chrisq (894406) on Friday September 20, 2013 @03:00AM (#44900197)

      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 [arstechnica.com]
      It’s Official: iBooks Now Supports Epub3 [the-digital-reader.com] which is based on XHTML1.1 which introduced html5 features to XHTML

      • Actually, once XHTML came out, why do we have HTML being perpetrated at all, instead of switching over completely to XHTML?
        • Actually, once XHTML came out, why do we have HTML being perpetrated at all, instead of switching over completely to XHTML?

          I thought HTML 5 finally was valid XML? And without all the jiggery-pokery of XHTML and different DTD flavors.

          • by Chrisq (894406)

            Actually, once XHTML came out, why do we have HTML being perpetrated at all, instead of switching over completely to XHTML?

            I thought HTML 5 finally was valid XML? And without all the jiggery-pokery of XHTML and different DTD flavors.

            According to Wikipedia it is "... also an attempt to define a single markup language that can be written in either HTML or XHTML syntax. XHTML5 is [wikipedia.org] " the XML serialization of HTML5". I take this to mean that it can be written as XML without jiggery-pokery, but it is not mandatory to write well-formed XML.

            • Actually, once XHTML came out, why do we have HTML being perpetrated at all, instead of switching over completely to XHTML?

              I thought HTML 5 finally was valid XML? And without all the jiggery-pokery of XHTML and different DTD flavors.

              According to Wikipedia it is "... also an attempt to define a single markup language that can be written in either HTML or XHTML syntax. XHTML5 is [wikipedia.org] " the XML serialization of HTML5". I take this to mean that it can be written as XML without jiggery-pokery, but it is not mandatory to write well-formed XML.

              Gah. I dearly hope that well-formed HTML 5 is also perforce well-formed XML, and we don't have any more of that closing-tags-optional rubbish. I did see on the Talk page of that Wikipedia article [wikipedia.org] that HTML 5 might be identical in both HTML and XML/XHTML incarnations, with the only real difference being the mime type declared by the server. I'm not sure if I should hold my breath, though...

        • by tepples (727027)
          The HTML form of HTML5 is easier to hand-code, and once you parse it, its DOM is equivalent to that of the XHTML form of HTML5 anyway. And there are still UAs out there that don't support XHTML's MIME type at all but do support a subset of HTML5's HTML form.
    • by Anonymous Coward

      ePub is just HTML in a glorified wrapper. If you're going to make a work available in ePub then HTML should be a given. However it shouldn't matter at all what tool the author uses to compose his work. Presentation for publication and distribution is the job of editors.

      Now whether or not the author wishes to be the editor of their own work is another story. Some want that level of control, and others don't really care.

      Also sloppy piss-poor formatting in electronic publications means the editor isn't doing t

  • by Anonymous Coward

    These problems were solved years ago....

    • I will never go back to anything containing "TeX" in the name.

    • Re: (Score:2, Insightful)

      by 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 necessa

  • 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 [css3clickchart.com] claims that only "labs" (alpha?) builds of Opera support it, and that was probably before Opera switched to being yet another WebKit wrapper. Wikipedia [wikipedia.org] claims that most of the CSS3 paged media properties are completely unsupported in popular browsers.
    • Re: (Score:3, Interesting)

      by dgatwood (11270)

      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

      • by nabsltd (1313397) on Friday September 20, 2013 @07:44AM (#44901621)

        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 [idpf.org], primarily to allow assistive technologies to make better use of the content.

        • by dgatwood (11270)

          Yeah, but the semantic roles are mostly limited to things like buttons and other UI elements, which isn't really relevant for most books. Also, the entire notion of using attributes for semantic meaning instead of tag names is at best a hack to make things kind of work.

          HTML does have some semantic tags, mind you. The problem is not that you can't do semantic tagging, but rather that you can do non-semantic tagging. Most non-HTML output languages are inherently more structured than HTML is in its most mi

  • I don't think so... (Score:2, Informative)

    by djupedal (584558)
    I'm living large with XML'd e-pubs, but I do use a bit of HTML5 storage in a few of my apps.
  • by Anonymous Coward on Thursday September 19, 2013 @10:23PM (#44899281)

    Two weeks ago I published the web edition of the Graphics Codex [graphicscodex.com]. 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.

    • by catmistake (814204) on Friday September 20, 2013 @12:34AM (#44899655) Journal

      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.

      • by dargaud (518470) <[ten.duagradg] [ta] [2todhsals]> on Friday September 20, 2013 @05:14AM (#44900825) Homepage

        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.

        • by Oligonicella (659917) on Friday September 20, 2013 @08:21AM (#44901949)
          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.
        • by Anonymous Coward

          It hardly ever reflows properly.

          PDF doesn't "reflow" ever, period. Its not meant to... what it gives you is identical content everywhere it is used, no matter the platform. It is not necessarily ideal for eReaders, unless to want an eBook that is identical content to the printed version. I have found I prefer PDF versions of magazines because I prefer content that identical to the published version, even though the copy appears small on a small screen, and I have to magnify the page to read it and scroll around.

  • You can't easily specify printout options with HTML for one...
  • Because we're in for a sustained campaign of "all documents in the cloud" opinion pieces driven courtesy of cloud providers and companies that make money off of sniffing your panties, like Google.

    HTML 5 as of now represents a regressive step in page layout and rendering relative to what can be done by other word processing technologies. It's good for making web pages but as a universal lingua for all written communication it's lacking a lot. Also the really interesting things around the evolution of written

  • So how will this revolution make sure that the writer gets paid? As Harlan Elison says, Pay the Writer [youtube.com]! Don't get me wrong, I love writing and am not looking for top dollar for my own small efforts, but all I see is sites wanting free writing. I do it myself, but at least I don't have ad dollars coming in off the backs of the few people who contribute to my site.
  • SO how did chm work out? You see many books in that.

    Put simply the stuff I am writing is not in HTML format and never will be if I can help it.

    • SO how did chm work out? You see many books in that.

      CHM??? chm is a piece of utter garbage by Microsoft, intended as Compiled HTML Help.

      HTML5, on the other hand, is actually rather decent.

      • HTML5 on the other hand, is a bit of a bitch if you want to embed resources in a single file for distribution.

        CHM is pretty much an archive designed to store HTML files and supporting artefacts, along with indexes for searching. Nothing really stopping you using HTML5 in a CHM file, since it is rendered with IE anyway.

        • HTML5 on the other hand, is a bit of a bitch if you want to embed resources in a single file for distribution.

          It's not impossible. You can use the data: URI scheme to embed Base64-encoded files. It increases the filesize considerably, though.

  • You should check out BookJS ( http://sourcefabric.github.io/BookJS/ [github.io] ). It's made so you can design book pages in the Chrome browser and create PDFs using the browser's print-to-pdf function. it can handle footnotes, floats, margin notes, etc. . It's being used in Fidus Writer ( http://www.fiduswriter.org/ [fiduswriter.org] ) and Booktype ( http://www.sourcefabric.org/en/booktype/ [sourcefabric.org] ). However, going on with Fidus writer, I am less sure that book editing can be directly done woith HTML, without a large amount of Javascript, ba
  • by Tom (822)

    HTML5 is great for text. Like, basically, any markup language. If you write a novel or something, you basically just need text with less than a dozen markers for where chapters start and such. Then you send it to your publisher and they'll do their part.

    Now if you write something more interesting, then HTML5 isn't the solution, mostly because there aren't any good editors and readers/browsers still don't guarantee you a good result. For stuff that requires DTP, you are better off with PDF today, and probabl

    • Re: (Score:2, Informative)

      by nabsltd (1313397)

      If you write a novel or something, you basically just need text with less than a dozen markers for where chapters start and such.

      There are very few novels that don't use some sort of alternate text (italics, bold, etc.), so that has to be noted in some way.

      Then, you have structures like in-chapter breaks, first paragraph differences, date/location notations, chapter name/number, etc., where it's very likely an author has an strong idea for what the final result should look like. At the extreme end, you have novels like The Andromeda Strain which is as complex in specific formatting requirements as a math textbook.

      The primary differe

      • by Tom (822)

        There are very few novels that don't use some sort of alternate text (italics, bold, etc.), so that has to be noted in some way.

        Much fewer than you think, that seems to be a curse of modern times. I could quote a friend of mine who works in the publishing industry and said something like "bold does not belong into a novel, EVER".

        But yes, that and some titles and such are what a semantic markup language needs, and is why I said it needs some markers instead of saying plain text would do.

        And, for that, HTML is a lot more tedious than a WYSIWYG word processor.

        Frankly, 99% of the people using a word processor don't know how to use it. Everyone who submits a manuscript in Word format where he used individual

  • I definitely think HTML, CSS and JS is the future of publishing. In fact, I'll go ahead and say the transition has already started. If you look at what's happening right now, book sales, magazine and newsprint subscriptions are on the decline in favor of information gathered from the internet. People generally don't like picking up a book to look up some info when Google is readily available and decreases the amount of time required to get said information. Also, writers will not have to learn anything diff

Old programmers never die, they just branch to a new address.

Working...