Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

121–130 of 386 posts

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

#121

Post by y4mi »

colanderman wrote: post #78
ChrisSD wrote: 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…

> The WHATWG has always opposed the W3C's spec. They see it as confusing to have two "official" specifications. As the old joke goes... if it hurts, they should stop doing that! The WHATWG spec is worse than useless to me as a developer. It's impossible to tell what is usable and what is just Google's wishlist (which is about half of it). The MDN has entirely replaced it for me, since they at least do a good job of d…

Urm, I thought MDN was based on WHATWG? (Not W3C)

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

#122

Post by xtian »

Sharlin wrote: post #107
lucideer wrote: post #48

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.

And the versions of IE in use didn’t support application/xhtml+xml anyway so you would have to switch to text/html based on the user agent string.

It was never clear what the technical benefit of this was supposed to be. I only ever saw one site whose pages served double duty as an API and UI by serving styled XML. It seemed like a challenging approach to pull off well.

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

#123

Post by coldtea »

lucideer wrote: post #48
ChrisSD wrote: 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…

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

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

#124

Post by winkeltripel »

rimliu wrote: post #109
anonymfus wrote: post #66

Earlier quoted context omitted.

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

> "draconical"

That's xml error handling, following rules as written.

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

#125

Post by manigandham »

chrismorgan wrote: post #114

Serious question: why are the W3C still publishing or trying to publish standards for DOM and HTML and probably a few others, when no one that matters cares about them? Why not rather throw in the towel on those particular standards and acknowledge that the WHATWG has won on them?

It's especially amazing that there's a comment asking what the WHATWG will give up in return if W3C gives this up... as if this is some kind of battle truce.

These people are living in wonderland and need to wake up to the reality that there's already a winner and the war is long over.

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

#126

Post by tptacek »

kuschku wrote: post #115
monetus wrote: post #93

Earlier quoted context omitted.

It would be awesome if the layers of the browser would allow for a more parseable, document-based web. That would be an effort towards standardization. But are you really advocating for removing dynamic media from the browser? That seems like an incredible step backwards in most regards. In the absence of a desktop toolkit to rule them all, browser standardization is what we are left with right?

> In the absence of a desktop toolkit to rule them all Qt. Runs everywhere, works everywhere, just fine.

If only some standards group somewhere could mandate that everyone use Qt.

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

#127

Post by tptacek »

winkeltripel wrote: post #124
rimliu wrote: post #109

Earlier quoted context omitted.

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

> "draconical" That's xml error handling, following rules as written.

"Draconian" error handling is a term of art in HTML.

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

#128

Post by manigandham »

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

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

#129

Post by dkersten »

scarface74 wrote: post #62

We know that Apple, Google, Microsoft, and Mozilla, consider the WHATWG to be the canonical version. We don't yet know whether the other 450+ W3C member organisations that represent the wider web platform agree with this position or not though. Honestly, do the other 450+ W3C member organizations matter? ( https://www.w3.org/Consortium/Member/List )

I came here to ask the same thing! If all the major browser vendors think one way, then it’s irrelevant how many people disagree with them.

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

#130

Post by blablabla123 »

kuschku wrote: post #23
Latty wrote: 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…

IMHO XHTML is pretty painful. Even if you say: okay, there is a server-side auto-generated markup tree and we can formally verify what happens. There is now a solution to that and it's called (server-side) React which is basically a (useful) alternative to XSLT. Except that it outputs HTML5.

Even if you argue that the specs are huge. Just compare book sizes about XML, XSLT vs HTML5 and CSS, JS, React. When I actually tried to do some useful work with XSLT (which needs to be mentioned here IMHO), I realized that the - less painful - 2.0 version is hardly implemented by anyone.

Regarding the parsing: X(HT)ML lexing is ridiculously easy, for HTML5 it's slightly more difficult but not tough at all. You just need to keep a list of closing vs self-closing tags. Not talking about building in fault-tolerance, that would be tough, yes, even tougher for XML!

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

> OpenGraph tags would never have been necessary. We wouldn’t need to throw

> DNNs at rendered output of a browser just to parse data.

Yes and no. If you use CSS for styling, the answer is no. If you require JS to show the initial show/page, the answer is no as well. But yeah, if you use the whole XML machinery with XSLT and possibly even XPATH, then you would be kind of right. I mean, as long as we properly handle the schemas and dtd's - which almost no parser does AFAIK. So it's true, one can do pretty bad-ass stuff with all the X*. But tooling and library support is not good and has never been. XSLT 1.x is insanely difficult to use and XSLT 2.x hard to fully implement I guess.

Post reply on HN