Validation: XHTML Transitional vs. HTLM 4.01 Strict

[GwG]

Re: Validation: XHTML Transitional vs. HTLM 4.01 Strict


"Brian" <usenet3@juliet remblay.com.inv alid> wrote in message
news:10g3j96ek5 rlh10@corp.supe rnews.com...[color=blue]
> Daniel R. Tobias wrote:[color=green]
> > Brian wrote:
> >[color=darkred]
> >> That should be "You're comparing...."[/color]
> >
> > People also ought to attempt to spell "HTML" correctly when posting
> > to an HTML newsgroup, shouldn't they?[/color]
>
> Uh, I'll take what's coming to me for mixing up "your" and "you're",
> but I'm afraid the op is on the hook for transposing the letters in
> the subject, so take it up with him.
>[/color]

"transition al is meant to east the transition (get it?)"

Not really ;-)

[Michael Rozdoba]

Re: Validation: XHTML Transitional vs. HTLM 4.01 Strict

Jim Ley wrote:
[color=blue]
> 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.
>
>[color=green]
>>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.[/color][/color]

I'm one of the clueless newbies who used XHTML because that was what W3C
recommended.

Since following several threads here & reading Appendix C, I've come
around to going with HTML 4.01 Strict.

However I like the idea of imposing upon myself the restrictions that
XHTML defines, which I would be free to do with HTML 4.01, such as
closing all tags & keeping the HTML free of presentational markup.

One of my reasons for using XHTML was that it allowed me to check I'd
done the above via validation. Is there any way I can write HTML 4.01
within these constraints & use a validator to tell me I've not made any
errors, rather than merely tell me I've complied with the requirements
of HTML 4.01?

--
Michael
m r o z a t u k g a t e w a y d o t n e t

[Alan J. Flavell]

Re: Validation: XHTML Transitional vs. HTLM 4.01 Strict

On Sat, 24 Jul 2004, Jim Ley wrote:
[color=blue]
> On Sat, 24 Jul 2004 11:41:12 +0100, "Alan J. Flavell"
> <flavell@ph.gla .ac.uk> wrote:
>[color=green]
> >But how do you know what the author intended, if they haven't followed
> >the elementary rules of the language?[/color]
>
> 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.[/color]

Oh dear, we've been around this before, haven't we?

The user wants <strong under no circumstances</strong> to find out
what the author was trying to tell them. Hmmm?

Only the other day, I accidentally botched the closing of an <h1>. As
a consequence, the browser showed the entire rest of the page as if it
had been a heading-1. Was that what I intended? Some misguided
authors stick a <b> tag at the start of a whole chapter, -intending-
it to remain in effect across paragraph etc. boundaries (no surprises
that they use <b> in preference to <strong>, ho hum). Should the
browser pander to this wish, or not? Others who -know- the rules
nevertheless occasionally botch their closing </strong> tag and find
the browser continues the <strong> effect way beyond what they had
really intended. OK, so this might not be disastrous to the content,
but what if it had been "display: none;" that was involved? Or they
put textual content inside a table but outside of a table cell, and
the browser renders it completely out of its intended context?
[color=blue]
> What matters is that the user isn't penalised for their incompetence,[/color]

I agree with the principle: but it's sheer chance whether the fixed-up
result will show obvious defects, be merely incomprehensibl e, or
occasionally convey *the wrong message*. So, take care not to
"penalise the user" by displaying some botched content which might be
completely wrong, but without any form of warning that it's been
botched.
[color=blue]
> 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,[/color]

Often you will, but is that good enough? - it would be unwise to rely
on it. And in that regard an error-fixup indicator *could* be a
useful alert. After all, many browsers have javascript error logs,
Java error logs, popup rejection logs, etc. etc.; the one major thing
they seem to lack are HTML/CSS rendering error logs - or indeed, *any*
kind of indicator of rendering errors, even if a full-scale log would
be thought overkill and might slow-down the action.
[color=blue]
> and if it's not then it'll be obvious to the human that's
> using the document.[/color]

That's *not* guaranteed (unfortuntely I haven't collected the examples
I've met in the past). If it's only 1 in 100 defective documents
which carry a significantly misleading message, it's still 1 too many,
and you have no idea which one of that 100 it's going to be. I don't
want to over-dramatise this, but as the web gets read more widely and
taken more seriously as a source of practical advice, the results are
potentially life-threatening in some cases.
[color=blue]
> Take the trivial example of a missing </html> on the end of an XHTML
> document,[/color]

....which an HTML rendering agent would take in its stride anyway...
[color=blue]
> 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.[/color]

Sounds like the usual HTML error recovery. Why not take an example
which has -real- consequences, instead of picking easy cases?
[color=blue]
> 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.[/color]

And IMHO none of those would be harmed by some kind of error
indicator, which could be a valuable marker in the instances - perhaps
the minority - where the defect does not produce obvious blemishes to
alert the reader to the defects in the rendered result. And by the
same token to alert many of those misguided authors, and discourage
them from putting their crap on the web until they fixed it. Which
would be beneficial to *both* sides.

IMHO and YMMV.

[Brian]

Re: Validation: XHTML Transitional vs. HTLM 4.01 Strict

Michael Rozdoba wrote:
[color=blue]
> Since following several threads here & reading Appendix C, I've
> come around to going with HTML 4.01 Strict.
>
> However I like the idea of imposing upon myself the restrictions
> that XHTML defines, which I would be free to do with HTML 4.01,
> such as closing all tags & keeping the HTML free of presentational
> markup.[/color]

This is wrong. You've conflated strict-v.-transitional with
HTML-v.-XHTML. HTML strict does not offer any presentational
markup that XHTML strict does not. The only difference is closing tags
that are optional in HTML but required in XHTML. (There are other
differences that are not relevant to your query.)
[color=blue]
> One of my reasons for using XHTML was that it allowed me to check
> I'd done the above via validation. Is there any way I can write
> HTML 4.01 within these constraints & use a validator to tell me
> I've not made any errors, rather than merely tell me I've complied
> with the requirements of HTML 4.01?[/color]

You could write your own dtd, referencing the w3c's strict dtd but
adding additional requirements e.g. for closing </p> and </li> tags.

[This thread has nothing to do with css, so I've set followups to ciwah.]

--
Brian (remove ".invalid" to email me)

http://www.tsmchughs.com/

[Jim Ley]

Re: Validation: XHTML Transitional vs. HTLM 4.01 Strict

On Sun, 25 Jul 2004 17:45:31 +0100, "Alan J. Flavell"
<flavell@ph.gla .ac.uk> wrote:
[color=blue]
>Only the other day, I accidentally botched the closing of an <h1>. As
>a consequence, the browser showed the entire rest of the page as if it
>had been a heading-1. Was that what I intended?[/color]

My point is that _XML_ is not suitablie for user focussed languages,
im your example, if you'd used XML, all the user would've seen is
nothing but "haha there's some content here, but I'm not going to show
you" The problem is the XML WF constraints on stopping display of the
information.
[color=blue][color=green]
>> What matters is that the user isn't penalised for their incompetence,[/color]
>
>I agree with the principle: but it's sheer chance whether the fixed-up
>result will show obvious defects, be merely incomprehensibl e, or
>occasionally convey *the wrong message*.[/color]

I've yet to see or hear of a scenario where fixup of invalid content
has resulted in the wrong message, and I visit and hear about a lot of
invalid webpages - also remember it's not invalid I'm arguing against
here, it's not WF (assuming UA's remain non-validating).
[color=blue][color=green]
>> 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,[/color]
>
>Often you will, but is that good enough? - it would be unwise to rely
>on it.[/color]

It would indeed be unwise to rely on it, which is why authors should
ensure their mark-up is invalid.

Users should absolutely have a caveat-emptor view on anything they
read, so I don't see any additional risk to the user.
[color=blue]
>That's *not* guaranteed (unfortuntely I haven't collected the examples
>I've met in the past). If it's only 1 in 100 defective documents
>which carry a significantly misleading message, it's still 1 too many,
>and you have no idea which one of that 100 it's going to be.[/color]

I don't agree with this, there's a lot more than 1 in 100 (and I would
suggest there's a lot more 0's on that list) web documents that
contain wrong information - so the additional misleadingness is
unlikely to be relevant.
[color=blue][color=green]
>> Take the trivial example of a missing </html> on the end of an XHTML
>> document,[/color]
>
>...which an HTML rendering agent would take in its stride anyway...[/color]

Of course, I'm only discussing why XML should no be used for
user-focused language - HTML is an excellent example of a more fault
tolerant SGML application that I would encourage people to use for
user focused languages.
[color=blue]
>Sounds like the usual HTML error recovery. Why not take an example
>which has -real- consequences, instead of picking easy cases?[/color]

Because XML WF errors are pretty rare other than the trivial cases. I
think you're absolutely agreeing with me, that HTML is better model
than XML.
[color=blue]
>And IMHO none of those would be harmed by some kind of error
>indicator, which could be a valuable marker in the instances - perhaps
>the minority[/color]

I don't disagree, <url: http://ieqabar.sourceforge.net/ > but at the
same time, I don't think it would have any real value to a user, since
only a tiny minority would be shown - at the same time this is
irrelelvant to what I understood us to be discussing - XML WF
constraints on normal processing (rendering in the case of XHTML)

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

[Sam Hughes]

Re: Validation: XHTML Transitional vs. HTLM 4.01 Strict

On Sat, 24 Jul 2004 16:52:47 -0400, Daniel R. Tobias <dan@tobias.nam e>
wrote:
[color=blue]
> Jim Ley wrote:
>[color=green]
>> 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.[/color]
>
> What browser version has a mind-reading module to determine this?[/color]

Browsers already do try and fix user mistakes. However, here is a short
list of easy, sensible ways to mind-read a mis-formed XHTML document:

Error: No closing tag
Example: <p><em>Hi this is blah....</p>
Fix: Put a closing tag right before the first instance where nesting
breaks: <p><em>Hi this is blah....</em></p>.

Error: No closing tag (for normally self-terminating elements)
Example: ... <hr></div>
Fix: Assume the element was meant to self-terminate: ... <hr/></div>

Error: Open elements at end of document
Example: Lack of a </div>, </body>, or </html> perhaps.
Fix: Close all open elements in proper order.


That's not exactly mind-reading. With an XHTML document the browser
_could_ warn the user that it is malformed and that it might not exactly
represent the author's intentions, and then display it anyway.



--
Accessible web designs go easily unnoticed;
the others are remembered and avoided forever.

[Sam Hughes]

Re: Validation: XHTML Transitional vs. HTLM 4.01 Strict

On Sun, 25 Jul 2004 15:00:14 -0400, Sam Hughes <hughes@rpi.edu > wrote:
[color=blue]
> On Sat, 24 Jul 2004 16:52:47 -0400, Daniel R. Tobias <dan@tobias.nam e>
> wrote:
>[color=green]
>> Jim Ley wrote:
>>[color=darkred]
>>> 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.[/color]
>>
>> What browser version has a mind-reading module to determine this?[/color]
>
> Browsers already do try and fix user mistakes. However, here is a short
> list of easy, sensible ways to mind-read a mis-formed XHTML document:
>
> Error: No closing tag
> Example: <p><em>Hi this is blah....</p>
> Fix: Put a closing tag right before the first instance where nesting
> breaks: <p><em>Hi this is blah....</em></p>.
>
> Error: No closing tag (for normally self-terminating elements)
> Example: ... <hr></div>
> Fix: Assume the element was meant to self-terminate: ... <hr/></div>
>
> Error: Open elements at end of document
> Example: Lack of a </div>, </body>, or </html> perhaps.
> Fix: Close all open elements in proper order.
>
>
> That's not exactly mind-reading. With an XHTML document the browser
> _could_ warn the user that it is malformed and that it might not exactly
> represent the author's intentions, and then display it anyway.[/color]

But mind-reading shouldn't do things such as fix authors' misnesting of
inline and block-level elements; if there is something such as <b><p>...,
it should be fixed by <b></b><p>....

Really, my definition of "mind-reading" is just the in-putting of missing
end-tags at the last-possible byte. :)

--
Accessible web designs go easily unnoticed;
the others are remembered and avoided forever.

[Jim Ley]

Re: Validation: XHTML Transitional vs. HTLM 4.01 Strict

On Sun, 25 Jul 2004 15:00:14 -0400, "Sam Hughes" <hughes@rpi.edu >
wrote:
[color=blue]
>On Sat, 24 Jul 2004 16:52:47 -0400, Daniel R. Tobias <dan@tobias.nam e>
>wrote:
>[color=green]
>> Jim Ley wrote:
>>[color=darkred]
>>> 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.[/color]
>>
>> What browser version has a mind-reading module to determine this?[/color]
>
>Browsers already do try and fix user mistakes.[/color]

Browsers are not XML UA's (unless you believe the HTML WG XHTML 2.0
preamble) - I think their success provides both a model that can be
used, and an example that it is practical.
[color=blue]
>Error: No closing tag
>Example: <p><em>Hi this is blah....</p>
>Fix: Put a closing tag right before the first instance where nesting
>breaks: <p><em>Hi this is blah....</em></p>.[/color]

Yep, but XML does not allow this.
<url: http://www.w3.org/TR/2000/REC-xml-20001006#dt-fatal >
[color=blue]
>That's not exactly mind-reading. With an XHTML document the browser
>_could_ warn the user that it is malformed and that it might not exactly
>represent the author's intentions, and then display it anyway.[/color]

No it couldn't... well by original my interpretation it could, but
others have convinced me this is wrong.

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

[Claire Tucker]

Re: Validation: XHTML Transitional vs. HTLM 4.01 Strict

On Sun, 25 Jul 2004 18:17:30 GMT, jim@jibbering.c om (Jim Ley) wrote:
[color=blue]
>On Sun, 25 Jul 2004 17:45:31 +0100, "Alan J. Flavell"
><flavell@ph.gl a.ac.uk> wrote:
>[color=green]
>>Only the other day, I accidentally botched the closing of an <h1>. As
>>a consequence, the browser showed the entire rest of the page as if it
>>had been a heading-1. Was that what I intended?[/color]
>
>My point is that _XML_ is not suitablie for user focussed languages,
>im your example, if you'd used XML, all the user would've seen is
>nothing but "haha there's some content here, but I'm not going to show
>you" The problem is the XML WF constraints on stopping display of the
>information.
>[/color]

Of course, any sensible author would have at least looked at the
result of his document in a browser and seen that it caused an error,
so the likelyhood of a manually-authored XHTML document "in the wild"
having such a syntactic error is, thankfully, unlikely.

We only end up with a web full of broken HTML documents *because* they
appear to work (for various values of "work") in popular browsers.


(XHTML documents generated by automated systems are a bit more
troublesome, since often designers of such automated systems use
string concatenation to form the resulting document rather than some
kind of document tree. I can't say I blame them for this, as it's
usually a lot faster and more memory-efficient, but it's very easy to
"forget" to deal with issues like character encodings which don't show
up as problems immediately, but will later when a content-writer
writes a pounds-sterling sign which gets encoded in ISO-Latin-1 and
then inserted into a UTF-8 XHTML document without any translation.)

-Claire

[Spartanicus]

Re: Validation: XHTML Transitional vs. HTLM 4.01 Strict

"Sam Hughes" <hughes@rpi.edu > wrote:
[color=blue]
>With an XHTML document the browser
>_could_ warn the user that it is malformed[/color]

Provided that the document is actually served as XHTML, a standard
compliant renderer *must* throw a parsing error.

--
Spartanicus

[Jim Ley]

Re: Validation: XHTML Transitional vs. HTLM 4.01 Strict

On Sun, 25 Jul 2004 19:18:52 GMT, Claire Tucker <fake@invalid.i nvalid>
wrote:
[color=blue]
>so the likelyhood of a manually-authored XHTML document "in the wild"
>having such a syntactic error is, thankfully, unlikely.[/color]

Also there are problems with any bugs in a UA - if a UA contains a bug
which treats a WF document as Non-WF - the user and author are stuffed
even if they find out about it - all they can do is say "don't use
client X" hardly a realisitic proposition.

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

[Nick Kew]

Re: Validation: XHTML Transitional vs. HTLM 4.01 Strict

In article <4103dec6$0$712 6$db0fefd9@news .zen.co.uk>,
Michael Rozdoba <mroz@nowhere.i nvalid> writes:
[color=blue]
> Is there any way I can write HTML 4.01
> within these constraints & use a validator to tell me I've not made any
> errors, rather than merely tell me I've complied with the requirements
> of HTML 4.01?[/color]

http://valet.webthing.com/page/parsemode.html

--
Nick Kew

Nick's manifesto: http://www.htmlhelp.com/~nick/

[Claire Tucker]

Re: Validation: XHTML Transitional vs. HTLM 4.01 Strict

On Sun, 25 Jul 2004 19:29:05 GMT, jim@jibbering.c om (Jim Ley) wrote:
[color=blue]
>On Sun, 25 Jul 2004 19:18:52 GMT, Claire Tucker <fake@invalid.i nvalid>
>wrote:
>[color=green]
>>so the likelyhood of a manually-authored XHTML document "in the wild"
>>having such a syntactic error is, thankfully, unlikely.[/color]
>
>Also there are problems with any bugs in a UA - if a UA contains a bug
>which treats a WF document as Non-WF - the user and author are stuffed
>even if they find out about it - all they can do is say "don't use
>client X" hardly a realisitic proposition.
>[/color]

How is that any different from our current situation?

For (albeit a little outdated) example, Netscape 2, 3 and 4 had an
issue where if you omitted any of the table closing tags, even on TD
which the DTD defines as closing implicitly, the browser wouldn't
render the table at all.

To a user of, say, Internet Explorer 3, the document would have
appeared to work. If the author was running IE3, he would never have
noticed his mistake. (or indiscretion, if it was TD he omitted.)

Buggy browsers always have and always will be a problem. I don't see
how a broken XML parser is any different to a broken HTML parser in
this respect. In addition, XML is deliberately a lot easier than HTML
to parse, so the likelyhood of obscure XML parser bugs is slim at
best, especially given the wide variety of generic XML parsers already
"out there" that have been in use for several years.

All the best,
-Claire

[Jim Ley]

Re: Validation: XHTML Transitional vs. HTLM 4.01 Strict

On Sun, 25 Jul 2004 19:38:23 GMT, Claire Tucker <fake@invalid.i nvalid>
wrote:
[color=blue]
>On Sun, 25 Jul 2004 19:29:05 GMT, jim@jibbering.c om (Jim Ley) wrote:
>[color=green]
>>On Sun, 25 Jul 2004 19:18:52 GMT, Claire Tucker <fake@invalid.i nvalid>
>>wrote:
>>[color=darkred]
>>>so the likelyhood of a manually-authored XHTML document "in the wild"
>>>having such a syntactic error is, thankfully, unlikely.[/color]
>>
>>Also there are problems with any bugs in a UA - if a UA contains a bug
>>which treats a WF document as Non-WF - the user and author are stuffed
>>even if they find out about it - all they can do is say "don't use
>>client X" hardly a realisitic proposition.
>>[/color]
>
>How is that any different from our current situation?[/color]

Because UA's are fault tolerant via the design of HTML.
[color=blue]
>Buggy browsers always have and always will be a problem. I don't see
>how a broken XML parser is any different to a broken HTML parser in
>this respect.[/color]

The seriousness of it getting something wrong.
[color=blue]
> In addition, XML is deliberately a lot easier than HTML
>to parse, so the likelyhood of obscure XML parser bugs is slim at
>best, especially given the wide variety of generic XML parsers already
>"out there" that have been in use for several years.[/color]

There were lots of good SGML ones about when Netscape 3 was being
written, didn't stop them screwing it up.

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

[Spartanicus]

Re: Validation: XHTML Transitional vs. HTLM 4.01 Strict

jim@jibbering.c om (Jim Ley) wrote:
[color=blue][color=green]
>>With an XHTML document the browser
>>_could_ warn the user that it is malformed and that it might not exactly
>>represent the author's intentions, and then display it anyway.[/color]
>
>No it couldn't... well by original my interpretation it could, but
>others have convinced me this is wrong.[/color]

Yes it could, the requirement for a standard compliant XHTML renderer is
to throw a parsing error, the spec says nothing about displaying the
result or not.

Some people get confused by Mozilla's inability to display something
when it encounters malformed code (it only throws the parsing error).
Opera handles this as it should be handled, it (incrementally) displays
the code that's rolling in, and displays the parsing error on top when
it encounters malformed code.

Mozilla's method has a more important drawback: it's not able to display
anything before the html has completed loading.

--
Spartanicus