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

  2. thedarkman

    thedarkman Guest

    I don't follow, but then I seldom do.
    thedarkman, Dec 2, 2013
    1. Advertisements

  3. 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, Dec 2, 2013
  4. 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"):

    (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 "/".
    Jukka K. Korpela, Dec 2, 2013
  5. 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.
    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, Dec 2, 2013
  6. Then you may prefer W3C recommendations.
    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.
    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.
    Why not start with XHTML5?
    Um, the WWW would be a *much* smaller place then...
    Christoph Michael Becker, Dec 3, 2013
  7. 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
    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, Dec 3, 2013
  8. thedarkman

    Tim Streater Guest

    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:

    Tim Streater, Dec 3, 2013
  9. thedarkman

    Tim Streater Guest

    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 Streater, Dec 3, 2013
  10. 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, Dec 3, 2013
  11. It's a rather verbose description and not particularly focused on error

    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.
    Jukka K. Korpela, Dec 3, 2013
    1. Advertisements

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 (here). After that, you can post your question and our members will help you out.