who uses virtual pc for testing webpages

B

Bruce Grubb

http://www.goddamn.co.uk/tobyink/scratch/example >
is 3 lines of validated HTML with no CSS and no Javascript. Simple enough,
right? But it will instantly crash about 85% of your visitors' browsers.
Go ahead: visit it in IE 5+ for Windows. Just make sure you've saved any
work you were doing first.

Didn't crash on my system:
Win98SE and IE5.5 SP2 all updated with M$'s latest "patches" available.
To bad they stopped supporting Win98 though, many people still use it.[/QUOTE]

If HMTL authors had any brains they forget about browser detection (one of
the man uses for conditional comments). If you write spec complient HTML
there is no reason to detect what broswer the end user has and in contrast
to things like <i> conditional comments only work on certain browers
anyway. At least a commented out script will fuction properly without
crashing a broswer.
 
C

Chris Morris

Bruce Grubb said:
If HMTL authors had any brains they forget about browser detection (one of
the man uses for conditional comments). If you write spec complient HTML
there is no reason to detect what broswer the end user has and in contrast
to things like <i> conditional comments only work on certain browers
anyway.

At least a commented out script will fuction properly without
crashing a broswer.

So, you believe that spec compliant HTML will not crash a browser?

Generate a complex set of nested tables. Look at it in Netscape 4.
See if crashes. If not, make the table more complex and repeat.

Not good practice, but entirely valid code.

For more valid but browser crashing code pick a doctype (I think any
HTML one will do) and upload the following to
http://www.example.com/loop.html:
<title>Infinite loop</title>
<meta http-equiv="refresh" content="0; http://www.example.com/loop.html">

It won't crash every browser. Quite a few will cope fine. Some will
go into an uninterruptable (short of kill -9 or OS equivalent) loop.

[1] Arguably conditional comments work in every browser. Mozilla,
Opera, and even Mosaic 2, interpret a conditional comment saying 'IE6
only code' exactly as intended...
 
A

Alan J. Flavell

So, you believe that spec compliant HTML will not crash a browser?

Generate a complex set of nested tables. Look at it in Netscape 4.
See if crashes. If not, make the table more complex and repeat.

Hey, I had a perfectly straightforward blockquoted paragraph which, if
CSS was enabled, would - well, not exactly *crash* Win NN4 - but put
it into a 100% CPU loop from which only brute force (ctrl/alt/del and
taskmanager) could extricate it.

No complex tables needed!
Not good practice, but entirely valid code.

Same here.

(I think they fixed the bug in a later release, though.)
 
B

Bruce Grubb

Chris Morris said:
Bruce Grubb said:
If HMTL authors had any brains they forget about browser detection (one of
the man uses for conditional comments). If you write spec complient HTML
there is no reason to detect what broswer the end user has and in contrast
to things like <i> conditional comments only work on certain browers
anyway.

<i> only works in certain browsers, though. A few more than
conditional comments [1] admittedly.

Other than Linix what browers doesn't said:
So, you believe that spec compliant HTML will not crash a browser?

As long as the broswerr is FULLY HTML 4.01 complient and you don't do
something stupid (ie something needlessly complex or write infinate loops)

Generate a complex set of nested tables. Look at it in Netscape 4.
See if crashes. If not, make the table more complex and repeat.

Not valid as it is needlessly complex as per above.
Not good practice, but entirely valid code.
For more valid but browser crashing code pick a doctype (I think any
HTML one will do) and upload the following to
http://www.example.com/loop.html:
<title>Infinite loop</title>
<meta http-equiv="refresh" content="0; http://www.example.com/loop.html">

It won't crash every browser. Quite a few will cope fine. Some will
go into an uninterruptable (short of kill -9 or OS equivalent) loop.

[1] Arguably conditional comments work in every browser. Mozilla,
Opera, and even Mosaic 2, interpret a conditional comment saying 'IE6
only code' exactly as intended...

The problem is according to Inkster that is NOT true as the quite
straightforward page will crash some IE broswers:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<title>Example</title>
<body><!--[if gte IE 5]><input type example><![endif]--></body>

in short in the browser conditional comments were designed for they don't
work all that well. Which is IMHO a perfect reason NOT to use the blasted
things at all; a commented out script is less likely to cause probelsm and
unless you do something stupid it should not crass a browser
 
T

Toby A Inkster

Bruce said:
The problem is according to Inkster that is NOT true as the quite
straightforward page will crash some IE broswers:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<title>Example</title>
<body><!--[if gte IE 5]><input type example><![endif]--></body>

in short in the browser conditional comments were designed for they don't
work all that well.

It's not the conditional comments that cause Explorer to crash. These 20
characters of HTML alone will cause Explorer to crash:

<input type example>

The problem is that that is not valid. The DOCTYPE, title, body and
conditional comments are only required in order to make it valid.
Other than Linix what browers doesn't <i> work in?

I have never heard of "Linix", but I can assure you that the following
browsers do not fully support <i>:

- Links prior to version 2;
- Lynx;
- eLinks;
- w3; and
- w3m.
 
B

Bruce Grubb

Toby A Inkster said:
Bruce said:
The problem is according to Inkster that is NOT true as the quite
straightforward page will crash some IE broswers:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<title>Example</title>
<body><!--[if gte IE 5]><input type example><![endif]--></body>

in short in the browser conditional comments were designed for they don't
work all that well.

It's not the conditional comments that cause Explorer to crash. These 20
characters of HTML alone will cause Explorer to crash:

<input type example>

That is because "The INPUT element defines a form control for the user to
enter input."
The problem is that that is not valid. The DOCTYPE, title, body and
conditional comments are only required in order to make it valid.

BUT as I previous pointed old wise one:

"Some browsers close comments on the first ">" character, so to hide script
content from such browsers, you can transpose operands for relational and
shift operators (e.g., use "y < x" rather than "x > y") or use scripting
language-dependent escapes for ">"."
<http://www.w3.org/TR/REC-html40/interact/scripts.html>

While it might be argued that this would have been better placed earlier in
the HMTL specs it does show WHAT the problem with the page is and it also
shows FAILURE to follow HTML specs.


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<title>Example</title>
<body><!--[if gte IE 5]>
^ read asend of comment
(known issue spec warns about)

<input type example>

Improper use of input tag
<http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.4>

<![endif]--></body>

browser never gest this far.

As I said in my original rebuttal:

As long as you write to the standard (opposed to exploiting bugs
or quirks in Netscape and Explorer) you don't NEED to go testing
your HTML on multiple browsers.

The above exploits a quirk so well known that it is actually mentioned IN
the specs. Ergo it is not valid HTML by the specs. Since this was in the
scripts section I called it a 'script' because it will try to impliment the
improper tag when the if statement is true. Small surprise the stupid
thing crashes.

Validators are a tool and lets face it since they are automatic programs
they *will* vailidate stuff that the spec warns there can be problems with.
They are particually dumb about anything between <!-- and -->.


Which is why I speficially stated IN THE BEGINING that as long as you don't
exploit bugs or quirks of a certain browser HTML that validates negates the
need of desplaying the HTML on every browser you can get your hands on.

WFIW Balthisar Tidy took the above and translated it into this with the
following HTML errors (commented out per the spec):

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta content="HTML Tidy for Mac OS X (vers 1st March 2003), see
www.w3.org" name="generator">
<title>Example</title>
</head>
<body>
<form><input type="" example=""></form>
<!--<input&gt; isn't allowed in <body&gt; elements, inserting implicit
<form&gt;>
<!--<form&gt; lacks action attribute>
<!--unknown attribute "example">
</body>
</html>


On a side note to the genius who asked what a tag was; go read section 3 of
the HTML 4.01 spec. It tells you right there.
<http://www.w3.org/TR/REC-html40/intro/sgmltut.html#h-3.1>
 
C

Chris Morris

Bruce Grubb said:
Bruce Grubb said:
If HMTL authors had any brains they forget about browser
detection (one of the man uses for conditional comments). If
you write spec complient HTML there is no reason to detect what
broswer the end user has and in contrast to things like <i>
conditional comments only work on certain browers anyway.

<i> only works in certain browsers, though. A few more than
conditional comments [1] admittedly.

Other than Linix what browers doesn't <i> work in?

In addition to the ones Toby mentioned:
IBM Home Page Reader
JAWS
CERN Line Mode (!)
etc
As long as the broswerr is FULLY HTML 4.01 complient and you don't do
something stupid (ie something needlessly complex or write infinate loops)

Ah, so provided you write code that's both valid *and sensible* all
browsers will cope. No argument there. What browsers consider
'sensible' is a moving target, though, and (see below, and Alan's much
simpler example) some of them will choke on code that _isn't_ what
most people would consider needlessly complex.
Not valid as it is needlessly complex as per above.

When you say "not valid" do you mean "not a valid example" or "that
isn't valid code". I'll assume the former, since the latter would be
plain wrong.

The site isn't around anymore, it's been redesigned twice since, but
in a previous incarnation of it the table layout code was so complex
that NS4 crashed. The limit of complexity, in certain versions of
NS4, wasn't particularly high, and if you were a complex table layout
designer, possible to reach without wanting to.

I've also been able to crash Mosaic with fairly simple table code, but
to be fair to it that version did have the table support labelled
'experimental'.

Also, missing off the 'optional' </td> or </tr> can cause browser
crashes, and I've heard reports that some browsers will crash on
[1] Arguably conditional comments work in every browser. Mozilla,
Opera, and even Mosaic 2, interpret a conditional comment saying 'IE6
only code' exactly as intended...

The problem is according to Inkster that is NOT true as the quite
straightforward page will crash some IE broswers:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<title>Example</title>
<body><!--[if gte IE 5]><input type example><![endif]--></body>

in short in the browser conditional comments were designed for they don't

No, in the browser they're designed for they work 'perfectly' as well.
Unfortunately the thing 'commented out' in this particular example
*doesn't*.
work all that well. Which is IMHO a perfect reason NOT to use the blasted
things at all; a commented out script

is less likely to cause probelsm and unless you do something stupid
it should not crass a browser

Right. The reason that crashes IE is because IE interprets it _not
according to spec_ and tries to read the (invalid, but you can put
invalid code inside comments without making the document invalid,
because it's commented out) <input type example> as if it weren't
commented out.

The page is valid according to spec because conditional comments don't
exist *as such* in the spec, they're just the same as any other sort
of comment. A correct parser will treat that after comment removal
as:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<title>Example</title>
<body></body>

Completely valid.
 
C

Chris Morris

Bruce Grubb said:
BUT as I previous pointed old wise one:

"Some browsers close comments on the first ">" character, so to hide script
content from such browsers, you can transpose operands for relational and
shift operators (e.g., use "y < x" rather than "x > y") or use scripting
language-dependent escapes for ">"."
<http://www.w3.org/TR/REC-html40/interact/scripts.html>

While it might be argued that this would have been better placed earlier in
the HMTL specs it does show WHAT the problem with the page is and it also
shows FAILURE to follow HTML specs.

No, it shows failure to follow some (fairly outdated) _advice_ in the
_descriptive text_ in HTML specs.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<title>Example</title>
<body><!--[if gte IE 5]>
^ read asend of comment
(known issue spec warns about)

See below for IE6's parsing of > in comments. It's correct.
As I said in my original rebuttal:

As long as you write to the standard (opposed to exploiting bugs
or quirks in Netscape and Explorer) you don't NEED to go testing
your HTML on multiple browsers.

Because, apart from bugs or quirks that the spec knows about, there's
absolutely no chance that a present or future browser will have a bug
or quirk not mentioned in the spec that valid code will trigger.
The above exploits a quirk so well known that it is actually mentioned IN
the specs. Ergo it is not valid HTML by the specs. Since this was in the
^^^^^^^^^^^^^^^^^^^^^^^^^^^

*Yes* *it* *is*. Validation is the checking of the HTML code against
its SGML doctype. The comment in the spec about comment ending is a
warning about browser bugs *in force at that time*. Since the HTML 4
spec is *over five years old*, it shouldn't trip up a relatively
modern browser like IE6. And indeed, it doesn't. IE6 correctly displays

"<!-- Comment > Still comment --> Not comment"
as
"Not comment"
Validators are a tool and lets face it since they are automatic programs
they *will* vailidate stuff that the spec warns there can be problems with.

Yes, it's a _warning_, not a violation. Furthermore it's a warning
based on the browsers around in the mid-late 90s, often on the
browsers that were _dying out_ then.
Which is why I speficially stated IN THE BEGINING that as long as you don't
exploit bugs or quirks of a certain browser HTML that validates negates the
need of desplaying the HTML on every browser you can get your hands on.

And how, without displaying the HTML in a browser, can you know that
you haven't *accidentally* 'exploited' a bug or quirk? There are
several bugs/quirks not mentioned in the specs (how could they be,
those browsers hadn't been invented then) that can be triggered by
entirely valid code, without exploiting bugs quirks of other browsers,
that will crash (or at least fail to work properly in) some browsers.
 
B

Bruce Grubb

Chris Morris said:
Bruce Grubb said:
BUT as I previous pointed old wise one:

"Some browsers close comments on the first ">" character, so to hide script
content from such browsers, you can transpose operands for relational and
shift operators (e.g., use "y < x" rather than "x > y") or use scripting
language-dependent escapes for ">"."
<http://www.w3.org/TR/REC-html40/interact/scripts.html>

While it might be argued that this would have been better placed earlier in
the HMTL specs it does show WHAT the problem with the page is and it also
shows FAILURE to follow HTML specs.

No, it shows failure to follow some (fairly outdated) _advice_ in the
_descriptive text_ in HTML specs.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<title>Example</title>
<body><!--[if gte IE 5]>
^ read asend of comment
(known issue spec warns about)

See below for IE6's parsing of > in comments. It's correct.

Irrelevent as other people have pointed out not everyone uses the latest
browser or has added patches to the old ones. Besises it is a BROSWER
specific issue which is another non-no.
Because, apart from bugs or quirks that the spec knows about, there's
absolutely no chance that a present or future browser will have a bug
or quirk not mentioned in the spec that valid code will trigger.

Excluding commented out invalid tags and infinity loops what html will
crash a broswer (since HTML is NOT a page layout format displaying things
is an irrelevent issue)?
^^^^^^^^^^^^^^^^^^^^^^^^^^^

*Yes* *it* *is*. Validation is the checking of the HTML code against
its SGML doctype.

That is one method of validating HTML. But since that are automated
programs they will validated stuff that reading the spec in detail will
indicated could be a problem (the '>' prematurely ending a comment for a
example)

VPenman over in the 'CR2 Expansion Bug/Feature' thread some years ago. The
guy simply threw Windows help files at Robohelp and trusted that the
program generated 'reasoanble' HTML. The HTML Robohelp generated (thanks
to some really stupid tweeking) is some of the worst my HTML validators
have ever seen.

The supreme act of idiocy in this product? The creation of TWO sets of
HTML: one for Windows one for Macs. Of course trying VPenman to defend this
stupidity got him HTML specs quoted up one side and down the other.

His defence? "They do work fine in Windows, but did not work on the Mac."

In short VPenman followed the Windows idea of throw the thing at as many
[windows] broswers and if it works than it is right. Even if it is by the
specs way wrong.
The comment in the spec about comment ending is a
warning about browser bugs *in force at that time*. Since the HTML 4
spec is *over five years old*, it shouldn't trip up a relatively
modern browser like IE6. And indeed, it doesn't. IE6 correctly displays

"<!-- Comment > Still comment --> Not comment"
as
"Not comment"


Yes, it's a _warning_, not a violation. Furthermore it's a warning
based on the browsers around in the mid-late 90s, often on the
browsers that were _dying out_ then.

And yet accroding to Inkster there are broswers that STILL have problem
with an '>' in a comment just as this "old" spec warns. Which means the
warning is STILL VALID. VPenman's HTML was so bad he ignored spec going
all the way back RFC 1738 (Dec 1994) so this dog which didn't hunt in 1998
when I lamblasted VPenman and his piss poor HTML certainly doesn't hunt now.

Too many times I have seen HTML authors blindly generate HTML that doesn't
even validate but as long as it works on any [windows] broswer that they
throw the botchup at it is 'right'. Is that the mentality you support?
And how, without displaying the HTML in a browser, can you know that
you haven't *accidentally* 'exploited' a bug or quirk? There are
several bugs/quirks not mentioned in the specs (how could they be,
those browsers hadn't been invented then) that can be triggered by
entirely valid code, without exploiting bugs quirks of other browsers,
that will crash (or at least fail to work properly in) some browsers.

If it is a commented out tag or the like remove the comments and see if the
things still validates; if not then rewrite the thing. Improper displaying
of elements is not a problem as HTML is NOT nor NEVER will be a page markup
format.

Sure you can write infinate loops in any thing HTML calls to and it will
validate (but will likly cause problems) but that is not the validator's
fault.

Validators like HTML authoring program are tools and like any tool they do
require a little use of common sence. Would you use a wrench to hammer a
nail; sure you could use it that way but why unless you absolutely had to?

The same question goes in regards to commented out invalid tags, infinate
loops, and browser specific crap. Is there a reason it is there other than
'I want to show that I can write something that validates but will cause
some browsers to crash' or 'I don't give a flying flip what the WWW uses
they *must* use browser 'x' version 1.0.1'?

If there is there is no reason that such junk is there other than an ego
trip jolly fest than there is NO valid reason for it to be there.

Side note Inkster's pages does NOT validates using the validator linked to
at webpagesthatsuck <http://www.webpagesthatsuck.com/>. That validator in
fact states:

There were 2 document structure problems found.
There are 2 potential meta tag errors in your document
There is 1 browser support conflict in your document.
and finally

A Squished page that is reduced in size by 67.9 % to 44 bytes is available
here.

So by this validator at least this page is NOT valid HTML just as I said in
the begining. You lose Inkster.
 
S

Steve Pugh

Bruce Grubb said:
That is one method of validating HTML.

It is the only _method_ of validating HTML. There are other checks you
can run on it, but they can not be called validation because in the
context of HTML there is a precise technical definition of validation.
Side note Inkster's pages does NOT validates using the validator linked to
at webpagesthatsuck <http://www.webpagesthatsuck.com/>.

I presume you mean this tool:
http://www.fixingyourwebsite.com/drhtml.html

It's not a validator.
That validator in fact states:

There were 2 document structure problems found.

Not errors. The opening and closing tags for the HTML and HEAD
elements are optional in all versions of HTML.
There are 2 potential meta tag errors in your document

Not errors. No document _needs_ meta tags, and as most search engines
ignore them these days there is no justification in claiming that
description and keyword meta tags should always be included.
There is 1 browser support conflict in your document.
and finally

Oddly, it says that there's one error, but it also says "There are no
browser support conflicts in your document. Congratulations!".
Switching to verbose mode it seems to think that there's a problem
with IE 1.0 not understanding the said:
So by this validator at least this page is NOT valid HTML just as I said in
the begining. You lose Inkster.

Have you any idea how much of a fool you've just made yourself look?

Steve
 
S

Steve Pugh

Steve Pugh said:
It is the only _method_ of validating HTML.

Hmm, my emphasis seems to have wandered a bit off course. Hey! One
word to the left if you please. Thank you.

Steve
 
T

Toby A Inkster

Bruce said:
Excluding commented out invalid tags and infinity loops what html will
crash a broswer (since HTML is NOT a page layout format displaying things
is an irrelevent issue)?

Here's another one for you then...

http://www.goddamn.co.uk/tobyink/scratch/crash

Will crash IE on Windows 98 -- does not crash IE on Windows NT or Mac
though.

No scripts, no CSS, no applets, no frames, no tables, and Bruce -- just
for you -- no comments.
 
E

Eric B. Bednarz

Glad we cleared *that* up; now that the verdict has been brought in,
it's about time to impose an adequate sentence upon Toby.
I suggest one year Macintrash, no probation.
Have you any idea how much of a fool you've just made yourself look?

Psst; until BBC2 brings back The Simpsons, I'd really like to see this
thread continue.
 
B

Bruce Grubb

Toby A Inkster said:
Here's another one for you then...

http://www.goddamn.co.uk/tobyink/scratch/crash

Will crash IE on Windows 98 -- does not crash IE on Windows NT or Mac
though.

No scripts, no CSS, no applets, no frames, no tables, and Bruce -- just
for you -- no comments.

Cute, you forget what I ALSO said:


This little gem violates basic common sence rather than HTML specs

<body background="file:///C:/CON/CON">

The file URL is for LOCAL (to the broswer) files. Having a broswer do this
is just asking for trouble and there is no real reason anybody in their
right mind would use something like this.
 
C

Chris Morris

Bruce Grubb said:
This little gem violates basic common sence rather than HTML specs

Yes, that's the point! You can't argue that validation is sufficient
to avoid browser problems if you then require common sense too. There
is no good reason (apart from a very obscure part of the Windows 98 OS
structure) that that code should cause any problems in any browser.
And yet it does. Perfectly valid, largely in line with common sense
(c:/CON/CON could be an image were it not a forbidden filename in
W98, and how many people who, say, only *test* on NT would have problems).

Obviously, they could and should test on W98 too. But then we're back
to the need to test pages, even ones which validate, in multiple
browsers, which is what you were arguing against.
<body background="file:///C:/CON/CON">

The file URL is for LOCAL (to the broswer) files. Having a broswer do this
is just asking for trouble and there is no real reason anybody in their
right mind would use something like this.

No, no-one *ever* distributes documentation on CDs in HTML format for
viewing in a local browser. And no-one would ever develop an
application with the acronym 'CON'.
 
C

Chris Morris

Bruce Grubb said:
Irrelevent as other people have pointed out not everyone uses the latest
browser or has added patches to the old ones. Besises it is a BROSWER
specific issue which is another non-no.

Yes, not everyone uses the latest browser. IE6 is some way older than
the latest browser. But you have to put some sort of cut off on
things - CERN Linemode doesn't support <form> or <img> despite them
being in the specification. If you don't test in it, you'll never
know why the CERN Linemode users never fill in your forms.
Excluding commented out invalid tags and infinity loops what html will
crash a broswer

Complex nested tables in Netscape 4. Entirely valid code, nothing
that should generate an infinite loop.

You may think it's not sensible to use complex nested tables. You'd
probably be right. But the CSS vs tables layout argument has been
going for a long time, and at the time HTML 4 was written, tables were
just about the only option for complex layouts. And I have seen the
occasional legitimate use of nested tables for genuine tabular data.
(since HTML is NOT a page layout format displaying things is an
irrelevent issue)?

Rubbish. Displaying things is a very relevant issue. How they are
displayed will vary considerably from browser to browser, user to
user, medium to medium, but it *is* very relevant than things are
displayed *somehow*.
That is one method of validating HTML.

As has been pointed out, the *only* way of validating HTML, by the
definition of 'validating HTML'.
But since that are automated programs they will validated stuff
that reading the spec in detail will indicated could be a problem
(the '>' prematurely ending a comment for a example)

Yes! Therefore validation is insufficient, and one needs to test in
browsers too to find out what they can and can't handle. Or do you
believe every browser bug and quirk, including the ones in browsers
released after the spec was published, is documented and warned
against somewhere in the HTML 4.01 spec? And, assuming you're not an
idiot or a troll, and therefore answer no to that question, how do you
propose to find out what browser bugs and quirks do exist without
testing in the browsers?
<snip story about someone with an automatic generator>
In short VPenman followed the Windows idea of throw the thing at as many
[windows] broswers and if it works than it is right. Even if it is by the
specs way wrong.

Nice story, but a bit irrelevant. We know that validation is a good
idea. No-one is arguing (in this thread) that it's pointless, or
harmful. Merely that it is incredibly insufficient.
Too many times I have seen HTML authors blindly generate HTML that doesn't
even validate but as long as it works on any [windows] broswer that they
throw the botchup at it is 'right'. Is that the mentality you support?

No. My normal browser (for non-testing purposes) isn't a windows
browser, my 2nd and 3rd most used browsers aren't graphical. I don't
write invalid code without an exceptionally good reason (not found one
yet for my own HTML, though things like <nobr> have been useful to
others).

From your post <[email protected]>
- Which is why I speficially stated IN THE BEGINING that as long as you don't
- exploit bugs or quirks of a certain browser HTML that validates negates the
- need of desplaying the HTML on every browser you can get your hands on.

I'll ask again. How, *without* 'testing in every browser you can get
your hands on', do you make sure that you aren't *accidentally*
'exploiting bugs or quirks', given that the validator (or even reading
the specs) is insufficient.
If it is a commented out tag or the like remove the comments and see if the
things still validates; if not then rewrite the thing. Improper displaying

Anything contained in comments should be irrelevant. If it isn't it's
a browser bug. Suppose I find a browser in which the presence of <td>
without </td> causes the browser to crash. Clearly the solution is to
add the said:
of elements is not a problem as HTML is NOT nor NEVER will be a page markup
format.

Improper displaying of elements is a problem! What do you do with
your HTML code if you don't give it to a user-agent to display?
Exactly how it displays it may not be an issue, but that it displays
it somehow is.

Okay, example. I'll let you pick any HTML 4 doctype to put on the
front of it, it makes no difference and it will validate perfectly:

<title>Test page</title>
<img src="elephant.jpg" alt="Elephants are large">

Now, this is clearly valid code. If you want to be really picky,
throw in the optional html/head/body elements too.

I know of at least one browser that will neither display the image nor
the alt text. Is this warned of in the HTML 4 spec? No. How do I
know? Because I tested in that browser. Is it an old obsolete
browser that no-one uses? Yes. Does that matter? According to you,
no. So said:
Besises it is a BROSWER specific issue which is another non-no
Sure you can write infinate loops in any thing HTML calls to and it will
validate (but will likly cause problems) but that is not the validator's
fault.

No, it's not.
Validators like HTML authoring program are tools and like any tool they do
require a little use of common sence. Would you use a wrench to hammer a
nail; sure you could use it that way but why unless you absolutely had to?

This is what everyone has been saying this whole thread. Validators
are useful tools but are not sufficient to make sure that your page
works.
The same question goes in regards to commented out invalid tags, infinate
loops, and browser specific crap. Is there a reason it is there other than
'I want to show that I can write something that validates but will cause
some browsers to crash' or 'I don't give a flying flip what the WWW uses
they *must* use browser 'x' version 1.0.1'?

The former _is_ important. If someone can write it deliberately, then
someone else can write it accidentally. If it validates, and they
assume from that that it is safe, they could be in for a shock.
If there is there is no reason that such junk is there other than an ego
trip jolly fest than there is NO valid reason for it to be there.

Maybe it was put there by someone who didn't know it would cause a
problem. I've given elsewhere a legitimate reason why someone might
have _accidentally_ put a reference to c:/CON/CON in a HTML document,
for example, not knowing it would cause a problem.
 
K

Karl Smith

Bruce Grubb said:
This little gem violates basic common sence rather than HTML specs

<body background="file:///C:/CON/CON">

The file URL is for LOCAL (to the broswer) files. Having a broswer do this
is just asking for trouble and there is no real reason anybody in their
right mind would use something like this.

To test for the presence of a file at "file:///C:/CON/CON"? As in: "If
this page has a green background, you have installed the download to
the correct path."
 
B

Bruce Grubb

Chris Morris said:
Yes, that's the point! You can't argue that validation is sufficient
to avoid browser problems if you then require common sense too. There
is no good reason (apart from a very obscure part of the Windows 98 OS
structure) that that code should cause any problems in any browser.
And yet it does. Perfectly valid, largely in line with common sense
(c:/CON/CON could be an image were it not a forbidden filename in
W98, and how many people who, say, only *test* on NT would have problems).

Obviously, they could and should test on W98 too. But then we're back
to the need to test pages, even ones which validate, in multiple
browsers, which is what you were arguing against.


No, no-one *ever* distributes documentation on CDs in HTML format for
viewing in a local browser. And no-one would ever develop an
application with the acronym 'CON'.

But the above is NOT on CD genius it is on the INTERNET which why I
lamblasted it. There is no real reason an INTERNET HTML file should be
looking for HTML files on your local harddrive (cookies are another matter).

As I said earlier on we Mac users had a joke back in the late 1980s:

How many Microsoft programmers does it take to change a lightbulb?

None. They declair darkness the new standard.


Now the joke has one more line:

Which explains why Windows programers and users alike have been stumbling
aorund in the dark for the last 15 years.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top