Live data from Hacker News

Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec

github.com

161–170 of 386 posts

Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec

#161

Earlier quoted context omitted.

To put a slightly different spin on the same story as perspective always colours the telling: W3C decided to deprecate HTML in favour of XHTML. Most of the web quickly moved to XHTML. One individual (an employee at Opera, then Mozilla, finally and currently Google) wrote an oddly influential opinion piece saying the the move to XHTML had been somehow harmful and pushed for the major browser vendors to form a rival no…

> not all related to browser making, quite understandably was never fully on board with the new WHATWG HTML spec efforts. That's the other thing that pisses me off about the WHATWG, is how much they shit all over XML and other interoperability technologies. E.g. their URL standard (because, why not fuck the IETF as well) basically ignores anything non-HTTP for specious reasons.

The only reason there is a URL standard in the WHATWG is that the IETF URL RFC didn't define error handling and this led to interop problems. So there was a need for a URL standard that _would_ define error handling. The IETF refused to produce one (basically said "fuck you, we don't care about your use cases or interop problems" with slightly more polite wording), so the WHATWG ended up doing it...

I'm not saying this is a great situation. I'm not saying the WHATWG couldn't try to do better at considering non-HTTP or non-browser use cases here. But the representatives of those use cases in the IETF told browsers to take a hike. And then browsers did.

Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec

#162
post #42

Earlier quoted context omitted.

No, it wasn't simply a question of backwards compatibility. The W3C wanted (wants?) to pursue its own quixotic vision of a semantic, machine-readable web. One in which the needs of human users, browser user agents and use cases like web apps was of incidental importance at best. The HTML5 spec effort that gave birth to WHATWG wasn't simply about documenting backwards compatible parsing, it was about vendors like Mozi…

Yes, and today we’re left with a web that you can only parse if you’ve got a few thousand developers and billions of dollars to throw at the issue. As I wrote below, I offer $100 to anyone that can write a tool that can fully parse and render HTML5, the entire spec, and can a real-life React app, within of 4 weeks, without using any existing library or code for the parsing or rendering. Doing the same for XHTML and a…

React probably uses HTML5 APIs but could probably be re-written to do the same thing without them... I'm not sure anyone here is interested in $100 as they probably wasted at least that much "company" money reading this thread this happy Friday.

Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec

#163

Earlier quoted context omitted.

Yup, every page looks different anyway, calling megabytes of minified, obfuscated JavaScript. There is probably more in for the user. I guess then you only need , , and a subset of DOM.

And you'd need to handle accessibility considerations, and font and encoding support, and a flexible layout engine, and multiple input methods, and scrolling, and search engine standardization, and more all yourself. By the time you handle most of it, all you've done is make a wildly more complicated version of the DOM.

I doubt that will be worse than Flash.

Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec

#164
post #61

Earlier quoted context omitted.

To put a slightly different spin on the same story as perspective always colours the telling: W3C decided to deprecate HTML in favour of XHTML. Most of the web quickly moved to XHTML. One individual (an employee at Opera, then Mozilla, finally and currently Google) wrote an oddly influential opinion piece saying the the move to XHTML had been somehow harmful and pushed for the major browser vendors to form a rival no…

I'm not certain that it's true to say most of the web quickly moved to XHTML. Sure a number of sites advertised themselves as XHTML but they were not strictly XHTML compliant. This could be due to third party widgets or other included code or it could be due to a mistake in template construction. Whatever the issue fully compliant XHTML wasn't used much in practice outside of hand-crafted pages. Also Internet Explore…

> they were not strictly XHTML compliant

The vast majority were not strictly XHTML compliant, but whatever the figure was, I'd imagine it wasn't too different to all the many "strictly HTML compliant" sites now (compliant according to which commit?).

The point was they used XHTML, which means they could trivially choose to validate and test their XML well-formedness with built-in tools everyone had ready access to. Exposing your end-users to those conformance checks (i.e. the in-browser strict XML-parser) wasn't the only "value" offered.

Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec

#165

What a monumental waste of time. Why not just ignore W3C entirely? Seriously, what exactly are they going to do? Publish more? Sometimes it's better to not be nice and just let reality finish the job. So much effort taken from people who clearly have better things to do...

W3C attempts to make proper web standards. Apple Google MS break them and and try to push for substandard specs pushed through W3C. As a web developer for 11 years, I can state that web development is devolving to chaos of IE6 era. When W3C allowed itself to be subverted and let big dotcom browsermakers to hijack the process. A result of that is the continuous bloating of the acting web standard, when you have dozens…

> As a web developer for 11 years, I can state that web development is devolving to chaos of IE6 era.

This is a poor comparison. The problem of the IE6 and below era was that Microsoft was adding capabilities to IE without standardizing them. Now, browsers add non-standard capabilities to their browsers to trial their implementations (remember CSS gradients) but eventually move them through the standards bodies before formally declaring their support.

If you're using non-standard APIs, and they break for you before Recommendation, that's your own fault.

Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec

#166
post #51
post #41

Earlier quoted context omitted.

The idea that standards groups exist to push for top-down reconcepting of how the world should work is a common one, and is also a good reason why standards groups fail. Your idea of what the best outcome is won't be the same as every other stakeholders, and no one stakeholder will have exactly the same idea of the best outcome as the market will. Ultimately, the market will win, no matter what your standards group s…

When I was a child in elementary school, a standards committee decided to change my native language. They replaced the spelling of most words, and many grammatical rules. We were forced to obey these changes, any use of the old rules was counted as mistake in school. Back then, many older books were still using the old rules. By the time I left high school, almost no books with the old rules were left. All had been r…

Apples and oranges - when you introduce a government mandate, you remove the market. @tptacek's aregument is clearly about market forces in publicly defined standards, not government enforced ones.

I'm pretty sure the last thing anyone really wants is what we'd wind up with if web standards were left to government dictates...

Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec

#167

Earlier quoted context omitted.

To put a slightly different spin on the same story as perspective always colours the telling: W3C decided to deprecate HTML in favour of XHTML. Most of the web quickly moved to XHTML. One individual (an employee at Opera, then Mozilla, finally and currently Google) wrote an oddly influential opinion piece saying the the move to XHTML had been somehow harmful and pushed for the major browser vendors to form a rival no…

> W3C decided to deprecate HTML in favour of XHTML. Most of the web quickly moved to XHTML. In some parallel universes, yes. Even if so, there's also the fact that XHTML wasn't updated itself with features people needed.

What features?

If you're referring to "features" in the HTML5 spec., like canvas, webgl, geolocation, DOM etc. they were separate specs, which WHATWG lumped into one monolith (though they're mainly JavaScript APIs, and aren't directly related to HTML). They were being worked on separately to XHTML, and still work fine with XHTML to this day.

Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec

#168
post #23
post #13

Earlier quoted context omitted.

To offer another perspective. I'd say the W3C wasted a huge amount of time pursuing quests of purity (XHTML) over actually making the web better for users. I see the value in what they were trying to do, but it wasn't letting people do the things they wanted to do on the web. As browsers started just implementing features outside of standards in completely disparate ways because everyone was desperate for them (leadi…

> I'd say the W3C wasted a huge amount of time pursuing quests of purity (XHTML) over actually making the web better for users. I see the value in what they were trying to do, but it wasn't letting people do the things they wanted to do on the web. Okay, let’s make a deal: We both write a crawler that can fully reliably parse websites. I implement XHTML1.1, you implement HTML5. We both get 1 month time. What do you t…

> I implement XHTML1.1, you implement HTML5. We both get 1 month time.

Do you get to use libraries or not?

If you get to use libraries, there are plenty of libraries for both of these tasks, so it will be fairly equivalent. In fact, if you want to really support XHTML well, it will probably be more complex, because you have to take into account namespaces; a tag or attribute is not just a simple string, you have to consider the namespace it's in, so you would have to deal with that.

If you have to write it from scratch, I'd actually also bet on it being quicker for HTML5. The exact algorithm is specified in the standard; you just have to translate that from pseudocode into whatever language you're working in.

In XHTML, you have to look through several standards (XHTML 1.0, XHTML Modularization, XML 1.0 which includes the DTD, XML Namespaces, XML Schema), and then translate from the specification in a declarative style into a algorithm that can actually be used to parse the document. XML parsing is actually quite complicated.

> XHTML was a worthy goal – with it, we wouldn’t have a need to run headless Chrome for tests. We could parse the web, and actually use the data.

What? XHTML wouldn't have replaced the use of JavaScript to add features and load content. It wouldn't have replaced people's inappropriate use of tags. It wouldn't have replaced the fact that web pages are written for human consumption, and so don't generally try to include appropriate annotations on data for processing by other tools.

> HTML5 is amazing for existing browser vendors, developers, and in the short-term, users. But everyone else loses. Horribly.

Imagining that some magical standard is going to make everything better for users is a pipe dream. Providing good data formats and APIs for exporting data is hard, and is a different problem that providing user interfaces and interactivity. There's not some way in which XHTML could have been extended to serve both purposes; they are just too different.

This is why, when people care about providing programmatic access to data, they generally provide two endpoints; one serving HTML, CSS, and JavaScript for humans to interact with, and one for providing JSON for machines to parse. There have been endless attempts to try and make one standard that would work for both purposes, and they've failed because that's just not a good approach for solving the problem; instead, it's better to just have an API that both the UI code (whether on the client or server side) can use, and other developers can use if you want to expose it.

Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec

#169
post #116

Earlier quoted context omitted.

You mean, just like in many other languages? According to Wikipedia, French, Icelanding, Spanish, Swedish, and a few more have had varying degrees of prescriptive language standardization. > Yes, the German language has had several big changes, but until the reform we‘re talking about it was linguistically „proper“ in that the existing language was described and codified. It was bottom up. I just explained why that w…

You simply don't understand what I have written. I think we can leave it here. I don't care about your opinion that it's "fake" and "emotional". Language is a core part of my being, and a fascist power-grab killing my mother tongue is simply a crime against humanity. It's no different from how the Turks have been treating the Kurdish language. I have only weak hope, but still hope, that we can someday reverse this. V…

Do you believe languages are meant to live forever?

Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec

#170

Earlier quoted context omitted.

Users should have a voice too.

They do: they pick which browser to run, and thus give power to.

Hmmm... Do you remember IE6 days? It was the best browser at that time - at least in respect of user base.

Yes, they did a lot of innovations there we all use now. Most notable - the whole AJAX idea was born there.

Post reply on HN