Live data from Hacker News

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

github.com

181–190 of 386 posts

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

#181
post #96

Earlier quoted context omitted.

> The WHATWG has always opposed the W3C's spec. They see it as confusing to have two "official" specifications. The WHATWG has not always opposed the W3C's spec. The WHATWG explicitly agreed to work with the W3C to form an edited, snapshot spec based on the WHATWG spec. That's what HTML5 was supposed to be. However, the W3C process then hijacked this, by dropping things from the WHATWG spec, adding things back that h…

> W3C process then hijacked this While I agree the W3C's insistence on maintaining a parallel spec. is a silly idea they should absolutely abandon, I fail to see how any but the most biased perspective could conclude that they are "hijacking" a process of their own. W3C haven't dropped anything from the WHATWG spec.: that's separate and out of their control. They can drop what they like from their copy, it's their co…

Because there's no point in reconciling the specs if you don't actually reconcile them.

If the W3C spec is a snapshot, possibly of a subset, possibly with some editorial but not functional changes, then reconciling the specs is useful; it gives you want the W3C wants to provide, versioned, frozen specifications that can be used as the basis for other specs, for people to claim "full conformance" with a particular version, and so on.

Or, if the W3C process identifies real issues, then it should work with the WHATWG community to resolve those issues; since the WHATWG spec is being used as the upstream, evolving spec that these snapshots are being made from, it makes the most sense to get the changes into the upstream first, so you don't have to resolve the issues every time or maintain divergence forever.

However, the W3C instead just insisted on writing the spec the way it wanted, without regards to whether it would actually be implemented.

It makes no sense to publish a spec that will never be implemented by any of the projects that actually have real-world implementations, and differs from the spec that the implementers actually use. That just causes confusion.

So yes, they hijacked the process in the sense that the WHATWG agreed to work together with the W3C, but the W3C never really worked in good faith to resolve differences or provide technical arguments for their changes.

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

#182

Earlier quoted context omitted.

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.

I never said it would be worse than flash, but is that really the level we are holding ourselves to?

Flash was awful, an accessibility nightmare, a security nightmare, was/is not supported on many platforms/devices, and was horrible on battery life. I think we can absolutely do much much better than flash, but the answer is not to throw out the entire DOM and all of it's benefits and start over, the answer is to fix the problems that are easily fixable and settle on a good set of standards that we can have the option of ignoring for performance reasons in specific domains like games.

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

#183

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 was about to say no, but then I clicked the link and the first entry I saw is an organisation I happen to know (Access-for-All, Swiss Foundation), a foundation dealing with accessible technologies. They're doing a lot of good work with educating developers here in Switzerland.

There are lots of smart people doing important work that are also on the W3C, but that doesn't make them truly influential in de facto web standards.

From what I've read (which is not that much), the relationship between accessibility advocates and web standards has been particularly fraught, with advocates pushing for standards features that are received poorly in the marketplace. The argument here being: not every good idea about HTML is best expressed as a fundamental part of the HTML standard.

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

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

Why don't the browser companies just entirely ignore the W3C from now on?

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

#185
post #42

Earlier quoted context omitted.

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.

The $100 is for someone writing a fully-working parser that handles real-world HTML5 pages, without reusing any existing implementations.

Building an entire new parser is (obviously) much easier for strict languages (e.g. JSON) than for lenient languages (e.g. HTML5).

Which is the problem I have with HTML5, JS, and many similar technologies – they’re so lenient that almost everything is broken instead. We might as well write websites in english prose, it wouldn’t be much harder to parse.

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

#186

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?

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

There is a potential legitimate role for the two-track approach, if WHATWG represents a moving target of what browser vendors have agreed to implement and essentially is the vehicle for documenting hmthe agreed future common web platform, and W3C presents a versioned publication of the stable, widely implemented, currently usable state at a particular point of time; the W3C version would then be the target for conservative app developers that need something that works everywhere today, the WHATWG standard would be what people making browsers and other user agents would target, and what more ambitious developers willing to deal with “can I use...?” pitfalls would be guided by.

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

#187
post #18

Earlier quoted context omitted.

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

And wouldn’t it have been easier to write it without any of the leniency it has to expose? Wouldn’t it have been easier if all tags were either ending in /> or followed by a closing tag? Wouldn’t it have been easier if the syntax was formally defined as ABNF, and could be translated into code in a matter of days?

I believe it would have been. And I believe that making the web easier machine readable, and making it easier for people to develop tools working with the web, would be a valuable goal.

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

#188
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

No, it didn't.

At best a large share of new, greenfield development moved to XHTML, but I'm not convinced it was a majority of even that.

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

#189

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 flexibility concept - portion of free space left in container from other fixed elements in it.

Problem is that all browser from now on shall follow this mess.

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

#190

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 )

> Honestly, do the other 450+ W3C member organizations matter? ( https://www.w3.org/Consortium/Member/List ) Given that the W3C charter requires actual implementations in order for a standard to move forward, I'd have to say that no - entities other than those who might produce a significant implementation probably don't matter in this case.

The W3C Process considers all implementations equivalent: if you were to implement DOM 4.1 in Python, that would be as significant as a browser implementing it. That said, each group has to define what they'll consider "sufficient implementation experience" for each spec when they publish a Candidate Recommendation: the DOM 4.1 spec does not do this, and this forms part of Apple, Google and Mozilla's objections to the spec advancing to CR.

The DOM 4 implementation report, http://w3c.github.io/test-results/dom/details.html, is based on the tests in web-platform-tests: however, the web-platform-tests policy is that we test what browsers implement, and hence the DOM tests there are based on the WHATWG spec: there's no evidence provided that anyone has implemented what the W3C spec says in any case where it differs.

Post reply on HN