Live data from Hacker News

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

github.com

101–110 of 386 posts

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

#101
post #56

Earlier quoted context omitted.

That seems to ignore the conventional wisdom that according-to-Hoyle XHTML was a DOA standard because it mandated error handling in ways that no browser implemented and most of the authoring community didn't want. Authors don't write well-formed XML, even today.

>because it mandated error handling in ways that no browser implemented IIRC Opera implemented XHTML error handling.

IIRC several major browsers implemented XHTML error handling, but only for documents with a Content-Type: application/xhtml+xml header, which was basically nothing because that would then trip up other browsers

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

#102
post #97
post #37

Earlier quoted context omitted.

Oh? How many tools do you know that can parse a current HTML5 react app without importing any existing browser? Every tool we have to use on the web relies on 4 existing tools that only major companies can build. I’ll pay you $100 if you manage to write, in 4 weeks, a browser, from scratch, that renders a real life React app accurately, including all content, without importing a single bit of code or libraries from e…

What does it even mean to parse a React app? Crawlers can't resolve the halting problem, either.

> Crawlers can't resolve the halting problem, either.

And yet, that’s where we’re at today. Blogspot posts require JS. So many other pieces of content are similarily built.

And with phatomjs gone, we’re now running entire headless browsers just to test if websites are rendered correctly. It’s insanity.

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

#103
post #45
post #39

Earlier quoted context omitted.

HTML5 is amazing for existing browser vendors, developers, and in the short-term, users. But everyone else loses. Horribly. I don't understand who the 'everybody else' is in this case and what and when their horrible losing will be.

People trying to build new tools that parse the web. Try building a crawler without reusing an existing browser engine. Try running unit tests against your own web projects with Selenium without running a headless browser. Phantom.JS gave up because they couldn’t keep up with the complexity, and Chrome headless "just works". Opera gave up on their own browser engine because of the complexity of parsing HTML5 accurate…

One of the most valuable aspects of HTML5 is that it defines a parsing model for "broken" HTML.

This means tat, for the first time, it's possible to build a brand new HTML parser that has a high chance of working against all existing HTML without needing to first reverse-engineer existing browsers.

Remember, when HTML5 was first designed Internet Ecplorer was by far the most widely used browser. And IE was closed source. If you wanted to build a parser you needed to first reverse engineer IE and figure out how it handles invalid HTML.

The HTML5 spec fixed that. The thing you are complaining about here (HTML5 making it harder to build a new browser from scratch) is one of the things HTML5 actually solved!

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

#104

I'm not too knowledgeable on the background here, or on how the politics of standards organizations work, but my understanding is that the EU standards bodies (presumably as well as similar organizations for other governments) consider the W3C to be authoritative. Even if all the browsers prefer WHATWG's spec, won't they be forced to adopt W3C in the same way phones have to support USB charging[0]? [0] https://en.wik…

[edit: maybe entirely wrong? see reply.] USB-C was enthusiastically coinvented by Apple, not forced on them. They just let the standards orgs lead publicly to get broader suppot.

This is definitely not accurate. Apple didn't get on board until well after the connector and other things had been just about finalized. The price of making that connector a standard that Apple was willing to use was not pointing out it was made by a staunch competitor. I don't even think they were attending meetings.

(Gruber said something completely and totally wrong about this, which is usually the source of people's thinking apple did it. The history here is well documented, just not well known or well publicized, deliberately, so Apple could save face)

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

#105
post #5

For some clarity: - Mozilla's Objection: https://github.com/w3c/dom/issues/175#issuecomment-380771954 - Apple's Objection: https://github.com/w3c/dom/issues/175#issuecomment-380534425 - Microsoft's Objection: https://github.com/w3c/dom/issues/176 - Google's Objection: https://github.com/w3c/dom/issues/177

It's interesting that a formal objection is done by creating an issue on github.

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

#106
post #94

Earlier quoted context omitted.

Did you look at the list of members? Who on the list is going to be building their own browser and what would the business case be? Out of the big four, only two of them even thought it made sense to build a browser from scratch. Apple and Google started off with KHTML. EDIT: To clarify. Who is going to be building their own rendering engine instead of taking an existing one - 3 of the 4 are open source - and buildin…

The lineage of the rendering engine doesn't matter. What gives Apple and Google and Microsoft command of the standard is the fact that they mediate access to web pages; they own th actual customers. That's what matters.

Firefox doesn't own the customer.

But creating a rendering engine from scratch is hard and there is no business case for anyone doing it from scratch. Apple didn't (they tried with CyberDog ages ago) they used KHTML to create WebKit. Google didn't either, they started with WebKit. Opera gave up on their own rendering engine years ago.

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

#107
post #17

Earlier quoted context omitted.

I don't know of an article, sorry. A brief history from memory would be that during XHTML days the W3C essentially let the HTML spec languish and people weren't moving to XHTML (at best they were moving to XHTML-like HTML). So the WHATWG came along (mainly organised by the major browser vendors) and started the HTML spec moving again. This became part of what's known as HTML5. However WHATWG doesn't exactly make a "s…

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…

> Most of the web quickly moved to XHTML.

This simply is not true. The web moved to an XHTML-like dialect of HTML which was still served as text/html and browsers interpreted it as "HTML soup" because actually serving pages as application/xhtml+xml would have broken the majority of the web because browsers would actually validate them and refuse to display a page at all if there was even a single missing close tag.

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

#108
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…

> This lead to the W3C specs becoming totally redundant and the only way for W3C to keep up was to lamely try to copy from WHATWG into a "spec" at random intervals and claim it was something people could work towards So why don't they just disband the W3C? It sounds like it's not needed any more if WHATWG are doing the work?

The W3C actually does do some good work in other working groups; the CSS working groups seem to be working smoothly.

The W3C also oversees a lot of other standardization processes that aren't directly related to web browsers, like RDF. There are people who find this useful.

I think a lot of it is a power play. The W3C wants to be relevant, and the most relevant things in the web world are HTML, DOM, and CSS (there's also ECMAScript, but that already has a different standards body that owns it).

There are a lot of other standards that use HTML, CSS, and the DOM, such as ePub. The W3C wants to be the normative reference for these core web standards; many times, one standard will have to refer to the other, so the W3C wants to be the one that defines the "official" HTML standard.

But the W3C's process and policies are just terrible. They let people take over standards who have no intent on working with those most impacted by the standards, the people who develop the browsers that billions of people use daily to access tons of diverse content. So instead of just providing a lightly edited snapshot, possibly with some WIP features removed, of what the WHATWG produces, they start going in and meddling and making changes with insufficient justification so you have two forked standards providing a lot of confusion for everyone.

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

#109
post #56

Earlier quoted context omitted.

That seems to ignore the conventional wisdom that according-to-Hoyle XHTML was a DOA standard because it mandated error handling in ways that no browser implemented and most of the authoring community didn't want. Authors don't write well-formed XML, even today.

>because it mandated error handling in ways that no browser implemented IIRC Opera implemented XHTML error handling.

Opera had the "draconical" approach, where upon the error you just had that, an error. Firefox, iirc had a softer approach where you still got the page rendered, but you'd get the error reported too. Anyway it all depended on the proper MIME type for the XTHML (as it should). However the whole MIME type and everything associated with it (some elements and APIs are treated differently) is a whole barrel of worms, so XHTML in any of the incarnations was never a good idea.

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

#110
post #37

Earlier quoted context omitted.

> Do you see an innovative ecosystem there? Yes! Everyone says that the specification approach is what was severely limiting innovation, and when they took the living specification approach instead that's when web innovation took off again.

Oh? How many tools do you know that can parse a current HTML5 react app without importing any existing browser? Every tool we have to use on the web relies on 4 existing tools that only major companies can build. I’ll pay you $100 if you manage to write, in 4 weeks, a browser, from scratch, that renders a real life React app accurately, including all content, without importing a single bit of code or libraries from e…

> Oh? How many tools do you know that can parse a current HTML5 react app without importing any existing browser?

I don't recall XHTML deprecating JavaScript- pray tell, how would you render the XHTML version of a react app without a browser, or a JS engine as a bare minimum? (X)HTML is orthogonal to Js/react.

I could develop a self-driving car for $50 000 (instead of millions) if human drivers and pedestrians started behaving in well-defined patterns, following strict rules and stopped doing stupid, unexpected things. I'd really love that, but it's not going to happen even though there already are "standards" in the law books.

Post reply on HN