Is there any value to XHTML vs HTML?

[fdwojo]

Hello there, everybody. I've occasionally looked to these forums for my SIGIL and CALIBRE information searches, and been impressed each time.

As many Sigil users know, they dropped the BookView feature in it. Fortunately, for those of us who liked to see the WYSIWYG aspect, we know have PageEdit to help ourselves out.

My question is:

The description of PageEdit says it is an "ePub XHTML Visual Editor". Granted, I've used PageEdit with purely HTML ebooks. In fact, when I edit my EPUBs, I tend to change all text files to either HTML or CSS. If I see an XHTML, I generally rename it to HTML.

As such, I'm wondering whether (with respect to ebooks only) what value do XHTML files have over HTML files? Is there something I can do in an ebook with XHTML that I can't with HTML? I can easily image that for a website, XHTML might have some pretty nifty features. But for an ebook, is there *ANY* feature that XHTML has that can benefit me in an ebook?

If it helps, I (almost) exclusively use Sigil to compile and edit FanFiction stories (from websites like fanfiction_net) into a final, more pleasing aspect. Like many of you, I like having my ebooks as perfect and proper as possible.

Thus, is there any reason (for ebooks) to use XHTML? Or am I safe in making all my XHTML files into HTML and reading my ebooks in that way?

Thanks for any comments.

Frank

P.S. Is EPUB 2.0 good enough for the long haul, or will EPUB 3.0 have features that become a dealbreaker? Specifically, it seems that all the ebook readers are quite content to stay at EPUB 2.0 compatibility and EPUB editors seem to not dissuade users from creating EPUB 2.0 documents.

[DiapDealer]

Originally Posted by fdwojo

The description of PageEdit says it is an "ePub XHTML Visual Editor". Granted, I've used PageEdit with purely HTML ebooks.

No you haven't. PageEdit only edits/saves xhtml.

In fact, when I edit my EPUBs, I tend to change all text files to either HTML or CSS. If I see an XHTML, I generally rename it to HTML.

You're not changing anything but the file extension by doing that. An xhtml file with an html extension is still an xhtml file. It's not the name that makes it xhtml. It's the syntax.

Thus, is there any reason (for ebooks) to use XHTML?

Yes. The reason is that the epub requires files to conform to the xhtml specification.

Or am I safe in making all my XHTML files into HTML and reading my ebooks in that way?

As mentioned above, you're not actually changing anything by renaming files to an html extension. But to answer your question: renaming all xhtml files to html is perfectly "safe" to do with epub2. But only because doing so actually accomplishes nothing. Filename <> Format. And Sigil/PageEdit only do the xhtml format.

[Turtle91]

Originally Posted by fdwojo

...
As many Sigil users know, they dropped the BookView feature in it. Fortunately, for those of us who liked to see the WYSIWYG aspect, we know have PageEdit to help ourselves out.
...

Just to point out.... You can also have the Preview pane (F10) open - I have mine docked to the side or sometimes on a different monitor - so that you can WYSIWYG without having to open PageEdit.

It is HIGHLY recommended to learn the very basic html/css required for making a good book. That way you can work in the Code view pane and see exactly what it will look like in the Preview Pane at the same time.

Cheers,

[Tex2002ans]

Originally Posted by fdwojo

Thus, is there any reason (for ebooks) to use XHTML?

XHTML + XHTML5 are what the EPUB specs require.

There are a few (more technical) differences between HTML + XHTML, but the only real surface level thing is that XHTML is more strict.

Here are a few examples:

1. If you have an open tag, XHTML requires you have a closing tag.

So something messy like this is "valid" (but poor) HTML:

<p>This is paragraph 1.
<p>This is paragraph 2.

where in XHTML, for every <p> you need a closing </p>:

<p>This is paragraph 1.</p>
<p>This is paragraph 2.</p>

2. In HTML, you can have busted nesting like this:

<p><b>This is bold.</p></b>

but in XHTML, you must nest the tags properly:

<p><b>This is bold.</b></p>

3. Standalone tags have to close too. So in HTML:

<br>
<img src="example.jpg">

but in XHTML, you need the closing slash:

<br />
<img src="example.jpg" />

Originally Posted by fdwojo

In fact, when I edit my EPUBs, I tend to change all text files to either HTML or CSS. If I see an XHTML, I generally rename it to HTML.

As Diap has said, you just changing the .html to .xhtml isn't changing anything... the underlying code is all still XHTML: Sigil makes sure of it.

So if you put in poorly formed HTML, it will all be nested properly + cleaned up to the best of Sigil's ability.

Paste those code examples above into Sigil's Code View and then Tools > Reformat HTML > Mend and Prettify All HTML Files and see what happens.

[David Kudler]

It's so funny — I've been working in XHTML so long, I'd forgotten how much bad code you could get away with in vanilla HTML. ^.^

[fdwojo]

As much as I appreciate the number of them, none of you have really answered my question (that I probably asked badly).

My question:

With respect to eBooks ONLY, what can XHTML do that HTML cannot?

I would not consider myself an expert at HTML, but I've been editing my Sigil eBooks successfully for almost a decade now, and many of the cautions you made, I do watch out for, closing tags, proper syntax, etc.

I also realize that it is what is *in* the file that makes it HTML. But because of that fact that for all the eBooks I edit, (and I do edit any Kindle eBooks I buy to combine individual stories together when it's a series), it seems like nothing outside the realm of HTML seems to occur. Thus the question.

Most of what I do when I'm editing eBooks, (or rarely, writing an eBook), seems pretty straightforward. Occasionally, I will wish that there was a way to have a picture in the text with the text wrapped around it, but aside from that, I am fine. (and there probably is, but I don't know how)

But with all the push for Sigil to be able to do things with XHTML (and it did handle it pretty well before), I'm wondering if there are things in my eBooks that I can do with XHTML that I CAN'T do with HTML. Is there anything that people do in eBooks that XHTML can do that HTML cannot?

Once again, thank you for giving me much to think about, but I hope I can get some information to set my question to rest.

FDWojo

[Tex2002ans]

Originally Posted by fdwojo

With respect to eBooks ONLY, what can XHTML do that HTML cannot?

XHTML can do anything HTML can.

As was stated before, it's just more strict with what's a valid/well-formed file.

Originally Posted by fdwojo

[...] it seems like nothing outside the realm of HTML seems to occur. Thus the question.

Because the books you've worked with were probably already validated, or else they wouldn't be in the stores. (Or ran through something like Calibre that would convert to XHTML.)

Or if you opened it up in Sigil, it already did the cleanup/changes for you. For example:

HTML has rules like allowing capital letters, no quotes around attributes, and no strict need for a closing tag:

HTML:

<body>
<BLOCKQUOTE>
<P>This is a paragraph</p>
<p CLASS=someclass>This is a second sentence

XHTML (and similar to what browsers automatically do in the backend when met with trash code):

<body>
<blockquote>
  <p>This is a paragraph</p>
  <p class="someclass">This is a second sentence</p>
</blockquote>
</body>

When browsers are met with junk HTML, they have to then make all these assumptions and take wild guesses at what they THINK you meant.

With XHTML, you're forced into making your code well-formed/consistent in the first place.

As I said earlier... most of the differences are technical minutiae, so no need to go too deep into it.

[eschwartz]

Originally Posted by fdwojo

As much as I appreciate the number of them, none of you have really answered my question (that I probably asked badly).

My question:

With respect to eBooks ONLY, what can XHTML do that HTML cannot?

You're... not really understanding what people are telling you, so let's try it another way.

There's no such thing as HTML. At all, period. Anyone who told you HTML existed was completely and utterly wrong. Therefore, there cannot be any difference between HTML (which does not exist), and XHTML (which does exist).

XHTML is an interesting language, which you've been *thinking of* as "HTML", because that "X" is too long and therefore it's fun to abbreviate it. One of its quirks is that if there are errors in XHTML, the renderer throws up its hands and says "hey, you're not allowed to do that. I refuse to even look at your file".

Then it turns out HTML does in fact exist, even though we don't like to admit it. It's what happens if you take XHTML and remove the requirement that errors are errors.

HTML is a bastardized form of XHTML, with the sole difference being that in the event of an error, HTML is permitted to randomly guess what it thinks you meant, instead of displaying an error message.

So, the first step here is to define a glossary. Henceforth, we will refer to two terms.

• XHTML - XHTML, the standard for writing ebooks and webpages and stuff like that
• files with errors in them - sometimes known as HTML

Now, you have asked a question.

"With respect to eBooks ONLY, what can XHTML do that files with errors in them cannot?"

So, the answer to your question is that files with errors in them can "do" errors. But I don't know why you would want to do that, so don't do that.

In fact, as has been repeatedly stated, EPUB does not permit files with errors in them, therefore you cannot use files with errors in them, regardless of what you call them. So it turns out that given the choice between XHTML and "files with errors in them"... you don't actually have a choice, there is only XHTML.

Originally Posted by fdwojo

I would not consider myself an expert at HTML, but I've been editing my Sigil eBooks successfully for almost a decade now, and many of the cautions you made, I do watch out for, closing tags, proper syntax, etc.

I also realize that it is what is *in* the file that makes it HTML. But because of that fact that for all the eBooks I edit, (and I do edit any Kindle eBooks I buy to combine individual stories together when it's a series), it seems like nothing outside the realm of HTML seems to occur. Thus the question.

There is that word again. "HTML". Please stop using it.

"it seems like nothing outside the realm of files with errors in them seems to occur."

That's a pretty weird thing to say. The most obvious thing that occurs is the fact that there are no errors.

Originally Posted by fdwojo

Most of what I do when I'm editing eBooks, (or rarely, writing an eBook), seems pretty straightforward. Occasionally, I will wish that there was a way to have a picture in the text with the text wrapped around it, but aside from that, I am fine. (and there probably is, but I don't know how)

But with all the push for Sigil to be able to do things with XHTML (and it did handle it pretty well before), I'm wondering if there are things in my eBooks that I can do with XHTML that I CAN'T do with HTML. Is there anything that people do in eBooks that XHTML can do that HTML cannot?

I do not know where you got this incorrect information from. Sigil has never pushed to be able to do things with XHTML. Pushing to be able to do things with XHTML, would imply that there was a time when Sigil did something other than XHTML, and that is just plain wrong, since it never has, does not, and never will do something other than XHTML. Sigil. since day #1, is an EPUB file editor, EPUBs use the XHTML file format, and Sigil, hence, has always, since day #1, used XHTML. Nothing more*, and nothing less.


* -- discounting Sigil's support for additional resources like CSS or PNG or JPEG files, which is orthogonal to the current discussion.