HTML to XHTML

[Samuël van Laere]

It has been some time since I last posted here.
Currently i'm considering moving from HTML 4.01 to XHTML since I think
it will make moving to HTML5 easier when that time comes.

The thing is that I still need to support IE6.
So I wonder are the any problems with XHTML and IE6?
Are the in 2011 still reasons to stick with HTML 4.01 rather then XHTML?
I read in a book that rendering XHTML is faster, is that indeed so?
(read that in the Dutch translation of Zelfman's Designing With Web
Standards 2nd edition)

Hope your answers will make it easier to decide
if it is worth the time and effort to move to XHTML.

cheers,
Samuel

 

[Beauregard T. Shagnasty]

It has been some time since I last posted here. Currently i'm
considering moving from HTML 4.01 to XHTML since I think it will make
moving to HTML5 easier when that time comes.

The thing is that I still need to support IE6.
So I wonder are the any problems with XHTML and IE6?

Test for yourself:
http://tekrider.net/html/doctype.php

Are the in 2011 still reasons to stick with HTML 4.01 rather then
XHTML?

Yes. The most popular browser-like object known as Internet Explorer
does not support XHTML, and if served ... well, read here:
* http://www.webdevout.net/articles/beware-of-xhtml
* http://www.spartanicus.utvinternet.ie/no-xhtml.htm

I read in a book that rendering XHTML is faster, is that indeed so?

Never heard that and doubt if it is true at all.

(read that in the Dutch translation of Zelfman's Designing With Web
Standards 2nd edition)

Hope your answers will make it easier to decide
if it is worth the time and effort to move to XHTML.

You never mentioned "Strict" or "Transitional." Use HTML 4.01 Strict
and type all coding in lower case.

 

[Samuël van Laere]

Op 14-1-2011 23:15, Beauregard T. Shagnasty schreef:

Test for yourself:
http://tekrider.net/html/doctype.php


Yes. The most popular browser-like object known as Internet Explorer
does not support XHTML, and if served ... well, read here:
* http://www.webdevout.net/articles/beware-of-xhtml
* http://www.spartanicus.utvinternet.ie/no-xhtml.htm


Never heard that and doubt if it is true at all.


You never mentioned "Strict" or "Transitional." Use HTML 4.01 Strict
and type all coding in lower case.

Thanks for your answers Beauregard,

browser-like object lol

But I ment to do it in Strict;
the current website is in HTML 4.01 Strict also
so its allready in lower case and uses <li> with its closing
counterpart, so moving should be relative easy.
Though I don't see a reason to move if it doesn't help at all.


cheers,
Samuel

 

[Beauregard T. Shagnasty]

Beauregard T. Shagnasty schreef:

Thanks for your answers Beauregard,

You're welcome.

browser-like object lol

But I ment to do it in Strict;
the current website is in HTML 4.01 Strict also
so its allready in lower case and uses <li> with its closing
counterpart, so moving should be relative easy.

Then you are already finished. There's no need to convert to XHTML.
Hopefully, you test for errors.
http://validator.w3.org/
http://jigsaw.w3.org/css-validator/validator.html

Though I don't see a reason to move if it doesn't help at all.

IMO, HTML 5 (still a draft) is a long way away. Don't worry about it.

 

[dorayme]

http://tekrider.net/html/doctype.php

Your nice little list images wander off left on big user text
sizes, you are fightin' to keep all nice with neg margins and
things... Consider, on your menu.css, instead of:

#boxnav li {
list-style-type: none;
margin-left: -3em;
padding-left: 0;
}


try:


#boxnav ul {
list-style-type: none;
margin: 0;
padding: 0;

#boxnav li {
margin: 0;
padding: 0;
}

and you might make

#boxnav {
...
width: 13em;
}


to less, 11em looks ok. I assume you know how less is more.

It is less images wandering off left to face the perils of the
brown or even maybe off the browser, who knows what people have
outside their browsers, beasts and monsters ready to catch
wandering home and folder icons. <g>

 

[Beauregard T. Shagnasty]

Your nice little list images wander off left on big user text sizes,
you are fightin' to keep all nice with neg margins and things...
Consider, on your menu.css, instead of:
<cut>
It is less images wandering off left to face the perils of the brown
or even maybe off the browser, who knows what people have outside
their browsers, beasts and monsters ready to catch wandering home and
folder icons. <g>

LOL! Okay, I made your recommended changes. Works great, thanks. I did,
however, with the old code that I needed to press Ctrl-Plus five times
for the folders to wander into the brown. <g>

 

[Gus Richter]

It has been some time since I last posted here.
Currently i'm considering moving from HTML 4.01 to XHTML since I think
it will make moving to HTML5 easier when that time comes.

It is perfectly OK to remain with HTML4.01, but if your intent is to
move to HTML5, then you can do so immediately without the need to
consider XHTML as an interim move. You can do so immediately and very
easily for any Standards/Strict HTML4.01 page and if it validates for
HTML4.01, then it will validate for HTML5 if you simply change the
Doctype to:

<!DOCTYPE html>

That's all there is to it. ALL browsers support it NOW. The HTML5
doctype is a reduction of the HTML4.01 Strict doctype down to the
minimum required portions to satisfy legacy doctype sniffing. It also
triggers the browsers into Strict/Standards Mode. There is only the one
in HTML5. You can use the same HTML4.01 elements you used before, for
all elements are still supported. The bonus is that you can also use the
new elements available in HTML5, in as much as they are supported by all
browsers, which you will have to keep track of until all settles down.
You can check for their support here:
http://caniuse.com/
It all depends on which browsers you wish to support. Additionally, you
may have to use browser specific prefixes for the new elements. Many web
pages are using HTML5 already and the count is increasing.

With HTML5, you can use the same markup as in HTML4.01 Strict, it's up
to you, but there are shorter ways. i.e.:
For charset, HTTP header is preferred, but where not everyone can set
HTTP headers, meta may be shortened to:
<meta charset="utf-8">
which should always be included (expanded or short version), else it can
lead to security vulnerabilities. It must be immediately after the head
element.
For a linked stylesheet, the type="text/css" may be dropped, for it is
the default, as per:
<link rel="stylesheet" href="whatever.css">
For embedded stylesheet:
<style>

XHTML5 may be used with the same Doctype for SVG, MathML or for other
needs. The xlmns namespace attribute is no longer required on the html
element for it is the default. The XHTML document should be served with
a MIME type of application/xhtml+xml.

I probably included too much. I got carried away. Well, there you go.

-- Gus

 

[Samuël van Laere]

Op 15-1-2011 0:03, Beauregard T. Shagnasty schreef:

You're welcome.


Then you are already finished. There's no need to convert to XHTML.
Hopefully, you test for errors.
http://validator.w3.org/
http://jigsaw.w3.org/css-validator/validator.html


IMO, HTML 5 (still a draft) is a long way away. Don't worry about it.

Well every page validates fine, i'm kind of addicted to that.
So i'm sticking with HTML 4.01 Strict for some more years to come
hopefully HTML5 support is going to great amongst browsers, but that is
still future talk.

I think that my real question should be:
what is the real harm if the content type is incorrect?
Seems to be there is none:
IE would be able to open the page and display it (hopefully) correctly
Other UI's probally don't care and display it anyway

As for the HTML5 doctype:
I have tried that but for some reason the W3C HTML validator doesn't
seem to agree that the page(s) validates.
It validates fine with the HTML 4.01 Strict doctype.

cheers,
Samuel

 

[Gus Richter]

Well every page validates fine, i'm kind of addicted to that.
So i'm sticking with HTML 4.01 Strict for some more years to come
hopefully HTML5 support is going to great amongst browsers, but that is
still future talk.

Sadly, you have not read my response or you did not understand it.
What the HTML5 Doctype does is simply triggers the browsers into
Standards Mode.
HTML5 supports HTML 4.01 elements right now - it is backwards compatible.
HTML5 supports the new elements whenever you wish to use them and/or
when the browser(s) you intend to support, will support them.
HTML5 is not one big thing, it's a collection of individual features. So
you can't detect "HTML5 support" because that doesn’t make any sense.
But you can detect for support for individual features, like canvas and
video.
For your existing HTML 4.01 *Strict* web pages, if you change to HTML5
with its Doctype, they will function as previously.
Perform a search for HTML5 and do some reading to convince yourself and
learn the ins and outs.

I think that my real question should be:
what is the real harm if the content type is incorrect?
Seems to be there is none:

Content-Type refers to Internet Media Types such as text/html, text/css,
application/xhtml+xml, image/png, etc. I'm not sure what you mean.

IE would be able to open the page and display it (hopefully) correctly
Other UI's probally don't care and display it anyway

UI refers to User Interface, but you probably mean UA which refers to
User Agent. Not sure again what you mean, but if the markup is bad, all
bets are off and different UAs may display differently, if at all.

As for the HTML5 doctype:
I have tried that but for some reason the W3C HTML validator doesn't
seem to agree that the page(s) validates.
It validates fine with the HTML 4.01 Strict doctype.

This is very hard to believe. Perhaps you did not read my previous
article carefully enough. If you wish to proceed further, provide a URL
and I will look for the reason of it.

-- Gus

 

[Gus Richter]

As for the HTML5 doctype:
I have tried that but for some reason the W3C HTML validator doesn't
seem to agree that the page(s) validates.
It validates fine with the HTML 4.01 Strict doctype.

BTW, by placing the meta charset in an HTML5 document anywhere else but
first in the head element, you will find that the document will no
longer validate as HTML5.

As I wrote previously, "It must be immediately after the head element".
This is for a security reason and the validator checks for this.

 

[Beauregard T. Shagnasty]

I think that my real question should be:
what is the real harm if the content type is incorrect?
Seems to be there is none:
IE would be able to open the page and display it (hopefully) correctly

I guess the answer is: "Maybe"

Other UI's probally don't care and display it anyway

http://tekrider.net/html/htmlvalid.php ;-)

 

[Samuël van Laere]

Op 15-1-2011 6:30, Gus Richter schreef:

It is perfectly OK to remain with HTML4.01, but if your intent is to
move to HTML5, then you can do so immediately without the need to
consider XHTML as an interim move. You can do so immediately and very
easily for any Standards/Strict HTML4.01 page and if it validates for
HTML4.01, then it will validate for HTML5 if you simply change the
Doctype to:

<!DOCTYPE html>

Oke i've just changed it to that DOCTYPE.
I do not know why it doesn't validate at this point.
3 errors:
http://kubes.nl/


cheers,
Samuel

 

[Samuël van Laere]

Op 15-1-2011 13:41, Gus Richter schreef:

BTW, by placing the meta charset in an HTML5 document anywhere else but
first in the head element, you will find that the document will no
longer validate as HTML5.

As I wrote previously, "It must be immediately after the head element".
This is for a security reason and the validator checks for this.

I've just commented in your other post in this thread.
I used the HTML5 DOCTYPE but 3 errors remain:
http://kubes.nl/

 

[Jukka K. Korpela]

BTW, by placing the meta charset in an HTML5 document anywhere else
but first in the head element, you will find that the document will no
longer validate as HTML5.

Which HTML5 draft are you referring? The current content of
http://dev.w3.org/html5/spec/Overview.html#charset
does not seem to say such a thing.

As I wrote previously, "It must be immediately after the head
element". This is for a security reason and the validator checks for
this.

Which validator? The following passes http://validator.w3.org :

<!doctype html>
<title>foo</title>
<meta charset="utf-8">
<p>Hello world</p>

 

[Gus Richter]

Op 15-1-2011 13:41, Gus Richter schreef:

I've just commented in your other post in this thread.
I used the HTML5 DOCTYPE but 3 errors remain:
http://kubes.nl/

Excellent! It validates now in HTML5! I was going to point out your
errors. It could not have been validated in HTML 4.01 with the dimension
errors.
There are some differences in HTML5 as you found in the 1. Warning Line
that "The Content-Language state is obsolete." and the proper way is
<html lang="nl">

Some other differences are:
The default type for the STYLE element is "text/css" which is OK, but is
not required in HTML5.
<link rel="stylesheet" href="whatever.css">
and/or:
<style>
...
</style>
is all that is required.

Your line:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
is OK, but can be shortened in HTML5 to:
<meta charset="utf-8">
or you can use the HTTP header which is the preferred method and
overrider meta.

You should always specify a character encoding on every HTML document
and always place it first thing in the HEAD or bad things will happen
(security vulnerability). See:
<http://code.google.com/p/doctype/wiki/ArticleUtf7>

I am surprised that your page validates when not the first thing in the
HEAD since I had the experience that it would not validate in HTML5 if
placed after the TITLE element. I will have to check into this more when
time allows. In any case, do the advised due to security considerations.

Your page is now ready to also support the new HTML5 elements if and
when you wish to use them. You can use this site to check for browser
support of the new elements:
<http://caniuse.com/>

 

[Gus Richter]

Which HTML5 draft are you referring? The current content of
http://dev.w3.org/html5/spec/Overview.html#charset
does not seem to say such a thing.



Which validator? The following passes http://validator.w3.org :

<!doctype html>
<title>foo</title>
<meta charset="utf-8">
<p>Hello world</p>

In my response to Samuel, I said:

You should always specify a character encoding on every HTML document
and always place it first thing in the HEAD or bad things will happen
(security vulnerability). See:
<http://code.google.com/p/doctype/wiki/ArticleUtf7>

I am surprised that your page validates when not the first thing in
the HEAD since I had the experience that it would not validate in
HTML5 if placed after the TITLE element. I will have to check into
this more when time allows. In any case, do the advised due to
security considerations.

Sorry for any confusion.
I have checked the page I found this to be still true as I described. I
have a lot of HTML comments beside the elements. Without all the HTML
comments it does not. I will have to conduct more tests.

BTW, see:
<http://dev.w3.org/html5/spec/Overview.html#the-head-element-0>
and

<http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-head-element-0>
where it is positioned as advised herein, but nowhere can I find any
mention of the exact position as advisable or a must. The best I came
across somewhere is that it should be near the top within the HEAD.

 

[Gus Richter]

No. It must be *in* the head element, between its opening and closing
tags.

Thank you for correcting me *again*, but you are incorrect. It must be
immediately after the HEAD opening tag, not just anywhere in the HEAD
element by saying "between the HEAD opening and closing tags", that is,
if you are concerned about the security vulnerability.

 

[Allodoxaphobia]

As I wrote previously, "It must be immediately after the head element".
This is for a security reason and the validator checks for this.

cite!

 

[Gus Richter]

cite!

Just for you I'll restate what I wrote before:

You should always specify a character encoding on every HTML document
and always place it first thing in the HEAD or bad things will happen
(security vulnerability). See:
<http://code.google.com/p/doctype/wiki/ArticleUtf7>

 

[Gus Richter]

If you can't deal with being corrected, double-check your claims before
posting them. It's not that difficult.

I know that you were right. I therefore corrected myself. It was just
that you had no other comments except for the correction of same lapses.
It just smelled of someone jumping in to report a simple spelling
mistake. I thought, and still think, that I had an important message to
try and bring across to counter the numerous comments that HTML5 was not
ready or not supported. The corrections, although correctly done,
watered down the importance of the message - led away from it.

For one thing, that isn't what you said - you said it must be immediately
after the head *element*.

True and that was why I corrected it with "after the head opening tag".
I could have said that it must be the first thing in the head element.

I was correcting you then by describing a specific place in the head
element instead of just anywhere within it. Reason for that as I stated
several times here and elsewhere is found at:
<http://code.google.com/p/doctype/wiki/ArticleUtf7>

That would put it after the closing tag, and

would result in invalid HTML. (Honestly Gus, I expected better of you.
You've been around these parts for long enough to understand the diff-
erence between a tag and an element...)

I would normally say "the first item in the HEAD element" and this led
me to my wrong wording. I thought about some readers having trouble with
this and therefore wanted to express it as "being the first item after
the HEAD opening tag". Sometimes I brain fart, so I mixed up my wording,
my bad. I'm not perfect.

For another, the current HTML DTD does not define a required order in
which the head element elements *must* appear. It may well be a good
idea to place meta before title, but it's not a must.

Glad to see that you understand. On the other hand, if the security
vulnerability is of concern to you, it would behoove you to follow the
recommendation I pass on from the link I provided. It does not hurt.

IMHO, a better way to avoid the browser bug you mentioned is to avoid
using meta elements altogether. Setting up a local Apache instance for
testing isn't exactly rocket surgery.

As I said before:
For charset, HTTP header is preferred, but where not everyone can
set HTTP headers, meta may be .......