who uses virtual pc for testing webpages

[Chris Morris]

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).

It'll crash just as well if it was read from a CD, though. Or are you
arguing that people writing HTML files distributed offline don't need
to conform to the same standards as those writing online ones?

 

[Bruce Grubb]

It'll crash just as well if it was read from a CD, though. Or are you
arguing that people writing HTML files distributed offline don't need
to conform to the same standards as those writing online ones?

But the above does NOT conform because it is WINDOWS specific violating the
whole consept that HTML filez AND URLs be *platform and OS independent*

In fact the spec cited for dear braindead VPenman (RFC 1738) specifically
states:

A file URL takes the form:

file://<host>/<path>

where <host> is the fully qualified domain name of the system on
which the <path> is accessible, and <path> is a hierarchical
directory path of the form <directory>/<directory>/.../<name>.

For example, a VMS file

DISK$USER:[MY.NOTES]NOTE123456.TXT

might become

<URL:file://vms.host.edu/disk$user/my/notes/note12345.txt>

As a special case, <host> can be the string "localhost" or the empty
string; this is interpreted as `the machine from which the URL is
being interpreted'.

The file URL scheme is unusual in that it does not specify an
Internet protocol or access method for such files; as such, its
utility in network protocols between hosts is limited.


W3C has since thoughtfully provided this layman's explination:

"There is clearly a danger of confusion that a link made to a local file
should be followed by someone on a different system, with unexpected and
possibly harmful results. Therefore, the convention is that even a "file"
URL is provided with a host part. This allows a client on another system
to know that it cannot access the file system, or perhaps to use some other
local mecahnism to access the file."
<http://www.w3.org/Addressing/URL/4_1_File.html>

----

The problem is that crossing volumes is NOT standarized and treating it
like it was will produce "unexpected and possibly harmful results"

Ergo while file:///C:/CON/CON" will valide on most validators it is
NOT valid per RFC 1738 because C: is NOT a directory it is a VOLUME
and requires <host> for the URL to fuction properly.

The fact that per RFC 1738 the file URL scheme is NOT crossplatform for
absolute URLs can be demonstrated by anyone taking a local file created on
a Mac BEFORE MacOS X and trying to use the thing under MacOS X. Before
MacOS X local urls has this structure file:///volume_name/directory/directory
however under MacOS X (and some other Unix clones) it has the structure
file:///Volumes/volume_name/directory/directory. And unlike Windows
machines which are still learning the A:, B:, C:'s Mac and Unix
directories can have actual names.

So the above violates two aspects of HTML specs: no host (127.0.0.1 in this
case) and it is NOT platform independent. I lambblasted VPenman on this
over optimizing idiocy and to come up with 'I found something that
validates but breaks' you have done the same thing.

Face it guys so far all you have done is demonstrate you have NOT read HTML
specs or if you have you certainly have not understood them. I have done
both which is how I know that all of this so far is smoke and mirrors.

 

[Toby A Inkster]

So the above violates two aspects of HTML specs: no host (127.0.0.1 in this
case) and it is NOT platform independent.

Firstly "file:///C:/CON/CON" is perfectly platform independent. On any
Unix system:

mkdir -p '/C:/CON/'
touch '/C:/CON/CON'

and you now have a file called "C:/CON/CON" on the Unix file system.

Secondly, RFC 1738 says leaving out the host is fine: it defaults to
"localhost".

Thirdly, HTML specs don't say anything about any of this anyway.

 

[Chris Morris]

Firstly "file:///C:/CON/CON" is perfectly platform independent. On any
Secondly, RFC 1738 says leaving out the host is fine: it defaults to
"localhost".
Agreed.

Thirdly, HTML specs don't say anything about any of this anyway.

Well, they delegate defining of URLs to that RFC, so arguably they do.

 

[Chris Morris]

But the above does NOT conform because it is WINDOWS specific violating the
whole consept that HTML filez AND URLs be *platform and OS independent*

As has been pointed out in Toby's reply, it *does* conform to the
specification. It will mean a somewhat different file on this Linux
machine to the one it would mean on a windows machine or on the Mac on
the testing bench in the office, but it does fit the RFC.

Anyway, clearly you don't like this example, and to be fair I can't
see it as being particularly likely. So, what about this one.

text/x-hypothetical-stylesheet-format represents any stylesheet format
of your choosing, *with the exception of CSS*. Ignore the fact that
it has a .css extension, as you know from the specs it's the mime-type
sent back by the server that's the crucial thing.

So (expand to any 2/3/4 doctype, take your pick, it makes no
difference to the result) It even works in XHTML 1 (served according
to Appendix C, that is):

<!DOCTYPE ...>
<title>Hypothetical Stylesheet Demonstration</title>
<link rel="stylesheet" href="http://www.example.com/styles.css"
type="text/x-hypothetical-stylesheet-format">
<p>Demonstrates how to link in HSS stylesheets</p>

For brevity I've missed out all the optional elements. It has exactly
the same effect with them.

This will fail to display on Netscape 4. And I don't mean minor
rendering errors, I mean completely failing to display the entire
page, as if it wasn't even there.

Note that the reason I don't use CSS stylesheets is that I want
Netscape 4 to ignore them - it claims to understand CSS, it doesn't
claim to understand XHSF, therefore it shouldn't do anything with it.
(just as Mozilla correctly ignores text/plain stylesheets)

This is *not* a hypothetical situation, it's one I've seen happen many
times across the internet (with minor variations, usually it's with a
CSS stylesheet), none of which could be detected no matter how closely
the HTML file was checked against the specs (if you find a
discrepancy, feel free to correct it), but would be detected in an
instant with a simple check with the right web browser.

 

[Bruce Grubb]

<!DOCTYPE ...>
<title>Hypothetical Stylesheet Demonstration</title>
<link rel="stylesheet" href="http://www.example.com/styles.css"
type="text/x-hypothetical-stylesheet-format">
<p>Demonstrates how to link in HSS stylesheets</p>

For brevity I've missed out all the optional elements. It has exactly
the same effect with them.

This will fail to display on Netscape 4. And I don't mean minor
rendering errors, I mean completely failing to display the entire
page, as if it wasn't even there.

Now *this* I will admit is royally screwed up. Netscape 4.x should at
least default gracefully though that abomination was so buggy they should
have included a coupon for a free can of Raid with it.

But Netscape 4.x is OLD, very old. The program is up to 7.1 now and
version 6 will run any any OS and hardware within reason (ie less than five
years old). Now if a CURRENT modern broswer is doing this piece of
stupidity that is an issue but this is the broswer equivelent of an Edsil.

Note that the reason I don't use CSS stylesheets is that I want
Netscape 4 to ignore them - it claims to understand CSS, it doesn't
claim to understand XHSF, therefore it shouldn't do anything with it.
(just as Mozilla correctly ignores text/plain stylesheets)

This is *not* a hypothetical situation, it's one I've seen happen many
times across the internet (with minor variations, usually it's with a
CSS stylesheet), none of which could be detected no matter how closely
the HTML file was checked against the specs (if you find a
discrepancy, feel free to correct it), but would be detected in an
instant with a simple check with the right web browser.

But this raises a valid question. Should you write for a poorly written
browser (Netscape 4 was notorious buggy even by broswer standards
<http://www.richinstyle.com/bugs/netscape4.html>) or should you
write to the specs and hope the users have enough brains to stop doing the
Internet equivalent of driving a Model T down the interstate?

 

[Chris Morris]

Now *this* I will admit is royally screwed up. Netscape 4.x should at
least default gracefully though that abomination was so buggy they should
have included a coupon for a free can of Raid with it.

But Netscape 4.x is OLD, very old. The program is up to 7.1 now and
version 6 will run any any OS and hardware within reason (ie less than five
years old). Now if a CURRENT modern broswer is doing this piece of
stupidity that is an issue but this is the broswer equivelent of an Edsil.

While it is old, and exceptionally buggy, it was the current modern
browser once. I expect in a few years time we'll be considering IE6
to be just as bad as we now consider NS4.

But this raises a valid question. Should you write for a poorly written

Write around rather than write for This particular problem can be
solved without modifying the document at all.

browser (Netscape 4 was notorious buggy even by broswer standards
<http://www.richinstyle.com/bugs/netscape4.html>) or should you

Oh, obviously write to the specs. But all browsers have bugs, some
fairly severe (especially when CSS is used), and it'll be a few
browser generations yet before they're ironed out. To be replaced by
new bugs, no doubt.

Modern browser bugs don't tend to be in HTML spec interpretation (some
of IE's behaviour excepted), but in CSS spec interpretation, or in
other areas. It does make simply checking against the specs
insufficient, though. Wish it didn't, it'd make my job far easier.

Mozilla and IE (latest versions) both have a history stack that isn't
case-sensitive. This causes some very unexpected behaviour. It's not
a HTML issue per se, no, but it does give problems with otherwise
valid pages. http://www.dur.ac.uk/c.i.morris/teststart.html (no, the
example pages don't validate, but it doesn't make any difference if
they do)

write to the specs and hope the users have enough brains to stop doing the
Internet equivalent of driving a Model T down the interstate?

Netscape 4, while dying out (and you were arguing earlier regarding
not putting lone '>' in comments that older browsers should be
supported too) is still reasonably common in certain environments.
Quite often in a way that the user can't get around.

 

[Brian]

I expect in a few years time we'll be considering IE6
to be just as bad as we now consider NS4.

in a few years time? you mean we shouldn't be thinking that way already?
SCNR