Can you point to an actual active Gecko or Firefox developer (not a fanboy, not someone who last worked on the project many years ago) saying there are no leaks?
Or are you just making up or blindy repeating the "developers told us there aren't any" thing?
That's true as long as Google is not creating its own walled gardens. Which it's hard at work doing, unfortunately. Not quite as bad as Facebook yet, thankfully.
Well, sure. Grandparent was talking about restoring those in lieu of the agriculture we do now, as far as I can tell. Which would be a pretty hard sell, but my point was that even that wouldn't be enough to replace current US beef production with grass-fed free-range beef.
So if we're willing to reduce the beef production by a factor of 3 from where we are now, we can probably avoid human management. Otherwise, chances are human management is needed.
That said, we certainly have enough beef for just the US here; the problems, if any, start when beef exports start competing on price with domestic purchases.
TFA, which you may have read, talks about working from home.
If you work from home, that often means moving large amounts of work data back and forth. It's common for me to want to grab a 40MB chunk of data on short notice and be blocked on work until it comes down. At that point, 25Mb (13 seconds) is way better than 5Mb (65 seconds, you're likely to go read webcomics and so forth). 300Mb would be 1s, which is _really_ good because it doesn't interrupt your workflow at all.
Not in my experience... I think you underestimate the extent to which XHTML was cargo-culted. I think I've literally run across only 2 or 3 non-example XHTML pages that were actually well-formed over the last 10 years or so.
> Many, many businesses across the globe don't > even hand craft XHTML, it's built automatically > using tools like XSLT
Sure. Though note that it's possible to produce non-well-formed XML even using XSLT (disable-output-escaping, which people use a fair bit). But there are also lots of non-XSLT toolchains that claim to produce XHTML... and just don't.
> A spec isn't really meant to work with real world > content.
That, right there, is definitely a philosophical disagreement. There are lots of specs out there in which backwards compatibility was a hard requirement during spec development. Especially in the non-web world (gigabit ethernet, USB3, dual-channel DVI, and so on, and so forth). W3C specs were actually really _weird_ in their willingness to throw away backwards compat.
> and that's different to WHATWG how?
It's not that different in theory. In practice the set of participants is somewhat different at the moment, as you noted. So there are, for example, few people who are working in the WHATWG to shape HTML around their specific non-web use case.
Not that the development process for the WHATWG is a picnic, and God knows I've had my share of disagreements with the WHATWG spec, some of them still outstanding. Coordinating thousands of people with differing opinions is really hard. WHATWG is doing ok, but not necessarily great, in my opinion. I understand that you think they're not even doing ok.
But my personal experience, which reflects the interactions _I_ have had with WHATWG and W3C, is that WHATWG is more willing to at least listen to feedback and respond (if not necessarily take it into account) than some W3C working groups were back when WHATWG was founded. For those working groups, there was _real_ work behind closed doors going on: closed meetings that you couldn't attend unless you paid up, closed mailing lists you couldn't read or post to unless you paid up, closed decision process. Oh, and they were completely ignoring the W3C process requirements to address feedback on the drafts that they were in the end required to publish. _That_ sort of thing has largely gone away in the last 5 years, thankfully, due to WHATWG existing, but back when WHATWG started it was a very real part of trying to deal with the W3C.
See, the thing is that there is no such thing as a "version of a namespace" in XML. Just no such concept. There is just a namespace. What's supposed to happen when you have incompatible versions is a new namespace. But that didn't happen.
> it doesn't seem much of a big deal.
It's a huge deal. The corresponding bustage in IE6 where nodes from XHR couldn't be moved into normal documents was a huge pain point for developers until it was fixed.
> t's certainly far better than the current status quo
That's debatable, honestly.
> but people were moving their markup to XML > syntax
No, they were moving it to XML cargo-culting. 99% of the stuff pretending to be "XML syntax" was not well-formed XML.
> I suspect the core problem here is a clash of > ideologies
To some extent, yes. There _was_ a clash between "write specs that won't work with real-world content" and "write browsers that work with real-world content"...
But the authoring of self-contradictory specs has nothing to do with desire for stability and everything to do with the fact that the "W3C" is a bunch of independent working groups, composed of independent members, each with their own political, technological, and business ends. Sometimes the whole thing produces standards. Sometimes they're even good. Sometimes, it instead produces a self-contradictory ball of string that can't be implemented, and the you just have to excise enough of the bits to get something sane and only implement that. Which is what happened with XHTML2...
The basic "insoluble" problem is that XHTML1 and XHTML2 share a namespace. XML and the DOM specs define that the behavior and semantics of nodes depend only on their local name and namespace. But XHTML2 reuses some local names from XHTML1 but assigns different semantics to them.
Tracking origin information in memory _could_ be done, but it would result in bizarre behavior where you recreate a node in a way that XML and the DOM say should give you the same thing as you already have... and it doesn't.
Now obviously changes could have been made to the XML and DOM specs to allow this all to work somehow, unintuitive as it would be, but the W3C wasn't willing to do that, unfortunately.
I never claimed to be "neutral", but you're trying to focus the discussion on claims that I personally am incompetent instead of the actual issues.
> other applications, such as Word, do exactly this.
No, they do not. They expose foreign objects through abstraction layers of their choosing, while web browsers have to expose everything through the DOM, which exposes all sorts of implementation details.
> so there's no issue.
Sure there is. Once nodes can be moved via script, your DOM may no longer match your DTD, because a DTD is a _syntax_ description.
Seriously, please go and look through XHTML2 and think about what would be involved in implementing a UA that has to allow mixing XHTML2 and XHTML1 in the same document, which is what web browser would be required to do.
> You can perfectly well move content between > different versions of Word/Excel documents
Please read what I said more carefully. I addressed this.
> Why would your in-memory representation effect > your serialisation to/from XML?
Because what's serialized is the localname and namespace, and those are identical for the two elements that are supposed to have different behavior. Again, did you actually read what I wrote?
I think we're done here, since you've moved on to ad hominem attacks....
> How the hell do you think applications such as > Word deal with different file formats such as.doc > and.docx?
Easy. You don't have requirements about being able to move things from one to the other in unconstrained and non-opaque ways like web pages do.
> even if it means supporting different DOM > implementations
You have to be able to move elements from one DOM to the other whenever script decides to do it. That's the whole problem, as you would have realized if you'd taken a moment to think about this instead of assuming that everyone else has no idea what they're doing.
Of course with enough effort and pain and memory usage and indirection this is all achievable. You _can_ get to a world where two elements with the same tag name and namespace in the same document have totally different DOM behavior. It just means you can't serialize that document as XML. And violates some other W3C standards. But it _can_ be done.
Then the question becomes whether creating an inconsistent and confusing system that violates existing standards is better for the world than just ignoring XHTML2. This is indeed debatable, but in practice most people decided it's not.
And yes, I do have some grounding in software development. Both academic and practical. Though I've only been working on web browsers for about 12 years or so; obviously there are people who have more experience than me.
> If by deliberately you mean they came to a > compromise
No, I meant what I said. Please do go and compare the HTML4 spec to what browsers actually implemented at the time it was written. I'm talking basic stuff like the comment syntax.
> The point of a specification is to specify how things > should be done
Well, sure. But it needs to do this in a way that interoperates with existing things to some extent if it wants to be successful in the market. Or put another way... if a specification is too wacky, people can't use it in practice even if they want to, and then it fails.
And to be more precise, a specification should say how things should be done to enable all the various parties involved (software, in the case of the W3C, but for other specifications in other contexts it can be hardware of various sorts) to interoperate with each other. Things like your nuts fitting your bolts, or your web browser understanding the bytes your server sends. If implementing the specification does not in fact allow interoperability to a sufficient extent (and the extent can include legacy systems in many cases), then the bug is in the specification.
> You use your XML parser for XHTML
XHTML2 requires different output from your parser than XHTML1 does. For the same input.
Have you ever actually _read_ these specs?
> so one minute you're pretending there was no > transitional tool
XHTML1 was a recasting of HTML4 in XML syntax. XHTML2 was a completely unrelated beast that made the mistake of reusing the same namespace for incompatibly functionality. XHTML1 doesn't help you get to XHTML2; arguably it makes it _harder_.
> why do browsers now support both is this is true?
Both what? HTML5 doesn't redefine the behavior of HTML4 tags in incompatibly ways. That's one of your complaints about it, in fact, as far as I can tell. But it sure does make it possible to actually implement HTML5.
> It's basic software engineering, the parser should > be separated from the renderer with an abstraction > layer
XHML1 and XHTML2 use the same (XML) parser, by definition.
The problem, again, is that the two specs require different semantics out of elements with the same namespace and localname. Which happens way after the parser.
Note that there's a lot of stuff that happens above the syntax level in HTML (everything operating on the DOM, including CSS), and the DOM level is what was incompatible between the two specs.
> Step 2 was never addressed because browser > vendors found it too tempting to try and push the > web they wanted,
OK, so how would you have addressed it if you were a browser vendor?
> It's hard to have a deployment plan if the key > players wont play ball
Bingo. But I think you have a different impression of what "play ball" means here than I do. The only way to deploy XHTML2 would have been to have a flag day when everyone stopped using XHTML1 and HTML4. And website operators were refusing to play ball on that. Can't say as I blame them.
> two parsers, something they now magically have.
Web browsers have an XML parser and an HTML parser. Is that what you mean? Because if not, I'm following. Of course if that _is_ what you mean, I don't understand the relevance, since the XML parser would be used for both XHTML1 and XHTML2... except it would magically need to behave differently for them.
> but in reality they were merely failures by the browser > vendors to properly implement the spec.
They were failures caused by the spec being deliberately written to not match behavior of already existing and deployed systems.
The point of standardization is generally to take a bunch of stuff that's going on already and reconcile it so that people all do it the same way. What that _usually_ means is that if they're all doing it the same way already, you just spec it that way unless there are incredibly important reasons not to (e.g. it's a security flaw, in the browser space). It doesn't really work for the spec to forbid behavior X if there are already lots of existing deployments that depend on behavior X.
But development of HTML at the W3C had a tendency to see the spec as a club, not as a way to get everyone to agree on the same thing. Which is slightly backwards.
> There's nothing in the HTML4 spec that couldn't > be implemented properly
If you actually implemented parsing of HTML4 the way the spec required at the time it was written, you would fail to parse many web pages of the time "correctly" (as in, in a way that would actually render them the way they were expected to be rendered by their authors).
That's not to mention that the spec didn't actually define the parsing of many other web pages (indeed, most of them). Which is a bit of a problem if the point is to actually achieve interoperable behavior.
This was the usual problem with HTML4, in fact: it was written in a way that was impossible to implement interoperably without reverse-engineering another browser, because it left so many critical things undefined.
> Why is this a problem?
Why is it a problem that a single program can't implement both HTML4/XHTML1 (which are basically the same except for the XML syntax for the latter) and XHTML2? It's a problem because it meant that there was no deployment path for XHTML2: no browser could actually implement it correctly without breaking their HTML4/XHTML1 support. And they had absolutely no incentive to do that.
> I believe most browsers have implemented XML > rendering now anyway?
Sure, but the "XML" bit wasn't the problem with XHTML2. Things like "assign different semantics than XHTML1 to the same namespace+localname pair" were a bit more of a problem.
> simply writing off those interested in true > separation of concerns as pie-in-the-sky projects
No, I'm writing off the particular _approach_ they took to that goal as a pie-in-the-sky project.
In particular, the project was structured as follows:
1) Create a new version of HTML that no existing browser can implement without dropping support for the old version of HTML, the one that lots of sites already use. 2) ??? 3) New version of HTML replaces old version on the web and life is good.
Step 2 was never really addressed, which was the problem. There were lots of good ideas in XHTML2, but the particular way they were being put into practice was completely unrealistic.
But maybe I'm missing something. If you were involved in the standards process at the time, perhaps you happen to know what the actual deployment plan for XHTML2 was? I certainly never heard one.
> anything Chrome supports will also be supported by > Safari
Not necessarily. Chrome supports WebGL, and has for a while. Safari does not. Chrome supports Theora and VP8 video and Vorbis audio. Safari does not. They have totally separate implementation of requestAnimationFrame, which behave pretty differently. They have totally separate network stacks (and for example Chrome supports SPDY while Safari does not). They have different crypto libraries with different capabilities. They have different JS engines with different capabilities and different levels of support for the ECMAScript standards.
It goes the other way too. Safari on iOS supports a bunch of -webkit CSS properties that Chrome (and for that matter Safari on desktop) doesn't support. Safari on recent MacOS beats the pants off Chrome in terms of painting performance last I tested.
Key to all this is that there are multiple different "WebKit"s involved, and a lot of the functionality of a browser is not part of WebKit proper.
The criticism of the W3C that led to WHATWG being formed was twofold:
1) The W3C wasn't fixing obvious bugs in HTML4 (e.g. places where the standard required behavior that was not compatible with actual websites).
2) The W3C was instead spending its time working on XHTML2, which it had purposefully designed to be backwards-incompatible with HTML4 so that you couldn't implement the two in a single rendering engine.
A large part of the reason for #2 was that the browser vendors had at most 5 votes total on the working group, while there were lots of other voters who were more interested in pie-in-the-sky projects than actually producing something that could work on the web. So what the browser vendors _actually_ got tired of was having no say at all and everyone feeling entitled to order them to do their bidding, no matter whether the bidding made any sense.
Note that the current situation is pretty different from what was going on when the WHATWG was first founded. It's a bit of a mess, but it's not the complete and utter disaster things were back then.
The problems start when you create a non-moving-target standard that contains bugs. Little things like self-contradictory language, obviously false statements, requirements incompatible with the laws of physics. Sane standards bodies have an errata process to handle these things. Unfortunately, the W3C is... not very good at issuing errata in my experience (e.g. it took close to a decade before people gave up on getting any errata issued for HTML4 and created the WHATWG).
Now some people do thing that "living standard" means "add whatever you want, whenever you want it". That's pretty broken, I agree. But so is never fixing the bugs in the standard.
B2G (or Firefox OS, whatever you want to call it) is in fact doing process per app. Mozilla could do that today in Firefox (after putting in a bit of work to fix the existing Firefox UI). The problem is that it would break pretty much every single extension unless you took pains to make them work. But then you'd lose all the benefits when the extensions were installed, since they'd cause cross-process synchronization and blocking.
Slashdot Mirror
See, that's the thing. Everyone has heard, third-hand about someone saying that they heard some dev say something.
But whenever I actually look into it, turns out someone just made it up.
And yes, I've looked through most of the past discussions about Firefox, and in fact participated in them.
So again: are you just accusing people of lying with no evidence to back it up? Not very cool, that.
It hasn't "automatically blown up" extensions since Firefox 10, back in January 2012.
Firefox upgrades haven't broken compat with previous adons since Firefox 10 shipped back in January 2012.
Yes. Not only that, but cross-compilation of existing games to JS+WebGL. See https://hacks.mozilla.org/2012/08/mozilla-and-games-pushing-the-limits-of-whats-possible/
Can you point to an actual active Gecko or Firefox developer (not a fanboy, not someone who last worked on the project many years ago) saying there are no leaks?
Or are you just making up or blindy repeating the "developers told us there aren't any" thing?
Yes; it's just that some meats are more likely to do so than others.
That's true as long as Google is not creating its own walled gardens. Which it's hard at work doing, unfortunately. Not quite as bad as Facebook yet, thankfully.
Switching to mutton would have the side effect of tasting better too, for the most part. ;)
> Less beef might not be such a big problem.
It is if you want it to be affordable. But sure, not a big problem in the grand scheme of things, in theory.
Well, sure. Grandparent was talking about restoring those in lieu of the agriculture we do now, as far as I can tell. Which would be a pretty hard sell, but my point was that even that wouldn't be enough to replace current US beef production with grass-fed free-range beef.
According to http://www.americanbisonsocietyonline.org/AboutUs/Timeline.aspx there were 25-30 million bison on the Great Plains before we started seriously hunting them to the point of reducing their population.
According to http://www.beefusa.org/beefindustrystatistics.aspx there are about 95 million cattle in the US as of 2011. About 33 million were harvested in 2011.
So if we're willing to reduce the beef production by a factor of 3 from where we are now, we can probably avoid human management. Otherwise, chances are human management is needed.
That said, we certainly have enough beef for just the US here; the problems, if any, start when beef exports start competing on price with domestic purchases.
TFA, which you may have read, talks about working from home.
If you work from home, that often means moving large amounts of work data back and forth. It's common for me to want to grab a 40MB chunk of data on short notice and be blocked on work until it comes down. At that point, 25Mb (13 seconds) is way better than 5Mb (65 seconds, you're likely to go read webcomics and so forth). 300Mb would be 1s, which is _really_ good because it doesn't interrupt your workflow at all.
> 99% is rather a gross over-exageration
Not in my experience... I think you underestimate the extent to which XHTML was cargo-culted. I think I've literally run across only 2 or 3 non-example XHTML pages that were actually well-formed over the last 10 years or so.
> Many, many businesses across the globe don't
> even hand craft XHTML, it's built automatically
> using tools like XSLT
Sure. Though note that it's possible to produce non-well-formed XML even using XSLT (disable-output-escaping, which people use a fair bit). But there are also lots of non-XSLT toolchains that claim to produce XHTML... and just don't.
> A spec isn't really meant to work with real world
> content.
That, right there, is definitely a philosophical disagreement. There are lots of specs out there in which backwards compatibility was a hard requirement during spec development. Especially in the non-web world (gigabit ethernet, USB3, dual-channel DVI, and so on, and so forth). W3C specs were actually really _weird_ in their willingness to throw away backwards compat.
> and that's different to WHATWG how?
It's not that different in theory. In practice the set of participants is somewhat different at the moment, as you noted. So there are, for example, few people who are working in the WHATWG to shape HTML around their specific non-web use case.
Not that the development process for the WHATWG is a picnic, and God knows I've had my share of disagreements with the WHATWG spec, some of them still outstanding. Coordinating thousands of people with differing opinions is really hard. WHATWG is doing ok, but not necessarily great, in my opinion. I understand that you think they're not even doing ok.
But my personal experience, which reflects the interactions _I_ have had with WHATWG and W3C, is that WHATWG is more willing to at least listen to feedback and respond (if not necessarily take it into account) than some W3C working groups were back when WHATWG was founded. For those working groups, there was _real_ work behind closed doors going on: closed meetings that you couldn't attend unless you paid up, closed mailing lists you couldn't read or post to unless you paid up, closed decision process. Oh, and they were completely ignoring the W3C process requirements to address feedback on the drafts that they were in the end required to publish. _That_ sort of thing has largely gone away in the last 5 years, thankfully, due to WHATWG existing, but back when WHATWG started it was a very real part of trying to deal with the W3C.
See, the thing is that there is no such thing as a "version of a namespace" in XML. Just no such concept. There is just a namespace. What's supposed to happen when you have incompatible versions is a new namespace. But that didn't happen.
> it doesn't seem much of a big deal.
It's a huge deal. The corresponding bustage in IE6 where nodes from XHR couldn't be moved into normal documents was a huge pain point for developers until it was fixed.
> t's certainly far better than the current status quo
That's debatable, honestly.
> but people were moving their markup to XML
> syntax
No, they were moving it to XML cargo-culting. 99% of the stuff pretending to be "XML syntax" was not well-formed XML.
> I suspect the core problem here is a clash of
> ideologies
To some extent, yes. There _was_ a clash between "write specs that won't work with real-world content" and "write browsers that work with real-world content"...
But the authoring of self-contradictory specs has nothing to do with desire for stability and everything to do with the fact that the "W3C" is a bunch of independent working groups, composed of independent members, each with their own political, technological, and business ends. Sometimes the whole thing produces standards. Sometimes they're even good. Sometimes, it instead produces a self-contradictory ball of string that can't be implemented, and the you just have to excise enough of the bits to get something sane and only implement that. Which is what happened with XHTML2...
The basic "insoluble" problem is that XHTML1 and XHTML2 share a namespace. XML and the DOM specs define that the behavior and semantics of nodes depend only on their local name and namespace. But XHTML2 reuses some local names from XHTML1 but assigns different semantics to them.
Tracking origin information in memory _could_ be done, but it would result in bizarre behavior where you recreate a node in a way that XML and the DOM say should give you the same thing as you already have ... and it doesn't.
Now obviously changes could have been made to the XML and DOM specs to allow this all to work somehow, unintuitive as it would be, but the W3C wasn't willing to do that, unfortunately.
I never claimed to be "neutral", but you're trying to focus the discussion on claims that I personally am incompetent instead of the actual issues.
> other applications, such as Word, do exactly this.
No, they do not. They expose foreign objects through abstraction layers of their choosing, while web browsers have to expose everything through the DOM, which exposes all sorts of implementation details.
> so there's no issue.
Sure there is. Once nodes can be moved via script, your DOM may no longer match your DTD, because a DTD is a _syntax_ description.
Seriously, please go and look through XHTML2 and think about what would be involved in implementing a UA that has to allow mixing XHTML2 and XHTML1 in the same document, which is what web browser would be required to do.
> You can perfectly well move content between
> different versions of Word/Excel documents
Please read what I said more carefully. I addressed this.
> Why would your in-memory representation effect
> your serialisation to/from XML?
Because what's serialized is the localname and namespace, and those are identical for the two elements that are supposed to have different behavior. Again, did you actually read what I wrote?
I think we're done here, since you've moved on to ad hominem attacks....
> How the hell do you think applications such as .doc
> Word deal with different file formats such as
> and.docx?
Easy. You don't have requirements about being able to move things from one to the other in unconstrained and non-opaque ways like web pages do.
> even if it means supporting different DOM
> implementations
You have to be able to move elements from one DOM to the other whenever script decides to do it. That's the whole problem, as you would have realized if you'd taken a moment to think about this instead of assuming that everyone else has no idea what they're doing.
Of course with enough effort and pain and memory usage and indirection this is all achievable. You _can_ get to a world where two elements with the same tag name and namespace in the same document have totally different DOM behavior. It just means you can't serialize that document as XML. And violates some other W3C standards. But it _can_ be done.
Then the question becomes whether creating an inconsistent and confusing system that violates existing standards is better for the world than just ignoring XHTML2. This is indeed debatable, but in practice most people decided it's not.
And yes, I do have some grounding in software development. Both academic and practical. Though I've only been working on web browsers for about 12 years or so; obviously there are people who have more experience than me.
> If by deliberately you mean they came to a
> compromise
No, I meant what I said. Please do go and compare the HTML4 spec to what browsers actually implemented at the time it was written. I'm talking basic stuff like the comment syntax.
> The point of a specification is to specify how things
> should be done
Well, sure. But it needs to do this in a way that interoperates with existing things to some extent if it wants to be successful in the market. Or put another way... if a specification is too wacky, people can't use it in practice even if they want to, and then it fails.
And to be more precise, a specification should say how things should be done to enable all the various parties involved (software, in the case of the W3C, but for other specifications in other contexts it can be hardware of various sorts) to interoperate with each other. Things like your nuts fitting your bolts, or your web browser understanding the bytes your server sends. If implementing the specification does not in fact allow interoperability to a sufficient extent (and the extent can include legacy systems in many cases), then the bug is in the specification.
> You use your XML parser for XHTML
XHTML2 requires different output from your parser than XHTML1 does. For the same input.
Have you ever actually _read_ these specs?
> so one minute you're pretending there was no
> transitional tool
XHTML1 was a recasting of HTML4 in XML syntax. XHTML2 was a completely unrelated beast that made the mistake of reusing the same namespace for incompatibly functionality. XHTML1 doesn't help you get to XHTML2; arguably it makes it _harder_.
> why do browsers now support both is this is true?
Both what? HTML5 doesn't redefine the behavior of HTML4 tags in incompatibly ways. That's one of your complaints about it, in fact, as far as I can tell. But it sure does make it possible to actually implement HTML5.
> It's basic software engineering, the parser should
> be separated from the renderer with an abstraction
> layer
XHML1 and XHTML2 use the same (XML) parser, by definition.
The problem, again, is that the two specs require different semantics out of elements with the same namespace and localname. Which happens way after the parser.
Note that there's a lot of stuff that happens above the syntax level in HTML (everything operating on the DOM, including CSS), and the DOM level is what was incompatible between the two specs.
> Step 2 was never addressed because browser
> vendors found it too tempting to try and push the
> web they wanted,
OK, so how would you have addressed it if you were a browser vendor?
> It's hard to have a deployment plan if the key
> players wont play ball
Bingo. But I think you have a different impression of what "play ball" means here than I do. The only way to deploy XHTML2 would have been to have a flag day when everyone stopped using XHTML1 and HTML4. And website operators were refusing to play ball on that. Can't say as I blame them.
> two parsers, something they now magically have.
Web browsers have an XML parser and an HTML parser. Is that what you mean? Because if not, I'm following. Of course if that _is_ what you mean, I don't understand the relevance, since the XML parser would be used for both XHTML1 and XHTML2... except it would magically need to behave differently for them.
> but in reality they were merely failures by the browser
> vendors to properly implement the spec.
They were failures caused by the spec being deliberately written to not match behavior of already existing and deployed systems.
The point of standardization is generally to take a bunch of stuff that's going on already and reconcile it so that people all do it the same way. What that _usually_ means is that if they're all doing it the same way already, you just spec it that way unless there are incredibly important reasons not to (e.g. it's a security flaw, in the browser space). It doesn't really work for the spec to forbid behavior X if there are already lots of existing deployments that depend on behavior X.
But development of HTML at the W3C had a tendency to see the spec as a club, not as a way to get everyone to agree on the same thing. Which is slightly backwards.
> There's nothing in the HTML4 spec that couldn't
> be implemented properly
If you actually implemented parsing of HTML4 the way the spec required at the time it was written, you would fail to parse many web pages of the time "correctly" (as in, in a way that would actually render them the way they were expected to be rendered by their authors).
That's not to mention that the spec didn't actually define the parsing of many other web pages (indeed, most of them). Which is a bit of a problem if the point is to actually achieve interoperable behavior.
This was the usual problem with HTML4, in fact: it was written in a way that was impossible to implement interoperably without reverse-engineering another browser, because it left so many critical things undefined.
> Why is this a problem?
Why is it a problem that a single program can't implement both HTML4/XHTML1 (which are basically the same except for the XML syntax for the latter) and XHTML2? It's a problem because it meant that there was no deployment path for XHTML2: no browser could actually implement it correctly without breaking their HTML4/XHTML1 support. And they had absolutely no incentive to do that.
> I believe most browsers have implemented XML
> rendering now anyway?
Sure, but the "XML" bit wasn't the problem with XHTML2. Things like "assign different semantics than XHTML1 to the same namespace+localname pair" were a bit more of a problem.
> simply writing off those interested in true
> separation of concerns as pie-in-the-sky projects
No, I'm writing off the particular _approach_ they took to that goal as a pie-in-the-sky project.
In particular, the project was structured as follows:
1) Create a new version of HTML that no existing browser can implement without dropping support for the old version of HTML, the one that lots of sites already use.
2) ???
3) New version of HTML replaces old version on the web and life is good.
Step 2 was never really addressed, which was the problem. There were lots of good ideas in XHTML2, but the particular way they were being put into practice was completely unrealistic.
But maybe I'm missing something. If you were involved in the standards process at the time, perhaps you happen to know what the actual deployment plan for XHTML2 was? I certainly never heard one.
> anything Chrome supports will also be supported by
> Safari
Not necessarily. Chrome supports WebGL, and has for a while. Safari does not. Chrome supports Theora and VP8 video and Vorbis audio. Safari does not. They have totally separate implementation of requestAnimationFrame, which behave pretty differently. They have totally separate network stacks (and for example Chrome supports SPDY while Safari does not). They have different crypto libraries with different capabilities. They have different JS engines with different capabilities and different levels of support for the ECMAScript standards.
It goes the other way too. Safari on iOS supports a bunch of -webkit CSS properties that Chrome (and for that matter Safari on desktop) doesn't support. Safari on recent MacOS beats the pants off Chrome in terms of painting performance last I tested.
Key to all this is that there are multiple different "WebKit"s involved, and a lot of the functionality of a browser is not part of WebKit proper.
The criticism of the W3C that led to WHATWG being formed was twofold:
1) The W3C wasn't fixing obvious bugs in HTML4 (e.g. places where the standard required behavior that was not compatible with actual websites).
2) The W3C was instead spending its time working on XHTML2, which it had purposefully designed to be backwards-incompatible with HTML4 so that you couldn't implement the two in a single rendering engine.
A large part of the reason for #2 was that the browser vendors had at most 5 votes total on the working group, while there were lots of other voters who were more interested in pie-in-the-sky projects than actually producing something that could work on the web. So what the browser vendors _actually_ got tired of was having no say at all and everyone feeling entitled to order them to do their bidding, no matter whether the bidding made any sense.
Note that the current situation is pretty different from what was going on when the WHATWG was first founded. It's a bit of a mess, but it's not the complete and utter disaster things were back then.
The problems start when you create a non-moving-target standard that contains bugs. Little things like self-contradictory language, obviously false statements, requirements incompatible with the laws of physics. Sane standards bodies have an errata process to handle these things. Unfortunately, the W3C is ... not very good at issuing errata in my experience (e.g. it took close to a decade before people gave up on getting any errata issued for HTML4 and created the WHATWG).
Now some people do thing that "living standard" means "add whatever you want, whenever you want it". That's pretty broken, I agree. But so is never fixing the bugs in the standard.
B2G (or Firefox OS, whatever you want to call it) is in fact doing process per app. Mozilla could do that today in Firefox (after putting in a bit of work to fix the existing Firefox UI). The problem is that it would break pretty much every single extension unless you took pains to make them work. But then you'd lose all the benefits when the extensions were installed, since they'd cause cross-process synchronization and blocking.
Write it all in assembly, and more likely than not for a large system you get http://en.wikipedia.org/wiki/Therac-25