weird but it works

Discussion in 'HTML' started by thedarkman, Dec 1, 2013.

  1. thedarkman

    thedarkman Guest

    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, Dec 1, 2013
    #1
    1. Advertising

  2. thedarkman

    thedarkman Guest

    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 ./../../.*.
    >
    >
    >
    > >

    >
    > > <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, Dec 2, 2013
    #2
    1. Advertising

  3. On Sun, 01 Dec 2013 11:08:59 -0800, thedarkman wrote:

    > [/ 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.

    --
    Denis McMahon,
     
    Denis McMahon, Dec 2, 2013
    #3
  4. 2013-12-02 21:50, Denis McMahon wrote:

    > 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 "/".

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
     
    Jukka K. Korpela, Dec 2, 2013
    #4
  5. On Mon, 02 Dec 2013 22:32:15 +0200, Jukka K. Korpela wrote:

    > 2013-12-02 21:50, Denis McMahon wrote:
    >
    >> 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.


    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.

    --
    Denis McMahon,
     
    Denis McMahon, Dec 2, 2013
    #5
  6. Denis McMahon wrote:

    > On Mon, 02 Dec 2013 22:32:15 +0200, Jukka K. Korpela wrote:
    >
    >> 2013-12-02 21:50, Denis McMahon wrote:
    >>
    >> 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.


    Then you may prefer W3C recommendations.

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


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

    --
    Christoph M. Becker
     
    Christoph Michael Becker, Dec 3, 2013
    #6
  7. On Tue, 03 Dec 2013 01:16:54 +0100, Christoph Michael Becker wrote:

    >> 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?


    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.

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


    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.

    --
    Denis McMahon,
     
    Denis McMahon, Dec 3, 2013
    #7
  8. thedarkman

    Tim Streater Guest

    In article <l7j6f4$i3g$>, Denis McMahon
    <> wrote:

    > 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

    "That excessive bail ought not to be required, nor excessive fines imposed,
    nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
     
    Tim Streater, Dec 3, 2013
    #8
  9. thedarkman

    Tim Streater Guest

    In article <l7jk8d$i3g$>, Denis McMahon
    <> wrote:

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

    --
    Tim

    "That excessive bail ought not to be required, nor excessive fines imposed,
    nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
     
    Tim Streater, Dec 3, 2013
    #9
  10. 2013-12-03 11:39, Tim Streater wrote:

    > In article <l7jk8d$i3g$>, Denis McMahon
    > <> wrote:
    >
    >> 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.


    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.

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
     
    Jukka K. Korpela, Dec 3, 2013
    #10
  11. 2013-12-03 11:36, Tim Streater wrote:

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

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
     
    Jukka K. Korpela, Dec 3, 2013
    #11
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. F. GEIGER
    Replies:
    3
    Views:
    782
    F. GEIGER
    Aug 6, 2004
  2. David Wang
    Replies:
    0
    Views:
    737
    David Wang
    Dec 1, 2006
  3. dorayme
    Replies:
    1
    Views:
    625
    richard
    Jan 21, 2011
  4. richard
    Replies:
    0
    Views:
    587
    richard
    Jan 21, 2011
  5. richard
    Replies:
    0
    Views:
    618
    richard
    Jan 21, 2011
Loading...

Share This Page