Live data from Hacker News

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

github.com

191–200 of 386 posts

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

#191

Earlier quoted context omitted.

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

What features? If you're referring to "features" in the HTML5 spec., like canvas, webgl, geolocation, DOM etc. they were separate specs, which WHATWG lumped into one monolith (though they're mainly JavaScript APIs, and aren't directly related to HTML). They were being worked on separately to XHTML, and still work fine with XHTML to this day.

>they were separate specs, which WHATWG lumped into one monolith

For which I could not care less. Whether there's a big spec for HTML5+JS APIs, or 20 different specs, is a bureaucratic concern, not a concern to the developers or the end users.

W3C might had them "neatly" separated, by it also haven't moved them notch towards completion and release for more than a decade.

I've used and worked for the web before W3C, in its heyday, in its long decline days when we waiting a decade+ for some progress, and after it become irrelevant. Now it's a way better situation.

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

#192
post #94

Earlier quoted context omitted.

The lineage of the rendering engine doesn't matter. What gives Apple and Google and Microsoft command of the standard is the fact that they mediate access to web pages; they own th actual customers. That's what matters.

Nonsense. Web standards are supposed to be de jure, not de facto. Once upon a time Microsoft had 90% of the browser’s market. We created web standards in order to prevent monopolies, such as the former IExplorer, from holding the market hostage. That’s the whole reason behind web standards . And yes, they matter even with an IExplorer that has 90% market share, because governments can and do enforce adherence. That’s…

It doesn't matter what is suppose to happen. In reality. If none of the popular browsers support the standard - it doesn't matter.

Governments are not going to force every major browser manufacturer to support a standard.

That's why W3C lost relevance.

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

#193

I'm not too knowledgeable on the background here, or on how the politics of standards organizations work, but my understanding is that the EU standards bodies (presumably as well as similar organizations for other governments) consider the W3C to be authoritative. Even if all the browsers prefer WHATWG's spec, won't they be forced to adopt W3C in the same way phones have to support USB charging[0]? [0] https://en.wik…

I'm rather unfamiliar with the history of EPS, but its success seems to have been predicated on the preexisting willingness of a majority of mobile phone manufacturers to adopt it. On the other hand, as far as I'm aware, no major browser supplier currently supports publishing or implementing DOM 4.1, thus providing no pressure on the other browser developers to do so. The EU standards bodies' opinion regarding the authoritative standard seems somewhat irrelevant given this situation - attempted enforcement of a DOM implementation with such little support via legislative means is unlikely and infeasible.

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

#194
post #147

Earlier quoted context omitted.

Firefox doesn't own the customer. But creating a rendering engine from scratch is hard and there is no business case for anyone doing it from scratch. Apple didn't (they tried with CyberDog ages ago) they used KHTML to create WebKit. Google didn't either, they started with WebKit. Opera gave up on their own rendering engine years ago.

Why is "creating a rendering engine from scratch" the bar here? A new player could fork Blink or WebKit.

If you fork an existing rendering engine, you're rather implicitly using a WHATWG DOM. In order to use W3C DOM 4.1, you'd either have to modify a WHATWG DOM renderer into a W3C DOM 4.1 renderer -- which is a bit like starting with the emacs source to build a vim clone -- or to build your own. The inertia of forking an existing project pushes you towards the WHATWG implementation, not W3C. That's the point of forking. You get to preserve the forking.

Further, the W3C's argument historically has been to make the DOM easier to implement from the ground up (XHTML strict) compared to the overall rats nest of HTML5, which, as far as I'm aware, still is not fully supported anywhere [1] and is very loose about document structure errors etc. So, if you're planning to implement the W3C's DOM, it makes sense that you're agreeing at least somewhat with the W3C's historical philosophy about what the web should look like and how it should behave, so you're more likely to be concerned about the implementation difficulty of HTML5.

1: https://html5test.com/results/desktop.html

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

#195
post #159
post #131

Earlier quoted context omitted.

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

Not if that You can apply mandatory quoting to untrusted input all you want, but there are going to be times when you have trusted strings that can still contain stray characters that will make the resulting markup invalid. And in many cases you don't want to have mandatory quoting for all of that, because these strings may have markup you want to include.

And yeah, you can argue that instead of generating content by appending strings, you should be building up a proper type-safe DOM structure that can be serialized. I'll wait while you go boil the ocean of converting every single web application framework that exists now outside of a couple of obscure type-safe functional programming frameworks, and in the meantime I'll be able to browse the real web without every other page giving me validation errors.

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

#196

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…

Flexbox and Grid coming from different companies isn't really relevant (and, to note, Flexbox comes from Mozilla originally, if I'm not mistaken, it is ultimately based on parts of XUL).

They're also not competing: flexbox makes many 1D layouts easier than grid does. They're complementary, not conflicting.

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

#197
post #3

That’s a flamey title. They’re objecting to them publishing their spec before the negotiations with WHATWG are over.

If you read the thread there's an exchange with the CEO of W3C that is a touch 'flamey'. I think the title perfectly describes what I was reading, really interesting peek at the machinations behind the tech standards we use every day.

He also gets called out on it, in a rather satisfying manner:

> othermaciej commented 2 days ago • edited 2 days ago > @jeffjaffe As someone who is neither you or @michaelchampion , I read your response to him as dismissive and insulting, and it seems to have stopped @chaals from answering his legitimate question. The tone reads like you are addressing an unruly underling, rather than a key stakeholder. If that was not your intent, you may want to recalibrate your tone.

Perhaps not altogether relevant, but certainly interesting seeing the amount of conflict that's popped up in the discussion.

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

#198
post #85

Earlier quoted context omitted.

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?

In part, I think it's because there is still good work that goes on under the W3C umbrella in other areas; the CSS working group has managed to stay reasonable, learn from the mistakes of some over-engineered past standards, and continues to work with implementers.

Also, there are reasons to want some of what the W3C provides that the WHATWG doesn't. The W3C has many more member companies, and it can get them to sign off on patent rights so there's less likelihood of some one of Adobe's patents on page layout in InDesign suddenly being infringed by web browsers due to something in the spec.

And finally, I think that the W3C wants to stay relevant and so it keeps on trying to work from a basis on the WHATWG spec, and promising it will be good this time, and then it goes off and pulls this stuff again.

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

#199
post #121

Earlier quoted context omitted.

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

MDN includes clear documentation about what is actually implemented in all major browsers (the compatibility tables), so I (as someone who wants my code to work everywhere now , not next year ) can tell at a glance what pie-in-the-sky ideas I should ignore. That's great that it's based on the WHATWG's work – it should be, since it should document what's in Firefox, and Firefox presumably is following their own work w…

FWIW, the HTML Standard (not the DOM Standard) does include CanIUse information in a sidebar, to help with this. I'd like to include this into other WHATWG standards, but it hasn't really happened yet. I'd expect most web developers to use MDN and StackOverflow though, as you say.

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

#200

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?

Some history here: - https://en.wikipedia.org/wiki/WHATWG#History - https://annevankesteren.nl/2011/02/html-development - https://annevankesteren.nl/2016/01/film-at-11 - https://thehistoryoftheweb.com/when-standards-divide/ Differences between the W3C HTML 5.2 spec and the WHATWG Living Spec: https://www.w3.org/wiki/HTML/W3C-WHATWG-Differences

> Differences between the W3C HTML 5.2 spec and the WHATWG Living Spec: https://www.w3.org/wiki/HTML/W3C-WHATWG-Differences

FWIW, I'm pretty certain that is incomplete. It may well be the case that that is the set of deliberate changes from the WHATWG spec (at some revision), but we've had cases before where changes from the WHATWG spec have been copied only partially leading to the W3C spec, as published as a Recommendation (i.e., with two interoperable implementations) has been impossible to implement as written.

Post reply on HN