Live data from Hacker News

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

github.com

151–160 of 386 posts

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

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

It seems like the web is 10 times more parseable. I feel like almost all content is now delivered via JSON services, and the HTML around it is constructed on the fly and is totally pointless to look at. At least that's the direction I've seen. I don't know how "everyone else" are people that are writing parsers. Seems like that would be a tiny percentage of the population, not "everyone else".

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

#152
post #77

Earlier quoted context omitted.

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 e…

What makes that story (in my link) so compelling to me is that it happened to people who were XHTML advocates. They were the people arguing that browsers should be strict. They were the people writing blogging software The Way It Should Be Done, to ensure maximum XHTML compliance. It was a blog entry that was specifically arguing for strict parsing that it became invalid XHTML due to a bug. If true believers can make…

Yes, but if browsers were strict by default (or at least by default in dev mode), the bug in his compositing software likely would have been found and fixed much earlier, and it wouldn't have persisted into production.

So again, I understand that it's nearly impossible to make the transition now, but that doesn't mean it wouldn't be preferable. And there's no reason the transition couldn't still be made, but much more slowly, and perhaps without ever making the big browsers reject by default.

I don't know if there are other disadvantages to XHTML, but if the strictness issue is the only one, then it seems like there would still be value in slowly transitioning over.

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

#153

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…

> 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.

> This simply is not true. The web moved to an XHTML-like dialect of HTML

You're thinking of XHTML 1.1 or XHTML 2. That "XHTML-dialect" that everyone switched to was called "XHTML 1.0", which allowed serving as either content type.

If you're choosing to nitpick about the fact that most sites published would not have worked if served as application/xhtml+xml, I'd invite you to do a survey of sites currently being served as valid HTML5. It's not even that easy to verify as the Nu validator version in use varies so much depending on where it's hosted (or if it's a local jar), and which iteration of the living standard it conforms to is always ambiguous. Have you tried reading the WHATWG spec diffs?

The burden on devs who might like to adhere to any kind of strict automated verification of spec. conformance is now out of the question. With XHTML, even if you were serving non-well-formed XML with a text/html content-type, at least your markup could be trivially checked for conformance by almost any XML parser to see why it's not well-formed. It was actually conceivably viable to put that check into build steps or CI.

Serving application/xhtml+xml was a nice to have, but anyone believing that serving XHTML as text/html had no value completely missed the point. At least now, years later, the mess we're stuck with should make it a little easier to see though.

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

#154

Earlier quoted context omitted.

> 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.

Oh I remember this period of time and damn this is true. I think about 80% of the pages on the web during a certain time period had that tramp-stamp of XHTML Validated button somewhere on the page.

Only the cool sites :)

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

#155
I see this in another way, and I might not be right but my recollection of the matter was around 2008 and the stale state of the (X)HTML spec(s).

WHATWG came along and was heavily (as I remember it( supported by Google due to the Chrome browser and lack of evolution from W3C and particularly the sad browser state of IE.

Back then Microsoft was sitting on the browser market as Google is today. But Google needed to enforce something different than W3C so it could build a better browser than IE, but with a different (and perhaps a more controlled) spec.

Today, web standards is in a much worse state than they were 10 years ago. And having been developing for the web the last 20 years, it is not easier than it was "in the old days". It's perhaps more fun, but it's not easier.

And some of that frustration is partly due to the disruption of this specification.

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

#156

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…

The only "standard" that matters is the one everyone uses. Everything else is a nice wish list for discussion but eventually needs to get out of the way.

The WHATWG doc is a fine standard, backed up by real implementations. Beyond that, W3C is just copy/pasting whatever WHATWG has every few months so what's the point?

And you really think the web is in chaos? We're at an incredible era of possibilities because browsers like Chrome constantly make progress instead of devolving into a bike-shedding argument for years. What APIs do you find so useless or abandoned and why can't you just not use them if so?

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

#157
post #72

Earlier quoted context omitted.

No. They could matter, if they built a browser with competing market share. It's not a static equilibrium.

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…

"Who is going to be building their own rendering engine instead of taking an existing one"

Just for the note: I did - https://sciter.com

It was not meant to render all possible pages from Wild World Web but it renders HTML5/CSS3 (some subsets but still).

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

#158

time to use WASM to render the whole thing, ditch W3C. and all the players are there to make the change.

This view is erroneous. May an honourable gentleman tell us what company he is working for?

The main reason WASM proponents push is to have an ability to close down their code.

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

#159
post #131

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…

> Most of the web quickly moved to XHTML. Most of the web didn't move to XHTML. A lot of people who were interested in being standards compliant moved to XHTML 1.0 Transitional, which was the HTML compatibility subset, but they only ever served it and validated it as HTML, not XHTML, because if you served it as XHTML, one single stray The piece written by Hixie was influential because it was a wake up call that the d…

> and having to be extremely conscious of any possible stray Any system that publishes content that would let this kind of thing pass is incredibly insecure, and shouldn't be on the internet. Today it's a stray

It's no wonder software is where it is today with attitudes like these.

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

#160
post #18

Earlier quoted context omitted.

> the W3C, still being relied on by the other actors on the web that aren’t the 4 largest browsers Why do other actors need to rely on the W3C? Why can't they use the WHATWG specs as well? You say they're more complicated, but if that's what the browsers do then that's what they do.

Because the XHTML spec would have made a lot of things easier. I can write an XHTML1.1 parser and renderer in about one month. Writing an HTML5 parser takes thousands of developers 5 years.

> Writing an HTML5 parser takes thousands of developers 5 years.

This is demonstrably untrue. Servo's HTML5 parser, html5ever, was largely written by a single developer within a year. (Yes, it's not a month, but it's also not 5 years.)

Post reply on HN