weird but it works

[thedarkman]

I started a new directory on my main website because the root is getting too big, and noticed something weird.

Some of the files in the new directory are linked to the root like this:


<p>Back To <A HREF="\other_contributors.html" target="_blank">Other Contributors Index</A>


and others like this


<p>Back To <A HREF="/other_contributors.html" target="_blank">Other Contributors Index</A>

I've obviously made a coding error, but they both work. Weird or not?

 

[thedarkman]

I don't follow, but then I seldom do.

Directory Level

Level One

Level Two

Level Three



Example < http://billyray.is-a-painter.com/ >

Welcome to the directory listing of /

./ same Level

././ same Level

All Root Level

and Folders / Files path ./.*.



http://billyray.is-a-painter.com/Level Two/

./ Same Level

././ Back to Level One

All Level Two

and Folders /Files path = ./../.*.





http://billyray.is-a-painter.com/Level Three/

./ Same Level

././ Back to Level Two

All Level Three

and Folders /Files path ./../../.*.

 

[Denis McMahon]

[/ and \ both work as directory separators in relative links]

I've obviously made a coding error, but they both work. Weird or not?

Possibly by design, possibly a feature of your hosts software. But
possibly not a feature to be relied on, unless you can find it documented.

The use of "\" as a path separator in URLs is not a documented feature of
RFC 3986.

 

[Jukka K. Korpela]

The use of "\" as a path separator in URLs is not a documented feature of
RFC 3986.

In "URL Living Standard", as of 25 November 2013, it is defined as
causing a "parse error" but with explicitly defined handling (that
spells "naughty boy, but we'll do what you mean"):
http://url.spec.whatwg.org/#host-parsing

(Of course, as you read this, it might have been changed without prior
or posterior notice.)

If you ask me, "living standard" is an oxymoron if there ever was one,
but "living standards" is what the Web Wide World is moving to.

In this specific case, the error processing rule makes a lot of sense.
There is hardly any other thing that "\" in a URL might mean than "/".

 

[Denis McMahon]

In "URL Living Standard", as of 25 November 2013, it is defined as
causing a "parse error" but with explicitly defined handling (that
spells "naughty boy, but we'll do what you mean"):
http://url.spec.whatwg.org/#host-parsing

(Of course, as you read this, it might have been changed without prior
or posterior notice.)

If you ask me, "living standard" is an oxymoron if there ever was one,
but "living standards" is what the Web Wide World is moving to.

I agree with the living standard thing. Once approved / ratified a
standard should be a reference that is set in stone. A living standard
isn't a standard, it's today's recommended / current best practice, which
might have been the same yesterday, or might not, and could be the same
tomorrow, or could not.

In this specific case, the error processing rule makes a lot of sense.
There is hardly any other thing that "\" in a URL might mean than "/".

Agreed, but I'm still of the school that thinks browsers should throw a
"600 - wtf, I can't display this, it was coded by a moron" error for html
that doesn't match the doctype. Of course, this raises the question
"which doctype do I default to?" when none is supplied.

1) If xhtml element closures are detected, try xhtml 1.1, if that doesn't
work try xhtml 1.0(see 3), then throw wtf.

2) If no xhtml element closures are detected, work down from html 5 to
html 4.01(see 3) to html 3.2 to html 2.0 to html 1.0, then throw wtf.

3) For xhtml 1.0 and html 4.01, try strict, frameset, transitional in
that order.

If more browsers threw "600 - wtf, I can't display this, it was coded by
a moron" instead of trying to fix and display broken web pages, the world
would be a much better place.

 

[Christoph Michael Becker]

I agree with the living standard thing. Once approved / ratified a
standard should be a reference that is set in stone. A living standard
isn't a standard, it's today's recommended / current best practice, which
might have been the same yesterday, or might not, and could be the same
tomorrow, or could not.

Then you may prefer W3C recommendations.

Agreed, but I'm still of the school that thinks browsers should throw a
"600 - wtf, I can't display this, it was coded by a moron" error for html
that doesn't match the doctype.

There has been an attempt to do so: it is called XHTML. However, this
was never really used -- at least I'm not aware of websites sending
their content as application/xhtml+xml.

Of course, this raises the question
"which doctype do I default to?" when none is supplied.

It might break quite some websites if a missing DOCTYPE would trigger
auto detection of the desired one instead of forcing the browsers to
quirks mode.

1) If xhtml element closures are detected, try xhtml 1.1, if that doesn't
work try xhtml 1.0(see 3), then throw wtf.

Why not start with XHTML5?

2) If no xhtml element closures are detected, work down from html 5 to
html 4.01(see 3) to html 3.2 to html 2.0 to html 1.0, then throw wtf.

3) For xhtml 1.0 and html 4.01, try strict, frameset, transitional in
that order.

If more browsers threw "600 - wtf, I can't display this, it was coded by
a moron" instead of trying to fix and display broken web pages, the world
would be a much better place.

Um, the WWW would be a *much* smaller place then...

 

[Denis McMahon]

Why not start with XHTML5?

Does anyone actually use that? It always seemed as if it was either a
solution that was trying to find a problem to fix, or the hammer that
made everything into a nail.

It seems to me that what happened was everyone thinks they're writing
html 5 instead and you get a combination of html style and xml style eg
you'll come across elements with several and sometimes all variations of
html unquoted attribute values and xml empty element closure.

Microsoft effectively killed xhtml by not recognising the mimetype in ie
until everyone else gave up trying. I don't see "(x)html5" resurrecting
it.

Um, the WWW would be a *much* smaller place then...

No, but at least every idiot out there that thinks he can code websites
would have to damn well get it right! After all, no-one would pay for the
development of web pages that that threw 600 errors, and even amateurs
would have to get their web sites right to display them.

I suspect geocities might never have existed too .... which might not
have been a bad thing.

 

[Tim Streater]

Agreed, but I'm still of the school that thinks browsers should throw a
"600 - wtf, I can't display this, it was coded by a moron" error for html
that doesn't match the doctype. Of course, this raises the question
"which doctype do I default to?" when none is supplied.

1) If xhtml element closures are detected, try xhtml 1.1, if that doesn't
work try xhtml 1.0(see 3), then throw wtf.

2) If no xhtml element closures are detected, work down from html 5 to
html 4.01(see 3) to html 3.2 to html 2.0 to html 1.0, then throw wtf.

3) For xhtml 1.0 and html 4.01, try strict, frameset, transitional in
that order.

If more browsers threw "600 - wtf, I can't display this, it was coded by
a moron" instead of trying to fix and display broken web pages, the world
would be a much better place.

And web users would stop using browsers that did that and their authors
would pretty soon get their arses kicked.

You should stop farting about with xhtml and understand that <!DOCTYPE
html> is all that's needed (and the only reason for that is to trigger
standards mode). What counts is what browsers implement. The ones that
win are the ones that ship. As some Yank general said in WW2, what
counts is getting there the fastest with the mostest.

I suggest you read this and note that error correction of broken html
is reasonably well understood:

<http://diveintohtml5.info/past.html>

 

[Tim Streater]

Microsoft effectively killed xhtml by not recognising the mimetype in ie
until everyone else gave up trying. I don't see "(x)html5" resurrecting
it.

No it was killed by those people insisting that either a page was
correct and the user saw the page, or it was errored and the user saw
nothing. A lunatic approach.

 

[Jukka K. Korpela]

No it was killed by those people insisting that either a page was
correct and the user saw the page, or it was errored and the user saw
nothing. A lunatic approach.

If it was lunatic, then the lunacy is in XML. Draconian error handling
is not something that you can decide on after selecting XML as the
basis; you select it when you select XML.

The main practical problem with XHTML5 (i.e., HTML5 in XML
linearization, aka. "XHTML linearization") is still lack of support in
old versions of IE.

Draconian error handling won't bite you if your document has no errors -
in this context, violations of generic XML syntax, aka "well-formedness
errors". There is nothing particularly difficult with achieving that.
Using XHTML5 as genuine XHTML (that is, served with an XML content type,
triggering XML processing, with Draconian error handling), you will
immediately see if your page has "well-formedness errors" when you view
it in a browser.

 

[Jukka K. Korpela]

I suggest you read this and note that error correction of broken html
is reasonably well understood:

<http://diveintohtml5.info/past.html>

It's a rather verbose description and not particularly focused on error
correction.

Error correction is defined in quite some detail in HTML5. There are
just two problems with it: it's very technical, and it does not say
which parts just describe what virtually all browsers do and which parts
are normative only, i.e. prescribe what browsers must or should do.

This will change when there will good manuals on HTML5 (HTML5 books
published so far don't try to be manuals, they just tell about ideas and
show examples).

And then we will effectively have two versions of the HTML language:
1) Real HTML, which is what browsers process and are required to
process, and 2) Valid HTML, which is a very restricted subset of real
HTML, the language that authors "are allowed" to use, by the spec. There
is no big difference in expressive power, though.

The point is that once you describe that some error be handled in a
specific way, and observe that implementations actually do so, you have
effectively added a feature to the language. You can say "invalid", "not
allowed", "must not", "entirely obsolete", "anathema", "cursed", and
"evil" as many times as you like, but people can just ignore those words.