Live data from Hacker News

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

github.com

351–360 of 386 posts

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

#351

Earlier quoted context omitted.

> The WHATWG doc is a fine standard, backed up by real implementation. It sucks badly. To begin with, it can't be called a proper standard. It is in their terminology "a living standard" which means it being changed on a whim. It is not being written as an "ideal prototype", but rather it is just a codification of current behaviour of how Google's devs managed to write Chrome's DOM Api, with with all bugs and workaro…

Ok, so why does it suck? Because you don't like it? Why isn't it a proper standard when it's the only one implemented? Things definitely do not change on a whim and there's great care taken in the process. The group is very transparent and clearly state the objective is to keep the standard modern and evolving. You can always refer to an archived snapshot or the numerous compatibility tables for historic data if need…

How it should work:

A standard is written and set in stone at least for 1-1.5 years. Official test suites are made.

Then, browsermakers make their stuff compliant.

APIs must support strict versioning. A user should not be bothered with "your browsers supports version 1 of method b, version 2 of method c, and does not support method d" it should either work with API version N or popup a big error message "API version N not supported, update your browser"

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

#352

Earlier quoted context omitted.

Users should have a voice too.

We definitely believe users should have a voice in the WHATWG, and thus in guiding what browsers implement. We strive to maintain an open and welcoming community; this has brought a lot of good ideas to the table. A few years ago I gave a talk on this. https://www.youtube.com/watch?v=hneN6aW-d9w . I hope it's not too embarassingly outdated now :) In particular, unlike the W3C, we do not require membership fees ( http…

Right, that's my point :) But thanks for making it clear for those reading.

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

#353

Earlier quoted context omitted.

Are there any non-browser members as part of the editors or steering committee in the whatwg? To me, this is giving browser makers even more power over HTML than they have otherwise.

The MIME Sniffing, Streams, Console, and Quirks Mode Standards are all edited by people who are not working for the browser-engine-developer companies. (Streams is co-edited by Googlers as well.) That's 4 out of the 15 standards currently developed at the WHATWG; not so bad, given how few companies are willing to pay people to work full time on web standards. Of course, we have lots of work to do, and if you or anyon…

> That's 4 out of the 15 standards currently developed at the WHATWG; not so bad, given how few companies are willing to pay people to work full time on web standards.

Thats actually nice to know, but specifically about HTML (which is one of the most important specs the whatwg works on) it's all browser makers. (That too, majority of them from one particular browser maker).

>I think this is probably the right way to go, instead of "The Director" having the final voice.

I think having a better mix of people in the decision making process than just browser makers would be the right way to go. I understand that browser makers have to implement the specs, but the web community as a whole has to use the specs to build the web of the future - and as such, people from non-browser companies should have a greater say in the final voice.

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

#354
post #310

Earlier quoted context omitted.

> The W3C actually does do some good work in other working groups; the CSS working groups seem to be working smoothly. The W3C is also doing work in HTML at least too. If browser makers would actually participate as editors (like they do in CSS) then it would work just as well as the CSS working groups and others.

What good work is it doing in HTML? In HTML, as far as I can tell, it appears to be copying features from the WHATWG standard, paraphrasing them, and including them in their standard, with only a small notice on the acknowledgements page the the HTML standard contains parts derived from the WHATWG standard. The browser makers did participate. They participated in the W3C working groups up until they were shot down wh…

>What good work is it doing in HTML?

From my experience, it has generally done a better job of explaining things developers would want to know, especially in terms of accessibility and internationalisation.

The XHTML stuff was a long time back, and at that time, it warranted having a whatwg. Now that W3C is no longer insisting on XHTML (and hasn't for many years).

>When it was clear that the WHATWG standard was the one that actually mattered because it was what was actually implemented, the W3C invited them back in to start working on the standard together. That's what HTML5 was; the W3C agreed that they would start from the WHATWG standard, that they could have the same editor (Ian Hickson), and they wound down the XHTML 2.0 group.

This is the crux of it. The WHATWG is really usefull for browser vendors because they can do essentially whatever they want in it without anyone having the power to formally object to it (unlike the W3C). Now the whatwg editors (and thus browser makers) can say that they will listen to community feedback, but thats pretty much a benign dictatorship over the most important spec of the web.

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

#355

Earlier quoted context omitted.

> The W3C actually does do some good work in other working groups; the CSS working groups seem to be working smoothly. The W3C is also doing work in HTML at least too. If browser makers would actually participate as editors (like they do in CSS) then it would work just as well as the CSS working groups and others.

> If browser makers would actually participate as editors Microsoft tried that, investing in easier to use GitHub tooling to allow a wide range of people to submit pull requests to update/fix bugs in the W3C HTML standard. "If you build the field of dreams, they will come...." Nope. "They" had all gone to WHATWG ballpark, and all the W3C editors do is cherrypick (that's the actual word in the HTML 5.2 Recommendation)…

>Microsoft tried that, investing in easier to use GitHub tooling to allow a wide range of people to submit pull requests to update/fix bugs in the W3C HTML standard. "If you build the field of dreams, they will come...." Nope. "They" had all gone to WHATWG ballpark, and all the W3C editors do is cherrypick (that's the actual word in the HTML 5.2 Recommendation) WHATWG's specs. It made a LOT more sense to just join WHATWG for HTML (and DOM).

It won't work if only one browser maker will participate. If only microsoft participated and implementing things in the CSS WG then nothing really would get done over there too.

If all the browser makers would have editors in the w3c html spec (like they do in many other w3c specs) and agree to implement stuff there, then that would also work.

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

#356
post #346

Earlier quoted context omitted.

"Flexbox can do things Grid can't do" For example?

flex-wrap. flexbox is one-dimensional, so it can "wrap" items that don't fit to the next line. The wrapped items don't have to line up with vertical grid lines, like they would in a grid, and they can be stretched or centred to fit across the full width of the parent.

How that is different from a sequence of display:inline-block's (horizontal wrap) and multi-col layout (vertical wrap)?

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

#357

Earlier quoted context omitted.

> If browser makers would actually participate as editors Microsoft tried that, investing in easier to use GitHub tooling to allow a wide range of people to submit pull requests to update/fix bugs in the W3C HTML standard. "If you build the field of dreams, they will come...." Nope. "They" had all gone to WHATWG ballpark, and all the W3C editors do is cherrypick (that's the actual word in the HTML 5.2 Recommendation)…

>Microsoft tried that, investing in easier to use GitHub tooling to allow a wide range of people to submit pull requests to update/fix bugs in the W3C HTML standard. "If you build the field of dreams, they will come...." Nope. "They" had all gone to WHATWG ballpark, and all the W3C editors do is cherrypick (that's the actual word in the HTML 5.2 Recommendation) WHATWG's specs. It made a LOT more sense to just join WH…

How would one convince the others to re-invest in W3C HTML and DOM? Microsoft's rationale a few years ago was that WHATWG wasn't a real standards organization with a patent policy, dispute resolution system, etc., and that created various legal and business concerns.

It turned out to be much easier to add a legal framework to WHATWG than to convince the HTML and DOM standards community to move back to W3C. Basically, people work on specs (and code) together in the places where there is a critical mass of expertise and energy being productively engaged. The key variable is the people, not the organization.

I don't understand the dynamics of how these critical masses of expertise coalesce, break up, and move around. I have learned that it's much more efficient to go with the flow than try to redirect it.

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

#358
post #203

Earlier quoted context omitted.

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…

I'm not sure I get the distinction. As for curl, it doesn't follow any standard which seems worse, but does at least helpfully demonstrate that the RFCs cannot be implemented by major clients.

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

#359

Earlier quoted context omitted.

> Leave the business of documenting what browsers actually conform to to the W3C. Documenting the prevailing conditions is very much not the purpose of a standard .

That's what the W3C has historically done, with HTML 2.0, 3.2, and 4.0. "Document, clean up, and nudge" is maybe a better description. The WHATWG today seems to take more of a "document, don't clean up, and add our wishlist" approach. (The "don't clean up" mentality is embodied in their "don't break the web" ethos; the "add our wishlist" mentality is a consequence of the "living standard" ethos… the "standard" never…

I'm not sure where you got this impression, but it's wrong. https://whatwg.org/working-mode stipulates the requirements on additions. That's quite a bit different from a set of wishes.

And there's a lot of cleanup of legacy APIs happening too. E.g., removal of the isindex tag and deprecation of AppCache.

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

#360

Earlier quoted context omitted.

> Leave the business of documenting what browsers actually conform to to the W3C. Documenting the prevailing conditions is very much not the purpose of a standard .

That is the governing philosophy of the WHATWG, sadly.

That's a bit of a stretch. This is only relevant to legacy APIs and only when all implementations are in agreement, which is quite the rarity.
Post reply on HN