Live data from Hacker News

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

github.com

201–210 of 386 posts

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

#201
post #85

Earlier quoted context omitted.

Is there an article with the background on this? Why do we have both the W3C and the WHATWG, and why do the W3C just copy and paste work from WHATWG, if that is indeed what happens?

Way back in the day, HTML was implemented as an application of SGML. SGML was a quite complex markup format, that had lots of features that were kind of complex to implement, and so web browsers didn't actually implement all of SGML, just that which was necessary for HTML and the HTML found in the wild. However, the HTML found in the wild was frequently invalid, so browsers had to implement some clever rules to do so…

> Way back in the day, HTML was implemented as an application of SGML.

[citation needed]

I'm unaware of basically any implementation of HTML treating it as an application of SGML; the only notable case I'm aware of is the old HTML validator.

Tim's original implementation of HTML didn't treat it as SGML.

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

#202
post #57
post #45

Earlier quoted context omitted.

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…

I very much doubt Opera gave up because of "parsing HTML5". Parsing HTML5 is well-defined, certainly better than what was there before (unless you are willing to say "if you don't write perfect XML you don't get to be on the web", but good luck with that – no browser ever was and never will be in the position to do that) The vast majority of the difficulty of the web platform is in the layers above, which don't care…

Indeed, having worked for Opera during the time where we implemented HTML5-compliant parsing, the net result was that we fixed a bunch of site compatibility issues. Implementing it made competing with other browsers easier. (And as you say, parsing HTML is complex, but the rest of the web platform is vastly more so.)

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

#203

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.

What do you mean by non-HTTP? It handles URLs whose scheme is not http(s): just fine...

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

#204

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.

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

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

Completely different thing. XML processing and all reasoning based on the premise of XML processing are fiction when XHTML is served as text/html. The HTML parsing algorithm and tve rest of the processing requirements is not fiction when HTML is invalid.

(Why are we still talking about this in 2018. Sigh.)

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

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

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

The WHATWG living standard is largely where browser vendors (and other interested parties) work out what the web will be. W3C (with their implementation requirement), and, as you note, MDN serve to describe what the Web is. The latter is more useful to developers, but, as you suggest, MDN is doing a better job of it.

OTOH, to get to a place where things have interoperable implementations, a forum for implementors to collaborate on forward-lookong specifications is necessary, and that’s what WHATWG does well, and W3C does not (which is why WHATWG exists.)

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

#206

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?

Interesting discussions from a year ago: https://www.reddit.com/r/javascript/comments/5swe9b/what_is_...

The W3C is very well funded and they don't wanna see the money gone.

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

#207

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.

A number of folks involved in WHATWG work bought into the XML vision initially, but reality has a strong text/html bias and we've been able to adjust views as experience has accimulated.

See https://annevankesteren.nl/2011/02/xml-tired

(Personally, the first time I managed to get funding to work on a Web engine was to make Gecko's XHTML-as-XML support better. At the time, I thought it was so important that I sought funding to get it done...)

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

#208
post #203

Earlier quoted context omitted.

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

What do you mean by non-HTTP? It handles URLs whose scheme is not http(s): just fine...

I forget the specifics, but there are several incompatibilities between the IETF URI and IRI spec and the WHATWG URL spec (see [1], EDIT: as I'm sure you're well aware, given your username). The WHATWG spec amounts to "what four popular web browsers do", explicitly without considering compatibility with the hundreds (thousands?) of other non-web-browser tools that make use of URIs.

What you've defined are effectively not URLs. Very similar, but different. If you wanted to call them "WHATWGRLs" or something I wouldn't care. But they're not URLs, and the WHATWG is choosing to muddy the waters rather than, say, specify an optional legacy compatibility layer on top of the IETF spec. It's one thing to say "in addition to IETF URIs, browsers should also accept these malformed URIs, but should not accept these valid but problematic URIs"… it's quite another to say "URIs aren't that anymore, now they're this".

[1] https://daniel.haxx.se/blog/2016/05/11/my-url-isnt-your-url/

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

#209

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 definitely needs to be some curation at least. As an example, CSS: Google came up with Flexbox, Microsoft came up with Grid. Now we have two competing layout methods doing pretty much the same. Yet they are conflicting in the sense that define the same flexibility entity by two different means: flexbox uses CSS property (that by itself conflicts with CSS 2.1 box model) and grid uses fr units for defining the same…

I use both flexbox and grid layout together. They are not comepting, merely completing each other. Grid can do things Flexbox can't do. Flexbox can do things Grid can't do.

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

#210
Surely W3C and WHATWG would periodically branch and freeze a version of living standard? Possibly defining some elements as optional or extensions much like OpenGL or Vulkan? It seems crazy that they proposal introduced changes to what was already established common practice.
Post reply on HN