Validation: XHTML Transitional vs. HTLM 4.01 Strict

What are the pluses and minuses of constructing and validating between
XHTML Transitional vs. HTLM 4.01 Strict

Thanks, CMA

On Fri, 23 Jul 2004 17:10:46 GMT, CMAR <cma6j (AT) yahoo (DOT) com> wrote:

What are the pluses and minuses of constructing and validating between
XHTML Transitional vs. HTLM 4.01 Strict

Thanks, CMA

If you use XML tools to build the page, XHTML is worthwhile if you can
serve it properly (which includes accounting for that set of browsers
which cannot handle properly-served XHTML).

Otherwise, there is no benefit I'm aware of.

Brian wrote:

Brian wrote:

Your comparing different variants of different languages.

Jeez Louise. My sister just misused "your" instead of "you're" in an
email to me, and apparently it's contagious. That should be "You're
comparing...." (Sure, it's pathetic to blame someone else for my
screwups, but that one is too embarassing to take the fall by myself.)

People also ought to attempt to spell "HTML" correctly when posting to
an HTML newsgroup, shouldn't they?

--
Dan

"CMAR" <cma6j (AT) yahoo (DOT) com> wrote in news:qEbMc.56758$yd5.32501
@twister.nyroc.rr.com:

in theory, web browsers can handle xhtml specifics - self closing tags for
instance, but that, as always is up to the software houses to sort.

The advantage of xhtml is the better structure you're forced to, with a far
stricter ruleset for how all the tags have to be written. xhtml 2, just
released in draft, goes somewhat further with some important tag changes;
this is, of course the rub. You still find pages out there that are written
in html 2, but they look dreadful. Keeping up with the current standards,
as xhtml is (html 4 has been around about as long as Microsoft NT4, at Microsoft have
stopped support for that now) is important.

In the end, validating xhtml is tougher, but you end up with a better
formatted document.

What are the pluses and minuses of constructing and validating between
XHTML Transitional vs. HTLM 4.01 Strict

Thanks, CMA

In article <10g3k2eqeo8c911 (AT) corp (DOT) supernews.com>,
Brian <usenet3 (AT) julietremblay (DOT) com.invalid> wrote:

s_m_b wrote:

in theory, web browsers can handle xhtml specifics - self closing tags for
instance, but that, as always is up to the software houses to sort.

Theory does not match reality. The most popular software used to
browse web pages, MSIE/Win cannot handle xhtml when served up properly.

http://www.hixie.ch/advocacy/xhtml

If ound it somehow disturbing that it does not talk about a future
transition to 'real' XHTML of ones markup. It costs authors little
trouble of writing XHTML right now and serving it as HTML tagsoup
because current browser limitations enforces that.

One of the caveats being that authors could be easily thinking that they
produce documents that can be served as application/xhtml+xml anytime of
their choosing without a problem. Often, a document is not well-formed
from the start or it loses well-formedness over time because of updates
to it's content. Also, scripts embedded or attached to the document are
often not good enough to continue function in browsers when the switch
to real XHTML is made.

The advantage of xhtml is the better structure you're forced to, with a far
stricter ruleset for how all the tags have to be written.

If you want stricter syntax (e.g., explicitly closed p and li
elements), then just close them. That's no reason to choose XHTML.

Choosing for the Strict version of HTML4.01 or XHTML1.0 would make a
bigger difference than choosing between HTML4.01 or XHTML1.0. Strict is
the magic to better strictness and that should be self-evident by it's
name.

If authors serve their XHTML as text/html, which in return makes UAs
interpret it as HTML tagsoup, there is no 'forced to more strictness',
because the author does not get penalized with an XML parsing error for
making a mistake when checking the page.

Keeping up with the current standards,
as xhtml is (html 4 has been around about as long as Microsoft NT4, at Microsoft have
stopped support for that now) is important.

One should not decide on XHTML simply because it's new. If there isn't
a reason, then HTML is the way to go.

No comment on that. Found it important to have it quoted here for anyone
who is considering using XHTML.

--
Kris
<kristiaan (AT) xs4all (DOT) netherlands> (nl)

On Sat, 24 Jul 2004 11:00:36 +0200, Kris
<kristiaan (AT) xs4all (DOT) netherlands> wrote:

In article <10g3k2eqeo8c911 (AT) corp (DOT) supernews.com>,
Brian <usenet3 (AT) julietremblay (DOT) com.invalid> wrote:

s_m_b wrote:

in theory, web browsers can handle xhtml specifics - self closing tags for
instance, but that, as always is up to the software houses to sort.

Theory does not match reality. The most popular software used to
browse web pages, MSIE/Win cannot handle xhtml when served up properly.

http://www.hixie.ch/advocacy/xhtml

If ound it somehow disturbing that it does not talk about a future
transition to 'real' XHTML of ones markup.

That's because it's trivial to convert valid HTML 4.01 to XHTML, no
trouble at all, in fact it's a lot easier than authoring XHTML
straight than follows the observations of Appendix C.

If authors serve their XHTML as text/html, which in return makes UAs
interpret it as HTML tagsoup, there is no 'forced to more strictness',
because the author does not get penalized with an XML parsing error for
making a mistake when checking the page.

It's the user that is penalised in the above scenario, not the author.

XML WF constraints should not exist on user focused languages.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

On Sat, 24 Jul 2004, Jim Ley wrote:

XML WF constraints should not exist on user focused languages.

But how do you know what the author intended, if they haven't followed
the elementary rules of the language? Getting "whatever was displayed
on the author's screen by version X of browser Y" isn't a very clear
design criterion, especially if you don't know the values of X and Y.

CSS at least has some mandatory requirements for error handling (even
/those/ are ignored by the Operating System Component that thinks it's
a web browser), and some general principles: I would summarise as
approx. "ignore everything that can't be understood unambiguously,
lest your guess prove disastrous". But that approach doesn't work for
broken (X)HTML.

The root problem is that the mass of authors are allowing themselves
to use a browser (or two) as arbiters of what is correct. If they
can't be disabused of that (and it doesn't look as if it's happening
any time soon), then browsers -should- be putting up a clear
indication whenever something is wrong, for the benefit both of
authors and of their poor readers.

On Sat, 24 Jul 2004 11:41:12 +0100, "Alan J. Flavell"
<flavell (AT) ph (DOT) gla.ac.uk> wrote:

On Sat, 24 Jul 2004, Jim Ley wrote:

XML WF constraints should not exist on user focused languages.

But how do you know what the author intended, if they haven't followed
the elementary rules of the language?

They didn't follow the elementary rules of the language, it doesn't
matter what they intended, what's important is what the user wants.

What matters is that the user isn't penalised for their incompetence,
so the User Agent should be allowed to have a guess at what at least
makes sense to it. Generally you'll find that the guess is good
enough, and if it's not then it'll be obvious to the human that's
using the document.

Take the trivial example of a missing </html> on the end of an XHTML
document, the guess that it's really there will not turn anything
disastrous. Or writing an undeclared entity in a standalone XML doc
is probably a pretty workable error recovery.

You may be able to construct a few documents where XML WF error
recovery results in documents that are not understandable, or not
obviously broken to the user, but I think you'll struggle - and I
think the vast majority of cases the user will be benefitted from the
behaviour.

But that approach doesn't work for broken (X)HTML.

I think the observations in Appendix C. suggest that it does work for
broken HTML.

The root problem is that the mass of authors are allowing themselves
to use a browser (or two) as arbiters of what is correct.

Yep, that's a great shame, but it's not a reason to penalise the
authors, and if you want to penalise the authors - penalise them on
the servers! make it an HTTP requirement that documents are not
served if invalid - at least that will mean users will never be able
to know there's a document there they can't read.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jim Ley wrote:

They didn't follow the elementary rules of the language, it doesn't
matter what they intended, what's important is what the user wants.

What browser version has a mind-reading module to determine this?

--
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/

On Sat, 24 Jul 2004 16:52:47 -0400, "Daniel R. Tobias"
<dan (AT) tobias (DOT) name> wrote:

Jim Ley wrote:

They didn't follow the elementary rules of the language, it doesn't
matter what they intended, what's important is what the user wants.

What browser version has a mind-reading module to determine this?

Determine what?

I'm talking about problems with XML that make it inappropriate for use
on user focused documents. Users want content, they don't want "bog
off you can't read this it contains a single character missing off the
end of the document"

Of course if you claim that that requires mind-reading, then I think
you're being ridiculous.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/