Hacker News new | ask | show | jobs
by fastviper 5302 days ago
The context was XHTML. It was more correct but it was wrong (now dead) path. XHTML created only problems, but was "more correct"

To be precise, XHTML promised that pages render faster, which turned out to be browsers fault, not markup. PyPy solves "render fast" problem for python2. What problem Python3 does solve? Unicode? No...
2 comments
luriel 5302 days ago
> To be precise, XHTML promised that pages render faster, which turned out to be browsers fault, not markup.

I'm not sure XHTML ever promised faster rendering, I'm sure many people (including me) _assumed_ it would render faster. The truth is that XHTML rendered considerably more slowly! This days XML parsers have improved, but for a long time XHTML made partial rendering while loading and other things harder which meant loading an XHTML page took much longer than the plain-old HTML version.

I doubt rendering XHTML will ever be faster, at best it is/will-be not measurably slower than HTML.

link
ricardobeat 5302 days ago
XHTML was poised to offer much more than "correctedness". Reliable validation, custom DTDs, extensions, better interoperability. It just wasn't meant for the general web, where you have a massive number of non-technical authors. I don't think this comparison has any place in this discussion.
link
masklinn 5302 days ago
> XHTML was poised to offer

"supposed" would be a better fit than "poised".

> much more than "correctedness"

Not really

> Reliable validation, custom DTDs

correctness.

> extensions

Really debatable, xhtml only added "extensions" in the "XML dialects, RDF!!!" sense, in the effective sense HTML is extended all the time.

> better interoperability

At the cost of interop with the real world. And that better interop was restricted to markup (an issue being much better solved through HTML5 as browsers are moving towards spec-compliant HTML5 parsers), it left the "new" interop issues (CSS, JS, DOM, ...) in place.

And XHTML offered this better interop by... mandating source correctness...

> It just wasn't meant for the general web, where you have a massive number of non-technical authors.

Which, interestingly, is also an issue with Python: it's used a lot in scientific fields and as an extension language (though less so than it used to be), which I'd guess would qualify as "non-technical authors" as they're not computer technicians.

link
dextorious 5302 days ago
"""XHTML was poised to offer much more than "correctedness". Reliable validation, custom DTDs, extensions, better interoperability. It just wasn't meant for the general web, where you have a massive number of non-technical authors."""

You just retold the whole of his Python 3 argument in terms of XHTML. P3 was also poised to offer more than "correctedness", and also "wasn't meant for the general real world where you have a massive number of different systems".

"""I don't think this comparison has any place in this discussion."""

Actually it's the perfect analogy.

XHTML -> add correctness, some new features, idealistic, unsuitable for the real world, didn't catch on.

Python 3 -> add correctness, some new features, idealistic, unsuitable for the real world, didn't catch on.

link
perfunctory 5302 days ago
"I don't think this comparison has any place in this discussion"

I agree. Comparing markup languages to programming languages is even worse than comparing js to assembly. But since we are on the topic... I am not quite sure i undestand what " xhtml is unsuitable for the real world" means. Xhtml is a contract between a content author and a browser. Why do we call the browser's failure to implement the contract "unsuitable for the real world"?

link