4 ms·

Didnt XHTML stand for eXtensible HTML ? maybe XHTML was the right way at first place , just saying.

by camus2 13y ago

gizmogwai 13y ago
XHTML _was_ right. People were just too lazy to close there tags and did not really understood what would the consequences of not having a robust and formal way to extend the language. HTML went the same way other popular languages (e.g.: VB, PHP, Perl), they got broad adoption because the compiler/interpreter/renderer would be too kind in working hard to fix user mistake instead of reporting them. And then, when they tried to fix it, the same user base complain (despite being bitten many times by the language) that it should stay like it is, because it has always been like that. When bad habits became traditions, you are really in a bad position.
- haberman 13y ago
  No: http://web.archive.org/web/20081211052740/http://diveintomark.org/archives/2004/01/14/thought_experiment http://web.archive.org/web/20081211052740/http://diveintomar... "The client is the wrong place to enforce data integrity. It’s just the wrong place. I hear otherwise intelligent people claim that if everyone did it, it would be okay. No, if everyone did it, it would be even worse. If you want to do it, of course I can’t stop you. But think about who it will hurt."
  - sixbrx 13y ago
    Hard to see how it would have been worse if all browsers had implemented stop-on-error, because then the developer/tester's browser would not have rendered the erronous page. That would mean that the developer/tester would have had to not try the page even once before shipping, if a bad page were to make it to production.
    - haberman 13y ago
      The page only became bad when the blog received a trackback from a different blog with a different character set. At that point the blog software erroneously changed the page's content and made it invalid. It was a software bug, plain and simple. The page was fully valid when the blog author published it. For the developer/tester of Typepad (the blog software) to catch the bug, they would have had to trigger this bug in development/testing before it made it into the wild. While we always hope developers will catch as many bugs as possible, some will always slip through. Strict validation on the client means that even the slightest bug can make the website 100% down/unavailable, even though the browser would be perfectly capable of displaying something that 99% works. Modern web sites are huge amalgamations of dynamically-generated content using umpteen templating technologies and aggregations of data that come from sources that the page's authors do not necessarily control. Guaranteeing that their output will always be valid XHTML is not trivial.
      - gizmogwai 13y ago
        I disagree. The issue described is an input sanitisation issue. The same thing would have happen to a SQL query and everyone would have put shame on you. It IS a bug that the blog engine developers should have catch, in the same way they should have protect the trackback from XSS injection. Guaranteeing your output will always be valid might not be trivial, but it is way less harder that some people pretend it to be.
        haberman 13y ago
        Bugs will slip through. They just will, it's a fact of life. The question is, when they do, will you let the browser gracefully recover, or will you demand that the browser show an error page, even though it could do something reasonable? The security analogy would be to let all your code run as root, because the main security mechanisms should prevent users from executing arbitrary code. But this is fragile, because any security bug would compromise the security of the system completely. What we do instead is have defense in depth: even if the first layer of security is compromised, there are other layers of security that can (hopefully) contain the damage. Permissive client rendering likewise limits the damage that one bug can do.
mindcrime 13y ago
maybe XHTML was the right way at first place , just saying. It very probably was. The path we're going down with HTML5 and "modern" browser technologies is taking a muddled clusterfuck of a mess, and making it even more muddled and even more of a clusterfuck. It'll work, but only through heroic effort and sacrifice. I feel like we're painting ourselves into a corner with the web these days, and actually reducing choice and flexibility on the web. One thing that is clear, is that we've lost sight of the distinction between a document and an application, and have managed to turn a pretty good hypertext platform into a Dr. Frankentein's Monster that combines hypertext browsing and a poor man's X-server in eldritch and grotesque ways.

Didnt XHTML stand for eXtensible HTML ? maybe XHTML was the right way at first place , just saying.

by camus2 13y ago

Didnt XHTML stand for eXtensible HTML ? maybe XHTML was the right way at first place , just saying.

XHTML _was_ right. People were just too lazy to close there tags and did not really understood what would the consequences of not having a robust and formal way to extend the language. HTML went the same way other popular languages (e.g.: VB, PHP, Perl), they got broad adoption because the compiler/interpreter/renderer would be too kind in working hard to fix user mistake instead of reporting them. And then, when they tried to fix it, the same user base complain (despite being bitten many times by the language) that it should stay like it is, because it has always been like that. When bad habits became traditions, you are really in a bad position.

haberman 13y ago
No: http://web.archive.org/web/20081211052740/http://diveintomark.org/archives/2004/01/14/thought_experiment http://web.archive.org/web/20081211052740/http://diveintomar... "The client is the wrong place to enforce data integrity. It’s just the wrong place. I hear otherwise intelligent people claim that if everyone did it, it would be okay. No, if everyone did it, it would be even worse. If you want to do it, of course I can’t stop you. But think about who it will hurt."
- sixbrx 13y ago
  Hard to see how it would have been worse if all browsers had implemented stop-on-error, because then the developer/tester's browser would not have rendered the erronous page. That would mean that the developer/tester would have had to not try the page even once before shipping, if a bad page were to make it to production.
  - haberman 13y ago
    The page only became bad when the blog received a trackback from a different blog with a different character set. At that point the blog software erroneously changed the page's content and made it invalid. It was a software bug, plain and simple. The page was fully valid when the blog author published it. For the developer/tester of Typepad (the blog software) to catch the bug, they would have had to trigger this bug in development/testing before it made it into the wild. While we always hope developers will catch as many bugs as possible, some will always slip through. Strict validation on the client means that even the slightest bug can make the website 100% down/unavailable, even though the browser would be perfectly capable of displaying something that 99% works. Modern web sites are huge amalgamations of dynamically-generated content using umpteen templating technologies and aggregations of data that come from sources that the page's authors do not necessarily control. Guaranteeing that their output will always be valid XHTML is not trivial.
    - gizmogwai 13y ago
      I disagree. The issue described is an input sanitisation issue. The same thing would have happen to a SQL query and everyone would have put shame on you. It IS a bug that the blog engine developers should have catch, in the same way they should have protect the trackback from XSS injection. Guaranteeing your output will always be valid might not be trivial, but it is way less harder that some people pretend it to be.
      - haberman 13y ago
        Bugs will slip through. They just will, it's a fact of life. The question is, when they do, will you let the browser gracefully recover, or will you demand that the browser show an error page, even though it could do something reasonable? The security analogy would be to let all your code run as root, because the main security mechanisms should prevent users from executing arbitrary code. But this is fragile, because any security bug would compromise the security of the system completely. What we do instead is have defense in depth: even if the first layer of security is compromised, there are other layers of security that can (hopefully) contain the damage. Permissive client rendering likewise limits the damage that one bug can do.

mindcrime 13y ago

maybe XHTML was the right way at first place , just saying. It very probably was. The path we're going down with HTML5 and "modern" browser technologies is taking a muddled clusterfuck of a mess, and making it even more muddled and even more of a clusterfuck. It'll work, but only through heroic effort and sacrifice. I feel like we're painting ourselves into a corner with the web these days, and actually reducing choice and flexibility on the web. One thing that is clear, is that we've lost sight of the distinction between a document and an application, and have managed to turn a pretty good hypertext platform into a Dr. Frankentein's Monster that combines hypertext browsing and a poor man's X-server in eldritch and grotesque ways.