Validing XHTML vs Html

[Peter Williams]

Hello,

If my html is valid XHTML accroding to http://validator.w3.org/, does
thuis mean it is also valid (4.0.1) Html?

Thanks in Advance

[Ian Rastall]

On 2 Mar 2006 02:49:28 -0800, "Peter Williams" <p8****@gmx.net> wrote:

If my html is valid XHTML accroding to http://validator.w3.org/, does
thuis mean it is also valid (4.0.1) Html?

Hi Peter. A test you could try is to make a copy of a file, change the
DOCTYPE, and then try to re-validate it.

XHTML is usually served up with the MIME type "text/html", which means
that browsers see it as HTML, and render it correctly. This is because
XHTML was designed for backwards-compatability. Another way of saying
this is that XHTML is broken HTML that happens to be broken in just
such a way that it doesn't break the page. It is not valid HTML 4.01,
though, to answer your question.

The real MIME type for XHTML is "application/xhtml+xml", which most
browsers recognize, but which Internet Explorer doesn't recognize.
Since IE commands most of the market share, and since they're not
going to accomodate this MIME type in IE 7, a lot of web designers
have gone back to HTML 4.01. I've done the same thing. I actually
learned XHTML first, and stuck with it for many years. If you use a
text editor that supports HTML Tidy, then making the conversion back
to HTML 4.01 is as simple as changing the DOCTYPE and then tidying the
page.

Ian
--
http://sundry.ws/

[Steve Pugh]

Peter Williams wrote:

If my html is valid XHTML accroding to http://validator.w3.org/, does
thuis mean it is also valid (4.0.1) Html?

Obviously the doctypes will be different - a valid HTML 4.01 document
should have a HTML 4.01 doctype and a valid XHTML 1.0 document should
have a XHTML 1.0 doctype.

But ignoring that (and the whole content-type farce), if you swapped
doctypes (or used the over ride feature in the validator) would it be
valid? Maybe.

If your XHTMLisms are confined to those that look like HTMLisms then it
will be valid.

So, you would need to have:
* No empty elements in the head (so no <link> or <meta> elements) or
anywhere else where character data can't appear.
* No boolean attributes anywhere (so no compact, readonly, disabled or
nowrap attributes).

Of course there are valid XHTMLisms that look like valid HTMLisms but
which mean something totally different in HTML (e.g. <br /> means <br>>
not <br></br>).

Steve

[David Dorward]

Steve Pugh wrote:

Peter Williams wrote: If your XHTMLisms are confined to those that look like HTMLisms then it
will be valid.

So, you would need to have:
* No empty elements in the head (so no <link> or <meta> elements) or
anywhere else where character data can't appear.
Although any of those used where character could appear would have
different meaning in HTML than in XHTML.
* No boolean attributes anywhere (so no compact, readonly, disabled or
nowrap attributes).

HTML does allow for the expanded form of boolean attributes, it just
isn't recomended.

http://www.w3.org/TR/html4/appendix/notes.html#h-B.3.4

[Andy Dingley]

Peter Williams wrote:

If my html is valid XHTML accroding to http://validator.w3.org/, does
thuis mean it is also valid (4.0.1) Html?

No, it certainly doesn't _mean_ that.

If you didn't use certain features, and you swap the doctype, then it
_may_ be valid as both.

It's not really useful to know this though. They are different and they
do need separate processing. Searching this newsgroup is probably the
best resource around on the details. If you don't _really_ understand
this, then stick with HTML 4.01

[Steve Pugh]

David Dorward wrote:

Steve Pugh wrote:

* No boolean attributes anywhere (so no compact, readonly, disabled or
nowrap attributes).

HTML does allow for the expanded form of boolean attributes, it just
isn't recomended.

http://www.w3.org/TR/html4/appendix/notes.html#h-B.3.4

Thanks, I'd never come across that before.

Steve

[Jukka K. Korpela]

Andy Dingley wrote:

If my html is valid XHTML accroding to http://validator.w3.org/, does
thuis mean it is also valid (4.0.1) Html?
No, it certainly doesn't _mean_ that.

Indeed; it means that the document _cannot_ be valid HTML 4.01.
If you didn't use certain features, and you swap the doctype, then it
_may_ be valid as both.
Well, it's not the same document any more if you swap the doctype.

Besides, a document that conforms to the XHTML specification does not
become a (valid) HTML 4.01 document just by swapping the doctype, even
if we ignore issues already discussed here. The xmlns attribute is
obligatory, though for technical reasons, it is not required as an
explicit attribute according to the DTD. (Thus, an XHTML document that
lacks the attribute is valid but incorrect, nonconforming.)

An XML declaration (<?xml ...>) at the start of document, as allowed in
XHTML, makes a document nonconforming (though not invalid) by HTML 4.01
rules.

There are also differences in content models of <script> and <style>
elements. They can be essential if you have "&" or "<" characters inside
them.
It's not really useful to know this though.

Yeah, it's just fun to get confused with this. However it _is_ an issue,
in principle at least, if you wish to author so that you serve the same
content as HTML 4.01 to some browsers and as XHTML to other browsers.

[Peter Williams]

> However it _is_ an issue, in principle at least, if you wish to author so that you serve the same content as HTML 4.01 to some browsers and as XHTML to other browsers.

This is what Im aiming at.

[Peter Williams]

I suppose my original question should have better have been phrased:

Apart form some trivialities (eg swapping DOCTYPE) correct XHTML is a
superset of correct HTML ? So that by writing correct XHTML and
avoiding anything outside the overlap (XHTML thats not part of HTML),
the result will be even more "standard" than correct HTML (ie all
elements properly closed etc)?

Or are the trivialities not so simple, so that it wouldnt be so trivial
to convert my XHTML documents to HTML, by hand via simlpe editing such
as swapping of the DOCTYPE? Are there things to be weary of here?

[Chris Beall]

Peter Williams wrote:

However it _is_ an issue, in principle at least, if you wish to author so that you serve the same content as HTML 4.01 to some browsers and as XHTML to other browsers.

This is what Im aiming at.

Peter,

How brave are you?

Back up all your files, then go to w3.org and download the appropriate
version of Amaya.

Open a file, then:

File, Show parsing errors (unless it's greyed out). Fix the errors.

File, Change the Document Type. Pick one. Let it crank a while. Then
File, Save as...

CAUTION: This code is under test. Bad Things can happen. Proceed at
your own risk.

Chris Beall

[Eric B. Bednarz]

"Jukka K. Korpela" <jk******@cs.tut.fi> writes:

An XML declaration (<?xml ...>) at the start of document, as allowed
in XHTML, makes a document nonconforming (though not invalid) by HTML
4.01 rules.

The general policy of W3C HTML – as far as I know it – is a vague “‘foo’
is recommended� rather than an explicit “‘bar’ is Verboten�. *If*
processing instructions in the prolog are nonconforming, HTML cannot be
processed by any conforming SGML system as a conforming application in
the first place. End of story (obfuscating nsgmls output with
undocumented heuristics, as the W3C validation service happens to do,
does not rewrite standards; no surprise, but that qualifies 'invalid' as
undefined).
--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011

[Toby Inkster]

Peter Williams wrote:

Apart form some trivialities (eg swapping DOCTYPE) correct XHTML is a
superset of correct HTML ?

Not really.

Apart from swapping the DOCTYPE, it is possible to create a document that
is both valid HTML *and* valid XHTML. For example, given the right
DOCTYPE, the following markup is valid HTML 4.01 and XHTML 1.0:
[listing 1]
<html lang="en">
<head>
<title>Example.</title>
</head>
<body>
<h1>Example.</h1>
<p>This is an example.</p>
</body>
</html>

However, the following valid HTML document would not be valid as XHTML:
[listing 2]
<html lang="en">
<title>Example.</title>
<h1>Example.</h1>
<p>This is an example.
</html>

and the following XHTML would not be valid as HTML:
[listing 3]
<html xml:lang="en">
<head>
<title>Example.</title>
<meta name="title" content="Example."></meta>
</head>
<body>
<h1>Example.</h1>
<p>This is an example.</p>
</body>
</html>

So, if we're going to talk subsets and supersets (and forget about
DOCTYPES) then:

If H is the set of all possible valid HTML documents; and X is the set of
all possible valid XHTML documents, then there exists a non-empty set A
such that A⊂H and A⊂X, as illustrated by listing 1, which is a member
of set A.

However, as shown by listing 2, there exists a document h such that h∈H,
but h∉X. And as shown by listing 3, there exists a document x such that
x∉H, but x∈X. These last two findings show that H⊄X and X⊄H.

FWIW, I think that whether you're using XHTML or HTML, it's usually good
practice to aim for your documents to be as close to set A as possible.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

[Andy Dingley]

On 3 Mar 2006 02:56:26 -0800, "Peter Williams" <p8****@gmx.net> wrote:

Apart form some trivialities (eg swapping DOCTYPE) correct XHTML is a
superset of correct HTML ?

No.

You should read Hixie's paper. This paper is bogus, because it describes
difficulties in achieving something that no-one wants to do - but it
seems that you actually want to !

HTML and XHTML should be seen as two separate end results of diverging
content-management tasks. It's usually easy to produce either on demand
but his idea of "simultaneously being both" is both impossibly
difficult, and pointless.

[Alan J. Flavell]

On Mon, 6 Mar 2006, Andy Dingley wrote:

You should read Hixie's paper. This paper is bogus, because it
describes difficulties in achieving something that no-one wants to
do
Oh, I dunno about that - I've seen several cases of people who
appeared to want to do what it describes (that is, until it was
explained to them what they'd need - and then they went right off the
idea).

The problem with Hixie's paper is that it over-states the case with
such details, giving people who want to diss it ("bogus", your choice
of words) the opportunity to ignore the substantive message which it
also contains.
HTML and XHTML should be seen as two separate end results of
diverging content-management tasks. It's usually easy to produce
either on demand but his idea
"his" idea? That isn't how I read it.
of "simultaneously being both" is both impossibly difficult, and
pointless.

No disagreement there. But I don't interpret that as Hixie's point,
and it doesn't contradict the substantive content of his rant.

One message that I take from his rant is that the majority of
soi-disant "XHTML" on the web today is in fact XHTML-flavoured tag
soup, fit only to be served as text/html under the extensive fixup
heuristics of bad old HTML. As genuine XHTML, it is bogus: as
"XHTML/1.0 Appendix C" it is bogus too. It carries all of the old
ballast of only "working" (for some small values of the term
"working") in the presence of a whole menagerie of browser fixups.

So the provisions of "Appendix C" have given us a whole new legacy of
defective markup, containing all of the disadvantages which had
accrued in HTML du jour, and from which XHTML was supposed to rescue
us, PLUS some whole new legacy problems based on widespread
misunderstandings of XHTML and of Appendix C.

It would have been better to convince those authors to stay with
legacy HTML unless/until they understood XHTML. And draw a firm line
under the fixup heuristics of HTML, make a clean break and a clean
start. But it's too late for that now: the new legacy is already
there. Ho hum.