7 ms·

I think you're downplaying the shit show that was XHTML. It was the epitome of standards people chasing the ideal of a perfect platonic ideal of a standard at

by cwmma 9y ago

I think you're downplaying the shit show that was XHTML. It was the epitome of standards people chasing the ideal of a perfect platonic ideal of a standard at the cost of actual usability. E.G. a single parse error in an XHTML document and it doesn't render at all. That all by itself was a deal breaker for many people.

kuschku 9y ago
That’s great if you’re either an existing browser vendor, using a browser, or developing a broken website. But if you actually try to write a new browser from scratch, or a tool to scrape websites, you’ll learn to love XHTML, and hate HTML5. The same that applies with human languages applies here as well. Writing a vocaloid for japanese is a high school programming class project. Writing a TTS for english takes thousands of Google developers years. Writing an XHTML1.1 parser and renderer takes a month. Writing an HTML5 browser takes thousands of developers years. The WHATWG specs prevent the web from ever evolving further – we’re stuck with opaque websites and no way to build new technology on top of it. Building a crawler is a task of years, and semantic data tags are impossible to parse, because no one uses them right. The only reason we can automate any parsing of websites is because either browser vendors spent billions on crawlers for their search engines, or if we run a full browser, or if we use the opengraph tags that Facebook forced on websites. With XHTML1.1, Chrome and Firefox headless would never have been necessary. Imagine how much time and computational cost you could save.
- maxerickson 9y ago
  I'm pretty sure javascript heavy pages would exist even in a strict parsing world.
- olavk 9y ago
  But the web already contains billions of pages which do not conform to XHTML. Any browser or scraper would still have to able to parse those to be of any use. Adding XHTML would just be an additional parser frontend, it would not simplify anything.
  - kuschku 9y ago
    That’s not true – the WHATWG has already deprecated some HTML specs, and older HTML pages already break today. XHTML would have worked the same way – after a few years, you can deprecate the old parsers.
    - olavk 9y ago
      As far as I know, WHATWG have deprecated some elements not widely used (like "isindex", "font"), but the documents using these elements will still be readable even if not exactly as the author intended. Moving to XHTML, on the other hand, would make billions of pages totally inaccessible. There are people who are now dead who have pages on the internet. These pages will never be updated.
      - hsivonen 9y ago
        font still works. isindex does not. It's extremely rare for a cross-browser HTML element to get removed but isindex is one of those.
        kuschku 9y ago
        blink also doesn’t work anymore, and neither does marquee. Several of the frame attributes are broken as well. noscript doesn’t always work reliably depending on browser.
        hsivonen 9y ago
        Marquee works for me in Gecko and Blink. Didn't test the other two engines.
- ChrisSD 9y ago
  XHTML lost in the marketplace. This was due in part to lack of developer adoption and the fact Internet Explorer ignored it. You could argue that the web community should have forced this through but that simply wasn't working at the time.
- Analemma_ 9y ago
  You keep repeating over and over that the big advantage to XHTML is "not having to run headless browsers", which I don't understand. I use Selenium all the time for my job, it's not great but it's... not horrible? It's fine, it's not some massive inconvenience, and it's definitely not worth getting rid of HTML5 to abandon it, when, as others have pointed out and you keep ignoring, the practical effect would be that the web would be useless for actual humans without plug-ins. I guess I don't get your huge bone to pick with Selenium.
  - kuschku 9y ago
    > I use Selenium all the time for my job, it's not great but it's... not horrible? It's fine, it's not some massive inconvenience, Try running hundreds of tests at the same time, to actually get fast results when running a full test suite. Right now running a small testsuite takes here over 2 hours, 99% of the time is spent in the browser processes. And that’s not nearly close to 100% test coverage. > not worth getting rid of HTML5 to abandon it You don’t have to – XHTML isn’t the only strict spec out there, AMP is another, React also enforces strict syntax in JSX templates. AMP fails to render anything if there’s even a single mistake, React fails at build time.
- PeterisP 9y ago
  "That’s great if you’re either an existing browser vendor, using a browser, or developing a broken website." - and that's the whole point, in the marketplace the convenience of these people matters much, much, much more than the convenience of those people who want to "try to write a new browser from scratch, or a tool to scrape websites." If you want to scrape websites or show them in a browser, then you have to follow the needs of makers of these sites, because you need them and they don't need you. If you want to go to the right and they want to go to the left, you either follow them or go alone and become unable to scrape or browse their content. If there's a feature that they want to use that makes your parsing more complicated, tough luck, that feature is going in as long as somebody (e.g. major browser vendors) will agree to make it work.
- freeone3000 9y ago
  The huge underlying assumption here is that people would use XHTML as a standard instead of using HTML4.01 with browser-specific extensions, which is what actually happened. XHTML didn't add any value to page authors. It added hugely indirect value to readers. The only people XHTML helped were tooling authors and browser vendors. It's very hard to market that as a value-add.
- hsivonen 9y ago
  Parsing isn't the difficult part and above the parser both XHTML and HTML involve the same complexity. You can get an HTML parser off the shelf. A browser vendor (Mozilla) even funded one for non-browser purposes before adopting it for Firefox.
- deleted 9y ago
  [deleted]
- comex 9y ago
  > Writing a vocaloid for japanese is a high school programming class project. Writing a TTS for english takes thousands of Google developers years. It didn't take "thousands of Google developers years" to teach a computer English spelling rules. Indeed, even a programming class assignment could do that: you can cover most cases by just looking the pronunciations up in a dictionary. (The number of quirks and inconsistencies makes English spelling quite hard for humans to memorize, but computers are rather good at lookup tables.) Even if you consider the actual Vocaloid software, which was developed by a team at a large corporation, there are two factors differentiating it from English TTS that make the latter much harder: 1. Japanese has much simpler phonetics than English, with a smaller set of phonemes and (somewhat oversimplifying) only using open syllables. So it's easier to consume and produce, for both computers and humans, but at the cost of being a less efficient encoding: Japanese tends to require a lot more syllables than English to express the same concept, and there are a lot of homophones. 2. Vocaloid sounds robotic. It's gotten a bit less so over time, but it still doesn't come close to passing as human. If you're okay with robotic, English TTS software has existed for a long time, starting many decades before Google was founded. The hard part, the part that requires neural networks and massive computational power and Google and still has yet to be perfected, is making it sound human. By the way, although vocaloid software would be given phonetic input, normal Japanese writing uses kanji (i.e. Chinese characters), most of which have multiple unrelated possible pronunciations. Determining which pronunciation applies to each character in a given piece of text is nontrivial, and sometimes even depends on context or meaning.
smaddox 9y ago
That seems reasonable to me. Would you want your programming language to compile code that has a syntax error?
- deleted 9y ago
  [deleted]
- pvg 9y ago
  Would you want any and all systems to have identical failure modes?
- haberman 9y ago
  Yes, it seems reasonable, and the analogy with programming languages seems to make sense. But there's a big difference. With programming languages, you write a program, and when it's correct, you check it in and it's immutable until you check in a new version. Web pages are composited on-the-fly by programs that combine static files, database content, content from third parties, etc. The only way you guarantee a valid output document is if your compositor is bug free and defensively validates any third-party content you might be pulling in. Any bug in the compositor and your website is totally unavailable for users that hit the bug. This is a great illustration of the concept: https://web.archive.org/web/20060613193727/http://diveintomark.org/archives/2004/01/14/thought_experiment https://web.archive.org/web/20060613193727/http://diveintoma...
  - smaddox 9y ago
    Thanks for the link. I can certainly see how making the transition now is pretty much untenable, but I'm not 100% sold that it wouldn't be a good idea if everyone had adopted the policy from the start. I can certainly see how it would still be important for browsers to have a mode where they do their best to render the page, but it's less clear that it should be the default. Even if it was the default, then I would expect variations in different browsers ability to recover from errors would lead developers to being much more careful about allowing errors to creep in.
    - 9y ago

by cwmma 9y ago

kuschku 9y ago

That’s great if you’re either an existing browser vendor, using a browser, or developing a broken website. But if you actually try to write a new browser from scratch, or a tool to scrape websites, you’ll learn to love XHTML, and hate HTML5. The same that applies with human languages applies here as well. Writing a vocaloid for japanese is a high school programming class project. Writing a TTS for english takes thousands of Google developers years. Writing an XHTML1.1 parser and renderer takes a month. Writing an HTML5 browser takes thousands of developers years. The WHATWG specs prevent the web from ever evolving further – we’re stuck with opaque websites and no way to build new technology on top of it. Building a crawler is a task of years, and semantic data tags are impossible to parse, because no one uses them right. The only reason we can automate any parsing of websites is because either browser vendors spent billions on crawlers for their search engines, or if we run a full browser, or if we use the opengraph tags that Facebook forced on websites. With XHTML1.1, Chrome and Firefox headless would never have been necessary. Imagine how much time and computational cost you could save.

maxerickson 9y ago
I'm pretty sure javascript heavy pages would exist even in a strict parsing world.
olavk 9y ago
But the web already contains billions of pages which do not conform to XHTML. Any browser or scraper would still have to able to parse those to be of any use. Adding XHTML would just be an additional parser frontend, it would not simplify anything.
- kuschku 9y ago
  That’s not true – the WHATWG has already deprecated some HTML specs, and older HTML pages already break today. XHTML would have worked the same way – after a few years, you can deprecate the old parsers.
  - olavk 9y ago
    As far as I know, WHATWG have deprecated some elements not widely used (like "isindex", "font"), but the documents using these elements will still be readable even if not exactly as the author intended. Moving to XHTML, on the other hand, would make billions of pages totally inaccessible. There are people who are now dead who have pages on the internet. These pages will never be updated.
    - hsivonen 9y ago
      font still works. isindex does not. It's extremely rare for a cross-browser HTML element to get removed but isindex is one of those.
      - kuschku 9y ago
        blink also doesn’t work anymore, and neither does marquee. Several of the frame attributes are broken as well. noscript doesn’t always work reliably depending on browser.
        hsivonen 9y ago
        Marquee works for me in Gecko and Blink. Didn't test the other two engines.
ChrisSD 9y ago
XHTML lost in the marketplace. This was due in part to lack of developer adoption and the fact Internet Explorer ignored it. You could argue that the web community should have forced this through but that simply wasn't working at the time.
Analemma_ 9y ago
You keep repeating over and over that the big advantage to XHTML is "not having to run headless browsers", which I don't understand. I use Selenium all the time for my job, it's not great but it's... not horrible? It's fine, it's not some massive inconvenience, and it's definitely not worth getting rid of HTML5 to abandon it, when, as others have pointed out and you keep ignoring, the practical effect would be that the web would be useless for actual humans without plug-ins. I guess I don't get your huge bone to pick with Selenium.
- kuschku 9y ago
  > I use Selenium all the time for my job, it's not great but it's... not horrible? It's fine, it's not some massive inconvenience, Try running hundreds of tests at the same time, to actually get fast results when running a full test suite. Right now running a small testsuite takes here over 2 hours, 99% of the time is spent in the browser processes. And that’s not nearly close to 100% test coverage. > not worth getting rid of HTML5 to abandon it You don’t have to – XHTML isn’t the only strict spec out there, AMP is another, React also enforces strict syntax in JSX templates. AMP fails to render anything if there’s even a single mistake, React fails at build time.
PeterisP 9y ago
"That’s great if you’re either an existing browser vendor, using a browser, or developing a broken website." - and that's the whole point, in the marketplace the convenience of these people matters much, much, much more than the convenience of those people who want to "try to write a new browser from scratch, or a tool to scrape websites." If you want to scrape websites or show them in a browser, then you have to follow the needs of makers of these sites, because you need them and they don't need you. If you want to go to the right and they want to go to the left, you either follow them or go alone and become unable to scrape or browse their content. If there's a feature that they want to use that makes your parsing more complicated, tough luck, that feature is going in as long as somebody (e.g. major browser vendors) will agree to make it work.
freeone3000 9y ago
The huge underlying assumption here is that people would use XHTML as a standard instead of using HTML4.01 with browser-specific extensions, which is what actually happened. XHTML didn't add any value to page authors. It added hugely indirect value to readers. The only people XHTML helped were tooling authors and browser vendors. It's very hard to market that as a value-add.
hsivonen 9y ago
Parsing isn't the difficult part and above the parser both XHTML and HTML involve the same complexity. You can get an HTML parser off the shelf. A browser vendor (Mozilla) even funded one for non-browser purposes before adopting it for Firefox.
deleted 9y ago
[deleted]
comex 9y ago
> Writing a vocaloid for japanese is a high school programming class project. Writing a TTS for english takes thousands of Google developers years. It didn't take "thousands of Google developers years" to teach a computer English spelling rules. Indeed, even a programming class assignment could do that: you can cover most cases by just looking the pronunciations up in a dictionary. (The number of quirks and inconsistencies makes English spelling quite hard for humans to memorize, but computers are rather good at lookup tables.) Even if you consider the actual Vocaloid software, which was developed by a team at a large corporation, there are two factors differentiating it from English TTS that make the latter much harder: 1. Japanese has much simpler phonetics than English, with a smaller set of phonemes and (somewhat oversimplifying) only using open syllables. So it's easier to consume and produce, for both computers and humans, but at the cost of being a less efficient encoding: Japanese tends to require a lot more syllables than English to express the same concept, and there are a lot of homophones. 2. Vocaloid sounds robotic. It's gotten a bit less so over time, but it still doesn't come close to passing as human. If you're okay with robotic, English TTS software has existed for a long time, starting many decades before Google was founded. The hard part, the part that requires neural networks and massive computational power and Google and still has yet to be perfected, is making it sound human. By the way, although vocaloid software would be given phonetic input, normal Japanese writing uses kanji (i.e. Chinese characters), most of which have multiple unrelated possible pronunciations. Determining which pronunciation applies to each character in a given piece of text is nontrivial, and sometimes even depends on context or meaning.

smaddox 9y ago

That seems reasonable to me. Would you want your programming language to compile code that has a syntax error?

deleted 9y ago
[deleted]
pvg 9y ago
Would you want any and all systems to have identical failure modes?
haberman 9y ago
Yes, it seems reasonable, and the analogy with programming languages seems to make sense. But there's a big difference. With programming languages, you write a program, and when it's correct, you check it in and it's immutable until you check in a new version. Web pages are composited on-the-fly by programs that combine static files, database content, content from third parties, etc. The only way you guarantee a valid output document is if your compositor is bug free and defensively validates any third-party content you might be pulling in. Any bug in the compositor and your website is totally unavailable for users that hit the bug. This is a great illustration of the concept: https://web.archive.org/web/20060613193727/http://diveintomark.org/archives/2004/01/14/thought_experiment https://web.archive.org/web/20060613193727/http://diveintoma...
- smaddox 9y ago
  Thanks for the link. I can certainly see how making the transition now is pretty much untenable, but I'm not 100% sold that it wouldn't be a good idea if everyone had adopted the policy from the start. I can certainly see how it would still be important for browsers to have a mode where they do their best to render the page, but it's less clear that it should be the default. Even if it was the default, then I would expect variations in different browsers ability to recover from errors would lead developers to being much more careful about allowing errors to creep in.
  - 9y ago