3 ms·

That wasn't serious enough. Did any browser ever reject a Web page just because it wasn't well-formed XHTML? Basically, give people a hand, and they'll grab yo

That wasn't serious enough. Did any browser ever reject a Web page just because it wasn't well-formed XHTML? Basically, give people a hand, and they'll grab your whole arm. It's human nature, and Web developers aren't above it.

unlinker 11y ago
That would be madness. Imagine a browser that did that, or that crashed the tab in case of a JS error. There would be no pages left :P
- catnaroek 11y ago
  It would be a lot more sensible than you think. When I get a compilation error, what I do is take a breath, think about the meaning of my code, correct any logical mistakes I can find, and try to compile again. Why couldn't Web developers do the same? Also, there's no need to crash the tab. The browser could simply stop running any JavaScript, and leave the user with a static page.
  - Klathmon 11y ago
    IIRC some of the older versions of internet explorer did something like that, showing the user a popup if an error happened and asked them if they wanted to keep going.
    - catnaroek 11y ago
      Next, browsers will show users a popup asking if they want to jump off a cliff.
- regularfry 11y ago
  And this is precisely the point. If the very earliest browsers had insisted on correctness rather than permissively accepting broken HTML (and JS - see semicolon insertion), we would not now have a situation where browsers need to do a ton of work to allow graceful degradation in the face of awful markup, simply because the tooling would have evolved in the other direction. Postel's Law gains a little temporary sender convenience in exchange for a nasty mess of permanent receiver headaches.
  - DanBC 11y ago
    Postel's law has two parts. Be gracious in what you receive is what most people are talking about, but be cautious in what you send is just as important. If people are using broken markup that's the problem that needs fixing. How many web devs bother with validation anymore? (And not for app like functionality, but for what should be simple text and images with a few menus - why are so many newspaper websites so awful?) https://tools.ietf.org/html/rfc793 https://tools.ietf.org/html/rfc793 2.10. Robustness Principle TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.
    - catnaroek 11y ago
      > but be cautious in what you send is just as important. How are you going to enforce this for everyone? > TCP implementations will follow a general principle of robustness (...) This rule has worked well for TCP implementors in large part because of their circumstances, which are very different from those of browser implementors and Web developers: (0) Priorities: How much do the following desiderata matter to each group: reliability, performance, new features? (1) Skill: What skills does a representative programmer from each group have? (2) Risk profile: How does each group cope with the possibility of design and implementation errors? How much technical debt are they willing to take? I'd contend that Postel's law doesn't scale beyond relatively small groups of highly skilled programmers, for whom reliability is paramount and trumps all other considerations.
    - regularfry 11y ago
      The problem is that being conservative and precise isn't enough. You and I can both be conservative, but disagree on the specifics (given an ambiguous spec, for instance). A permissive receiver of both our data now has to support both sides of our disagreement forever.
      - DanBC 11y ago
        No they don't. They just have to not explode.
seba_dos1 11y ago
>Did any browser ever reject a Web page just because it wasn't well-formed XHTML? Of course. If you served XHTML properly (by setting "application/xhtml+xml" MIME type), ill-formed XHTML would just show you a big syntax error instead of the page. Try it, that's still the case. Even when being well-formed, lots of sites still used "text/html" type to trigger HTML (SGML) parser instead of XML one, as any 3rd party code embedded into the website would of course crash the page as well. That was one of the reasons why XHTML never got popular and eventually has been abandoned.
- catnaroek 11y ago
  That still wasn't serious enough. All it took to get browsers to accept non-XHTML pages was to change the MIME type. What I'm talking about is simply not displaying ill-formed pages at all, under any circumstances.
  - seba_dos1 11y ago
    But with that MIME type it wasn't XHTML at all. It was being parsed as HTML which was possible only because of big similarity between those two formats. All you need to ensure the behavior you want is to disable HTML parsing (which is pretty much ensures being liberal in what the parser accepts already in its specification).

unlinker 11y ago

That would be madness. Imagine a browser that did that, or that crashed the tab in case of a JS error. There would be no pages left :P

catnaroek 11y ago
It would be a lot more sensible than you think. When I get a compilation error, what I do is take a breath, think about the meaning of my code, correct any logical mistakes I can find, and try to compile again. Why couldn't Web developers do the same? Also, there's no need to crash the tab. The browser could simply stop running any JavaScript, and leave the user with a static page.
- Klathmon 11y ago
  IIRC some of the older versions of internet explorer did something like that, showing the user a popup if an error happened and asked them if they wanted to keep going.
  - catnaroek 11y ago
    Next, browsers will show users a popup asking if they want to jump off a cliff.
regularfry 11y ago
And this is precisely the point. If the very earliest browsers had insisted on correctness rather than permissively accepting broken HTML (and JS - see semicolon insertion), we would not now have a situation where browsers need to do a ton of work to allow graceful degradation in the face of awful markup, simply because the tooling would have evolved in the other direction. Postel's Law gains a little temporary sender convenience in exchange for a nasty mess of permanent receiver headaches.
- DanBC 11y ago
  Postel's law has two parts. Be gracious in what you receive is what most people are talking about, but be cautious in what you send is just as important. If people are using broken markup that's the problem that needs fixing. How many web devs bother with validation anymore? (And not for app like functionality, but for what should be simple text and images with a few menus - why are so many newspaper websites so awful?) https://tools.ietf.org/html/rfc793 https://tools.ietf.org/html/rfc793 2.10. Robustness Principle TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.
  - catnaroek 11y ago
    > but be cautious in what you send is just as important. How are you going to enforce this for everyone? > TCP implementations will follow a general principle of robustness (...) This rule has worked well for TCP implementors in large part because of their circumstances, which are very different from those of browser implementors and Web developers: (0) Priorities: How much do the following desiderata matter to each group: reliability, performance, new features? (1) Skill: What skills does a representative programmer from each group have? (2) Risk profile: How does each group cope with the possibility of design and implementation errors? How much technical debt are they willing to take? I'd contend that Postel's law doesn't scale beyond relatively small groups of highly skilled programmers, for whom reliability is paramount and trumps all other considerations.
  - regularfry 11y ago
    The problem is that being conservative and precise isn't enough. You and I can both be conservative, but disagree on the specifics (given an ambiguous spec, for instance). A permissive receiver of both our data now has to support both sides of our disagreement forever.
    - DanBC 11y ago
      No they don't. They just have to not explode.

seba_dos1 11y ago

>Did any browser ever reject a Web page just because it wasn't well-formed XHTML? Of course. If you served XHTML properly (by setting "application/xhtml+xml" MIME type), ill-formed XHTML would just show you a big syntax error instead of the page. Try it, that's still the case. Even when being well-formed, lots of sites still used "text/html" type to trigger HTML (SGML) parser instead of XML one, as any 3rd party code embedded into the website would of course crash the page as well. That was one of the reasons why XHTML never got popular and eventually has been abandoned.

catnaroek 11y ago
That still wasn't serious enough. All it took to get browsers to accept non-XHTML pages was to change the MIME type. What I'm talking about is simply not displaying ill-formed pages at all, under any circumstances.
- seba_dos1 11y ago
  But with that MIME type it wasn't XHTML at all. It was being parsed as HTML which was possible only because of big similarity between those two formats. All you need to ensure the behavior you want is to disable HTML parsing (which is pretty much ensures being liberal in what the parser accepts already in its specification).