- TeleRead: News and views on e-books, libraries, publishing and related topics - http://www.teleread.com -

Reader asks: Why not use HTML instead of ePub?

Posted By Paul Biba On March 22, 2009 @ 3:27 pm In ebook,ePub,Paul Biba | 37 Comments

images.jpgI got an email from Bill Smith [1] asking the below question. It’s a good question, and something I’ve thought about myself. Not being that sort of techie, I don’t know the answer. Perhaps some of our more technically inclined readers can answer Bill’s question in the comments section. I’d like to know the answer, also. (Update: And Joseph Gray has provided a good one [2]. – D.R. [3])

In the "format wars," I’m idly wondering why HTML is not the defacto ebook format. I don’t mean to harsh on epub but the big selling point of epub is "it’s a standard format, just converted XML/HTML." My question is "what’s wrong with HTML in the first place?"

Epub requires a dedicated piece of software and it’s not *quite* an industry standard because some dedicated readers can’t digest it.

HTML can be read by any PC–with the explosion of netbooks and expectations by year’s end of sub-$100 netbooks and Android-based mini-laptops, this is a HUGE market.

HTML is easily saved to .txt from within most browsers.

HTML is DRM free and can be saved and backed up to your computer or USB drive at will.

IPod touches, Iphones and many cellphones can read simple HTML pages.

Users can adjust text font, size and text/background color combination to suit their personal preferences.

Many of the dedicated ebook readers can decipher HTML…and honestly, anyone who has a dedicated ebook reader has a PC and easy access to conversion software from HTML/txt to whatever ebabel format their device uses.

In short, it seems to me that epub may someday be the standard ebook format…but HTML is the logical universal format that *is* used and understood around the world. It’s available right now, not someday.

(Not meant as a slam or an insult on epub…I just don’t understand its advantages. I don’t see why epublishing is pushing epub instead of simply embracing HTML.)


37 Comments (Open | Close)

37 Comments To "Reader asks: Why not use HTML instead of ePub?"

#1 Comment By Joseph Gray On March 22, 2009 @ 4:22 pm

OK, I’ll take a stab at it. For devices that don’t (yet) support epub, HTML is a good choice. However, there are some problems with HTML for ebook use that epub tries to address.

HTML: What version of HTML do you mean – 3.2, 4.0, or the usual tag soup that doesn’t conform to any spec? epub specifies XHTML, which is a strictly defined version of HTML that does away with the tag soup and sloppy coding.

With a novel, do you want to create one huge HTML file or break things up into smaller files (chapters are a natural)? What if you want to include images or other files with your HMTL ebook? How do you package things so that the files stay together? Hey, how about using Zip, which is a very popular compression method to package everything? Many existing ebook reading softwares can natively handle Zipped ebooks. Not coincidentally, epub uses Zip compression as the package.

With your HTML ebook, do you want some formatting? How about using CSS, which is what almost all web sites use these days? epub specifies a particular subset of CSS to be used.

What I am trying to point out is that epub is not some entirely new species. It is based on existing standards and removes many of the ambiguities and sloppy practices common in generic HTML usage.

epub does add a few things as well. The contents and reading order can be specified, as can metadata that provide additional information about the book.

If you are using a device that does not yet support epub, no problem. Just unzip the epub file and you can open the XHTML files in any modern browser or reading software that can handle HTML. Worse case, you may have to rename an .xhtml extension to .html.

Reading an epub on a non-epub capable device will be a slight nuisance, but no more than any of the “conversions” that you mention above (probably less so).

The beauty of epub is that it is a standard that builds on existing standards and gives us a common and easily accessable format for ebooks. Is epub perfect? No. It was afterall designed by committee :-) It does not address several points that are important to properly represent some type of books and some types of users. These points have been discussed and will have to be addressed in a future version of the epub specification. However, I think that the current version of epub is a very good first attempt and very usable as is.

We have seen a very rapid and widespread adoption of epub by publishers, e-reader software and end users. This is a good thing. The goal of epub is to diminish (eliminate?) the need for the many incompatible ebook formats that now exist. Think of epub as the MP3 of the ebook world. Sure, there are other audio formats in use, but every audio player can handle an MP3 file. Would you want it any other way?

#2 Comment By Rui Hanazawa On March 22, 2009 @ 5:27 pm

What Joseph said. It’s hard to standardize on HTML because it’s freeform. Epub is basically a zip file containing an HTML file (or files in case it’s broken down into chunks) with stricter rules regarding structure. It also contains additional files that give information about the book such as publisher, subject, cover, table of contents, etc.

#3 Comment By Joshua Tallent of eBookArchitects.com On March 22, 2009 @ 5:52 pm

Well said!

#4 Comment By Hadrien Gardeur On March 22, 2009 @ 7:22 pm

Yeah, most of the times, individual flows in ePub are basically XHTML+CSS (you don’t see DTBook that often). But XHTML itself is not enough, you need:
- a container to distribute everything (OCF)
- metadata about your book (OPF)
- to define the order of the flows (OPF)
- the fallbacks if you need any (OPF)
- the table of contents in a more meaningful way than just inline HTML (NCX)
The list could go on and on…

If you have a browser available, it’s fairly easy to use it to build an ePub reader. For example on the iPhone, Stanza uses Webkit to handle the XHTML+CSS.

#5 Comment By Joseph Gray On March 22, 2009 @ 7:56 pm

Hadrien, what you say is true, but I was trying not to overcomplicate my explaination with the technical details. As you have pointed out, an epub reader can certainly be built on an existing browser. Openberg Lector for Firefox was the first implementation that I know of, although it hasn’t been updated in some time.

#6 Comment By Bill Smith On March 22, 2009 @ 8:17 pm

Thank you all for the clarification (and in a way that a non-techie like me can understand). I was curious and now I think I understand some of the advantages of epub (although for my own books, I expect to stick with html files for now).

Joseph Gray, it’s funny you mention epub as being like mp3 for ebooks. When I submitted the original question, I imagined that html would be like mp3 for ebooks–technically less sophisticated than other formats but easily accessible to a wider, more mainstream audience.

#7 Comment By Vicki On March 22, 2009 @ 9:44 pm

> and honestly, anyone who has a dedicated ebook
> reader has a PC and easy access to conversion
> software from HTML/txt to whatever ebabel format
> their device uses.

If ebooks are ever going to be a mass market, it’s not going to be by selling ebook readers just to us and people like us.

The potential mass market for ebooks is not the people who have easy access to conversion software. Henry Ford did not get rich selling cars just to the people who knew how the internal combustion engine works.

My best friend has a computer that she uses for email, to write her daily journal, and to visit in total less than 10 websites in a week. Her “easy access” to conversion software would be to call me since I’m the one who unpacked every computer she’s ever had and I do all the software updates for her.

But she wouldn’t call me because she couldn’t care less that such a thing as conversion software exists. She’s perfectly happy with her Kindle. That’s the mass market.

Vicki

#8 Comment By Joseph Gray On March 22, 2009 @ 9:44 pm

Bill, I’d like to make a suggestion about your use of HTML. Sticking with HTML is fine, but you should seriously look at using XHTML 1.1 as a standard method of coding your ebooks.

There really aren’t too many differences between XHTML and HTML (of any variety). Mainly XHTML defines things more cleanly and does away with the poor structure that HTML permits.

The advantage of using XHTML 1.1 now is that you will be ready for epub when the time comes. Also, XHTML should convert to other, old formats (Mobipocket, Lit, etc.) with fewer problems.

Although you will be coding your markup to XHTML 1.1 standards, you can still name your files with the .html extension. And because these files will basically be a cleaner form of HTML, they should display just fine in modern browsers.

For an example, look at the source here: [4]. This isn’t anything fancy, but it shows how you can use XHTML today, as a replacement for generic HTML.

The rest of the online book is poetry, which required some extra formatting, but the Introduction I pointed to will give you the idea. I did the online version first and when I created the epub, I only had to remove a few things that weren’t necessary (margins, CSS hacks for Internet Explorer and the javascript for Google Analytics).

One last thought. Notice that I do not specify a font size in my stylesheet. I did this on purpose. Also note that you can “zoom” in or out in your browser and the text still displays well at just about any size. This is all part of accessability.

#9 Comment By Janaka Stevens On March 23, 2009 @ 12:10 am

I would think the main reason for ePub is to facilitate DRM in a flowable format.

#10 Comment By Jon Noring On March 23, 2009 @ 6:22 am

Janaka, as one of the contributors to the specs which underlie ePub (namely, OPS, OPF and OCF), the “main reason” for ePub is certainly NOT to facilitate DRM. Being able to apply DRM has always been of interest to publishers (one can call it a requirement — one among many), and this certainly contributed to the final OCF spec, but this does not translate to “main reason”.

With regards to “why not just HTML”, the previous commenters to this thread (notably Joseph) have explained this well.

About why XHTML 1.1?: Note that a content document which is valid to XHTML 1.1 *is* HTML, and I agree with Joseph’s suggestion that XHTML 1.1 should be used for formatting ebook content, whether incorporated into ePub, or used as input for other formats (e.g. Kindle). I master all my ebooks in ePub-ready XHTML 1.1, and produce Word DOC and PDF, as needed, *from* the XHTML 1.1, not the other way around. The HTML produced from Word and similar word processing formats is simply gawd-awful.

#11 Comment By Michael Pastore On March 23, 2009 @ 8:11 am

A very good question — and very good answers have been given in the previous comments.

You want your train tracks in New York to be the same size as the tracks in Chicago and L.A. … To summarize the previous comments: ePub is not just any HTML, it is valid XHTML. XHTML is a signicant advance over HTML, for many reasons … [5]

In addition, the metadata in every ePub ebook will help librarians and booksellers to organize large collections of ebooks, and — ultimately — will help the ebook-reading audience to find the ebooks we want to read.

Do you have the latest edition of Michael Pastore’s bodice-ripping love story: “How I Found Rome-Ants at a Picnic In Italy” ?, or one of the earlier and outdated editions? … In the ePub format you will know this right away. In HTML you would need to open the file and look at this information somewhere in the file header … if the author-publisher has bothered to include it.

ePub ebooks gives us more information. True, they are a bit more complex than simple HTML — but it’s worth the trouble.

Michael Pastore
50 Benefits of Ebooks

#12 Comment By pond On March 23, 2009 @ 8:55 am

I do (kind of) understand the thinking that went into designing the epub standard. Basically it’s the additions that others have mentioned in comments above.

However…

well, what if you built a standard, and nobody could use it? that’s been the rap on epub so far, and it remains a big stumbling block. How wonderful it would be if epub were a real, de facto, universal standard, instead of just a dtd devised by a group of wonks! Then writers could write in it, reading software would be universally on all PCs as well as smartphones and ebook devices, publishers would take it as their preferred form of submissions, and the whole chain of content creation publishing and distribution would use this one magical standard.

Maybe we will reach that point someday. I hope we do.

In the meantime, Joseph Gray’s comment rather makes it seem as though plain-vanilla HTML were broken. As though we couldn’t be reading this or any other page on the internet! Whereas in practice the opposite is true: almost everybody can read a page in HTML, and only a very small niche crowd can read a native epub file, and only if they have a special device or if they have downloaded and installed special, uncommon, software. And as far as I know, nobody can actually write his book, article, or poem natively in epub.

So far epub supporters have done a good job in designing the spec. Now they have to go farther, and see that the rest of the world can use it.

#13 Comment By Jon Noring On March 23, 2009 @ 10:30 am

I disagree with pond saying “nobody could use” ePub. First, “nobody” is a pretty strong word, which is demonstrably false.

As noted ad nauseum, ePub is based on XHTML, CSS, JPG/PNG and ZIP. Nothing more need be said on this as there are billions of web pages out there using all these standards (well, ZIP is not used in the web milieu, but nevertheless it is also ubiquitous.)

Now if pond has some ideas as to how to create the true universal format that enables perfect and simple authoring applications for all types of book content, and enables reading systems to optimally work on all conceivable platforms (both visual and aural), I’m all ears.

#14 Comment By Rui Hanazawa On March 23, 2009 @ 11:36 am

I’ve seen several HTML pages (even not very complex ones) that render quite differently when viewed on different browsers. Again, the problem with HTML is it’s not uniform. HTML by itself isn’t broken. It’s the way people and software are coding it that’s the issue. Just try opening HTML files saved by Microsoft Word in Notepad or any similar plain text viewer and you’ll see the tag soup mess Joseph was referring to earlier. I certainly wouldn’t want to load something that complex on an ebook reader with a slow processor.

What we’re seeing now is similar to the digital music distribution scene a while back. Different stores used different types of DRM which prevented playback of music on various players (can’t play iTunes-bought music on Zune or secured WMA on iPod). Didn’t really help the music biz and peer-to-peer mp3 sharing was still rampant. Eventually, Amazon opened its DRM-free mp3 store and now, Apple iTunes is selling its entire library DRM-free.

I think the difference with mp3 and epub is mp3 was already an existing format (with a clearly defined structure and specifications for metadata, etc) prior to mass adoption. Another, people were already sharing mp3s before most of these online music stores popped up. We’re only getting epub after so many other companies have released their own proprietary formats (LIT, MOBI, eReader, Secure PDF, etc). Obviously, these companies have vested interest in seeing their own format succeed so I don’t see them going out of their way to support epub.

Yes, epub isn’t the de facto standard yet. From what I can see though, that is the end goal of epub – to become to ebooks what mp3 is to digital music. The problem is adoption. There are more ebook readers now that support it, both software and hardware, but not all of them. Unfortunately, designers of the spec can’t really force it down publishers’ throats. We, as consumers, are the ones who have a say. With our buying dollars (or euro, pound, yen, or whatever the case may be), we can show that we want an open format, preferably one that is unencumbered by DRM. If widespread adoption of epub by consumers / end-users can be achieved, companies (publishers, device makers, etc) will eventually have to support the epub format.

#15 Comment By Jon Noring On March 23, 2009 @ 11:55 am

I agree with Rui that HTML exported from Word is a horrible “tag soup”. But XHTML produced directly (e.g. in a text editor by applying tags to base text) is very simple and elegant. In fact, in my publishing business I find it easier and faster to master in XHTML than Word. As noted before, Word is an *awful* mastering format.

#16 Comment By Michael Pastore On March 23, 2009 @ 12:05 pm

I have to confess that, years ago, when I first heard about a new standard for ebooks — I was thinking about Shaw’s saying: “All professions are conspiracies against the laity.”

I wondered if this new standard would just be a way to take something simple, and over-complicate it, and create yet another vehicle for the big companies to squeeze more money from the unwary consumer.

All my fears have been dispelled — I now have not the smallest doubt that ePub is a great idea. A great idea for everyone: for authors, publishers, library professionals and readers. (By “readers” I mean human beings, not ebook reading devices.)

pond … It sounds to me as if you would like:

A. The capability to write your “book, article, or poem natively in ePub”
and
B. Easy ways to read ePub

A. Easy ePub conversion is coming very soon. In fact, there is at least one ePub converting tool, from Azardi, that is available for “personal use”. More ePub coverters are on the way, and soon it will be simple to take any RTF file (or other common format), and convert to ePub with a few clicks.

Until then, you can make your own ePub using freeware — I just did — it took me a few days to learn — with help from my younger assistant, and from various people on the web, who generously answered my questions and looked at my files.

ePub is a blessing for authors and publishers: we would love to be concerned about making ebooks in 1 format, not 6 or more.

B. An easy way to read ePub … that’s here already. You don’t need a dedicated ebook reading device: you can read ePub on your own computer, or online.

Here’s a page that lists ways to read ePub ebooks — and all of these are free:

[6]
read-epub/

Michael Pastore
50 Benefits of Ebooks

#17 Comment By Michael Pastore On March 23, 2009 @ 12:14 pm

How to Read Epub Ebooks ( free tools for reading ePub )

[7]

This link works; the link in my previous post is broken due to the line length.

MP

#18 Comment By Greg M. On March 23, 2009 @ 2:57 pm

Word to HTML does indeed produce a tag soup of worthless extra code, however it can easily be converted into highly readable ebooks just about every time. To me that is something very important. On the filp side, PDF almost always makes a mishmash of poorly formated text in an ebook: usually unreadable, unless the reader is willing to overlook errors.

So the real question is: Can epub format as nicely and easily as HTML? If so, then the next major hurtle will getting devices (Kindle, Sony, iPhone, etc.) to read epub. Compatibility with the desktop or online is nearly worthless for long texts. Could you read Peter F. Hamilton’s Night’s Dawn Trilogy (3000+ pages) in epub on your desktop? Technically, yes, I suppose so, but few people would try it, whereas there is no problem on the Kindle or Sony. I can’t speak for every one, but for me anything more then 5 to 10 pages is too much to read on a desktop or online.

Unless epub can create nicely formatted texts on the popular devices it will not become the mp3 of ebooks.

And there really should be one general format.

#19 Comment By Rui Hanazawa On March 23, 2009 @ 3:30 pm

@Greg
As has been commented several times, the format used for the actual content in epub *is* XHTML, albeit limited to a certain subset and with particular rules to follow to make things uniform and parsing easier for devices. Basically, create a strictly coded HTML document, create an XML file containing ebook meta information, create another XML file containing the table of contents/chapter information, add cover images and zip them into one file and you’ve got your epub. Of course, that’s a bit oversimplifying things but you get the general idea.

The Sony ebook readers and the iPhone/iPod Touch already have support for epub. In the case of the iPhone/iPod, Stanza by Lexcycle is one of the apps available which you can use to read epub and that’s what I use. I do believe all standalone ebook reader apps available on iTunes support epub.

Kindle, well Amazon owns the mobi DRM, I think, so that one might be a bit more difficult. One of the ways Amazon will be forced to include native support of epub in the Kindle is if epub became the industry standard.

#20 Comment By Tamas Simon On March 23, 2009 @ 4:07 pm

OK… let’s rephrase the original question: what’s the advantage of ePub vs a tarball (that’s like zip ;-) ) of HTML files and the rest of the stuff that goes with it?
In my opinion: nothing.
As for XHTML… there is no benefit of that whatsoever.
Just look at where the standard is evolving: HTML5
not XHTML2.0
Why not use standard web technologies for ebooks?

I think it would be better to have an open-source effort with a strong lead (Adobe?) instead of the design by committee.
Also it would make more sense to me to standardize style-sheets. The style-sheet would be implemented differently for different devices taking into account their characteristics.
So if I want to write a book I just worry about the text, select a few predefined styles and it would actually look good.

#21 Comment By Rui Hanazawa On March 23, 2009 @ 5:33 pm

tarball, if compressed, may be more difficult to process for ebook readers, since they would need to uncompress the whole file before you can start reading. Remember, these devices tend to be somewhat processor and memory-limited.

Aren’t HTML5 and XHTML5 being developed concurrently?

Anyway, HTML vs XHTML, pretty sure there are others more knowledgeable who can comment on this but here’s my 2 cents. HTML is too darned permissive. That really is the basic problem. When you look at it XHTML is just HTML with additional markup – useful since it makes reading easier for *machines*. Yes, the browser on your Core 2 Duo PC makes quick work of HTML files (even badly coded ones), but the same can not be said for, say, the Sony PRS-505 with its 200 MHz processor.

You’re proposing a new format which will only add to the confusion. epub’s not perfect but it’s a start. Refinements can come later. It’s extensible so it shouldn’t be that difficult to modify.

Also, with increasing popularity, there will be more tools available for epub creation and editing.

More content is being published in epub. Now if only we can convince publishers to get rid of DRM while they’re at it.

#22 Comment By Garson O’Toole On March 23, 2009 @ 6:09 pm

IMHO a fully successful ebook format should be integrated with the rest of the web. For example, major browsers like Firefox should be able to read it. (Joseph Gray mentions Openberg Lector for Firefox but suggests that it needs an update.)

Links between ebooks and links in and out of ebooks should be supported. It would be wonderful if you could specify a link in an ebook or webpage that would take you to a precisely specified word sequence within another ebook. Links like this would allow the incorporation of ebooks into the general conversational structures of the web. Maybe one of the knowledgeable commentators on this thread has a viewpoint on this topic. Is it already possible?

#23 Comment By LuYu On March 24, 2009 @ 1:37 pm

I would like to add that I agree that HTML is probably the most versatile and widely available format for e-books (that is why my program converts text files to HTML). However, the qualities of mobile browsers vary greatly.

In my experience, Opera is the best. NetFront and Ericsson’s stock browser are usable but lack important things such as non-Roman encodings and fonts with special characters. All three of these browsers have the ability to constrain text to the available screen width.

Bad mobile browsers are: minimo (does not work, really), Konq-e and other webkit browsers — including Safari from what I have seen (lack ability to constrain text), Android’s browser (also webkit), and PocketIE (sssllloooww). Except for PocketIE, none of these browsers can access the local disk (Android’s browser actually refuses to reconise file:/// links!!), so if you wanted to save your HTML e-books to your memory and read it from your phone, you are out of luck.

I have never seen a device, PDA, or phone that had the ability to access zip or any other type of archives. This is unfortunate because transferring files as a unit is always nice. If this feature existed, I doubt very much that dedicated e-book software would even be needed.

#24 Comment By Joseph Gray On March 24, 2009 @ 6:38 pm

LuYu Says: “(that is why my program converts text files to HTML)”

Not having used your script, what variety of HTML does it generate? As discussed above, XHTML 1.1 would be a good guide to follow, as you get clean, unambiguous code. I’m not setup for Perl right now – how about posting a link to a sample of your script’s output for the curious?

LuYu Says: “I have never seen a device, PDA, or phone that had the ability to access zip or any other type of archives.”

There were Zip utilities for PDAs at least ten years ago. Also, uBook has had the ability to handle Zipped ebooks for as long as I remember. Not owning a PDA any more, I no longer use uBook.

#25 Comment By LuYu On March 25, 2009 @ 2:06 am

[8]

I know my program is not extremely user friendly. I would like to get around to creating a GUI someday (is there anybody that would like to help with that?), but for the time being, all one has to do is create a [9] (named after the site named after the man) and type:

perl libreria.pl [your book file].txt

Depending on the layout of the book (and this varies a lot!), it should work without much other information and generate a folder named with the title of the book. If not, it can be told what to look for with HTML style attributes in the gutenberg tag. The folder can be copied to any device with a web browser that can access local files. The files should display nicely on any small screen.

As for the zipped files, were those addon programs? Or was zip a stock feature? I would really like to see Linux phones include gzip and bzip2 as well as zip. I would also like to see browsers read archives as folders. That way, the files could remain as a compressed unit, but be accessed as uncompressed. On modern phones, the speed difference should be negligible. That would pretty much eliminate the need for ePUB and dedicated e-book software, though.

Also, the lack of archives makes transferring files from one device to another over Bluetooth difficult. Since I do a lot of testing, every restriction that costs me time makes things much more difficult. Not only that, but for Public Domain books, why not have the ability to easily share them with friends?

#26 Comment By Robert Nagle On March 25, 2009 @ 2:38 pm

It’s easier to manage one file per book than 25. Imagine if you had to buy 300 separate pieces of paper every time you wanted to buy an ebook. You would quickly misplace page 82 and get the chapters mixed up and accidentally throw away a dozen pages in the trashcan.

#27 Comment By LuYu On March 25, 2009 @ 11:39 pm

I asked yesterday about the availability of zip compression on Android. Yes, it exists. However, their broken webkit browser does not access local files “as a matter of policy”, and the browser has no support for zip. So, basically, a dedicated e-book reader would have to be installed or another web browser just to read files on the local hard drive. Also, there is no file manager. That has to be installed as well.

I am very disappointed with Android’s lack of support for basic features.

#28 Comment By Miriam English On June 9, 2010 @ 8:58 pm

It is amazing that people constantly parrot this thing about HTML being a tag soup, and XHTML being somehow superior. It is true that XHTML standardises, more or less, but is not really an advantage if it just complicates matters further and encourages ridiculously verbose markup, which it does. Old HTML (pre-frames and pre-CSS) works fine everywhere, even on the most lowly of devices or simplest of web browsers. There is no reason why ebooks should have access to gazillions of formatting possibilities when they will almost never be used*. Sure, people who write bloated, slow-to-view web pages love CSS and a zillion tags at their fingertips, but for ebooks they are simply unnecessary.

There only 2 rationales for epub that I can see: the zip container to carry multiple files (images, etc), and for foisting DRM onto readers. Oh, I guess there is a third rationale: to make sure consultants have a continuing source of income producing ever more complex formats.

The container thing is fine. It is easy to deliver html ebooks as zip files.

The DRM argument should be dead already. Any format that survives any length of time into the future will not have DRM. All locked books are absolutely guaranteed to lock their owners out later.

The consultant thing? I’m kinda okay with them endlessly thinking ever more complex formats, but there really is no reason why we should mindlessly follow them.

There’s one slight exception to the my dismissal to the extra things in XHTML, and that is the possibility of using mathML, SVG and a couple of other such extensions, which would be a good thing. Unfortunately they are still pretty-much vaporware even though the syntax for them is well developed. Commercial markets don’t like non-proprietary formats.

Sadly it all comes back to finding a way to squeeze more money out of the end-users or the publishers.

#29 Comment By Jon Noring On June 10, 2010 @ 12:13 pm

@Miriam’s latest comment is mystifying in that XHTML 1.0 is essentially HTML 4.0 which conforms to the markup rules of XML. That is, XHTML 1.0 does not add anything to the vocabulary. XHTML 1.1 is a little more constrained XHTML 1.0.

Thus, XHTML is NOT inherently more “verbose” than HTML. If one observes “verbosity” in an XHTML document, it is not because it is XHTML, but rather that it is poor markup probably converted from Word — such verbose markup can be expressed in HTML 4.0 just as easily.

#30 Comment By DensityDuck On June 10, 2010 @ 3:49 pm

@Miriam:

“Old HTML (pre-frames and pre-CSS) works fine everywhere, even on the most lowly of devices or simplest of web browsers.”

Exactly. But…

“Sure, people who write bloated, slow-to-view web pages love CSS and a zillion tags at their fingertips…”

And guess who designs ebook readers.

#31 Comment By Joshua Richardson On June 19, 2011 @ 5:46 pm

Someone asked about a converter from epub to html. Here is a perl script I wrote to do that, in case anyone wants it:

[10]

#32 Comment By someguy On March 10, 2012 @ 5:36 pm

> Janaka Stevens says:
> March 23, 2009 at 12:10 am
> I would think the main reason for ePub is to facilitate DRM in a flowable format.
AGREE + 1
Everything is about economy. This is why there are so many silly ebook formats other than PDF, HTML, and plain text.

In my honest opinion, with HTML5′s growing mature, EPUB will be useless except for DRM.

#33 Comment By Leja Medina On April 13, 2012 @ 1:41 pm

My website is in basic form on Yahoo Small Busines and confessing I’m not into all this HTML/XML techdom lingo. Have to agree with the status quo a child sings to its parent ” … but why?’as to ePUB format. Now have time to put already written books online. Thought it would be a leap and bound into online authorship, … now ePUB. Is there a way around it? Word 2010 allows save into PDF format, as well as a PDF to ePUB converter. Is this sufficient, or do I have to learn how to master, HTML/XML in order to move forward? Please advise and many thanks for the listen.

#34 Comment By Skirual Kjirliw On December 18, 2012 @ 4:29 pm

I love html/css and I like epub, but I think there’s a little bit too much going on in epub-files to be able to edit them quickly with a solid text editor (like Notepad++). mimetype, meta-inf, oebps (content.opf, content.ncx) … could ‘ve been reduced to 1 and only 1 clear formatting-file counting for the whole zip/epub. Like a Windows ini file what. How to explain?.. – Just too much going on…

#35 Comment By -Andy- On December 18, 2012 @ 8:04 pm

“I think there’s a little bit too much going on in epub-files to be able to edit them quickly”

Well, if you use an ePub editor like Sigma, you don’t have to worry about all of that. Create the ePub file using whatever tool you want (I use a program called eCub to create the basic ePub file (You can feed it txt, html, or xhtml files) and then tweak it with Sigma. The end results work in iBooks, Stanza, and any other epub reader I’ve tried.

#36 Comment By -Andy- On December 18, 2012 @ 11:16 pm

Oops. Sigil, not Sigma. And it’s free.

#37 Comment By http://tinyurl.com/basebryan46687 On January 12, 2013 @ 3:18 am

I actually tend to go along with almost everything that was authored throughout “Reader asks: Why not use HTML instead of ePub?


Article printed from TeleRead: News and views on e-books, libraries, publishing and related topics: http://www.teleread.com

URL to article: http://www.teleread.com/ebooks/why-not-use-html-instead-of-epub/

URLs in this post:

[1] Bill Smith: http://www.billsmithbooks.com/

[2] provided a good one: http://www.teleread.com/2009/03/22/why-not-use-html-instead-of-epub/#comment-1024583

[3] D.R.: mailto:drNOSPAMteleread.com

[4] : http://www.zianet.com/jgray/nessmuk/forest_runes/introduction.html

[5] : http://www.w3.org/MarkUp/2004/xhtml-faq

[6] : http://summercampjobsusa.wordpress.com/ebooks/how-to-

[7] : http://tinyurl.com/http-EpublishersWeekly-net

[8] : http://libreria.sourceforge.net/library/

[9] : http://libreria.sourceforge.net/tag_definition.html

[10] : https://github.com/jric/epubtohtml

Copyright © 2010 TeleRead: Bring the E-Books Home. All rights reserved.