Live data from Hacker News

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

github.com

271–280 of 386 posts

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

#271
post #56

Earlier quoted context omitted.

That seems to ignore the conventional wisdom that according-to-Hoyle XHTML was a DOA standard because it mandated error handling in ways that no browser implemented and most of the authoring community didn't want. Authors don't write well-formed XML, even today.

> it mandated error handling XHTML 1.0 didn't mandate so-called "draconian error-handling", it just offered it as an optional feature. XHTML 1.1 (which was released but noone used) and XHTML 2 (which was never finished nor released) did mandate it. I wasn't a big fan of that decision, I don't think it would've worked, but XHTML 1.1 was still very usable while ignoring that one requirement; throwing out the baby with…

XHTML, other than Transitional, which nobody should count as "implementing XHTML", is an XML application. It inherits XML's parsing model. Every error is a fatal error.

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

#272
post #238

Earlier quoted context omitted.

the formal complaints of all browser people seem to support the WHATWG

The browser people are the WHATWG. There are no other stakeholders in that.

Not sure exactly what your comment is saying, but at least one reading is that "browsers are the only stakeholders in the WHATWG", which is not accurate. The WHATWG is a community organization open to participation by all; see https://whatwg.org/faq#process for more. We receive a lot of participation from users, web developers, and other companies.

There is a formal group, the Steering Group, which represents the browsers that implement WHATWG standards, and serves as the point of final appeal if the community doesn't come to a consensus on its own. But this is similar to the W3C appeals track where if all the paying member companies don't come to consensus, they appeal to "The Director" as the ultimate decider. ("The Director" is nominally Tim Berners-Lee, but recently all Director decisions have been made by W3C management "on behalf of" The Director.)

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

#273

Earlier quoted context omitted.

Thanks. The TL;DR seems to be that, instead of sticking to documenting what is , the W3C is (either deliberately or through incompetence) trying to push their own "vision" for DOM 4.1 without browser buy-in.

Tldr is that corporations don't want a standards body with any public input so they created their own competing body, strangled w3c, and are now saying w3c is limited to being a rubber stamp for the standards they create.

This isn't accurate; notably, the WHATWG is the standards body that is actually open to public input (see https://whatwg.org/faq#process). Whereas to give input to the W3C, you have to pay membership fees (https://www.w3.org/Consortium/fees; between $2250 and $77K depending on company size for the US). This latter model is commonly referred to as "pay-to-play" standardization.

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

#274
post #269

Earlier quoted context omitted.

Remember that Apple just implemented the Canvas tag. If you implement something good perhaps almost none of the W3C member organisations matter in pushing something.

Can you explain what you mean? According to caniuse[1] it has been supported for a while. [1] https://caniuse.com/#feat=canvas *EDIT I misread the parent. I didn't put the context for that paragraph together and read 'just' as in 'right now' instead of 'just decided to'.

The canvas tag (and canvas APIs) were first developed/shipped by Apple in tiger (so more than a decade ago) so yes, it has existed for quite a while :)

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

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

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

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

Plugging my XML Prague 2017 paper on a SGML DTD for W3C HTML 5.1 here [1].

[1]: http://sgmljs.net/blog/blog1701.html

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

#276

Earlier quoted context omitted.

Why cant people just use an older copy of the WHATWG standard as the new "stable" documentation? This is basically how caniuse.com and browserslist work today, allowing developers to precisely describe their compatibility targets and even automate their builds. It seems unnecessary to have an entirely separate organization to just copy/paste/publish new "versions" of existing archives.

> Why cant people just use an older copy of the WHATWG standard as the new "stable" documentation? Because the order of incorporation into the standard and the order of implementation and stabilization aren't the same, and some fesutres may be implemented incompletely in some browsers, so that what is stable and usable is a subset of features (and sometimes a subset of functionality within a particular feature) that…

The WHATWG is actually the only organization I know of that publishers a developer-focused specification; see https://html.spec.whatwg.org/dev/. (We only do it for HTML currently.)

Anyway, I agree with the grandparent poster that caniuse.com is a much better approach to documenting the interoperable subset than copying and pasting someone else's spec, and trying to delete the parts that are not interoperable by some threshold. We actually have caniuse.com boxes in the margin of the HTML Standard: see for example https://html.spec.whatwg.org/multipage/scripting.html#attr-s...

Finally, it's worth noting that we only incorporate features into WHATWG Living Standards if they have multiple implementer interest; see https://whatwg.org/working-mode#additions

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

#277

Earlier quoted context omitted.

font still works. isindex does not. It's extremely rare for a cross-browser HTML element to get removed but isindex is one of those.

blink also doesn’t work anymore, and neither does marquee. Several of the frame attributes are broken as well. noscript doesn’t always work reliably depending on browser.

Marquee works for me in Gecko and Blink. Didn't test the other two engines.

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

#278
post #72

Earlier quoted context omitted.

No. They could matter, if they built a browser with competing market share. It's not a static equilibrium.

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 (https://www.w3.org/Consortium/fees?countryCode=US&quarter=04...) for participation.

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

#279

Earlier quoted context omitted.

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

I agree with everything you said. What rubs me the wrong way about the WHATWG is that they give the perception (and it may be just that) that they are trying not just to serve as that forum for browser makers, but also as the standard reference for web developers (which is the role the W3C HTML specs, save XHTML 2, have historically served), and doing a poor job of the latter.

I don't think the WHATWG is trying to serve as the reference for web developers (though their HTML spec has notable and laudable features for that use); I think they are mostly fine with W3C trying to do that as long as they do it correctly (which requires alignment with what browsers do, otherwise developers will target a non-existent platform.)

I don't know if they (or developers, MDN is probably a more widely used reference than W3C) see a standards body as essential in that role, though, and I don't think it seems W3C really wants to accept being relegated to that role rather than driving the web platform, even though they haven't driven the platform for a long time.

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

#280

Earlier quoted context omitted.

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

I agree with everything you said. What rubs me the wrong way about the WHATWG is that they give the perception (and it may be just that) that they are trying not just to serve as that forum for browser makers, but also as the standard reference for web developers (which is the role the W3C HTML specs, save XHTML 2, have historically served), and doing a poor job of the latter.

Exactly what is the purpose of a standard reference for web developers that fails to track the documented behavior of browsers?
Post reply on HN