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…
Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec
271–280 of 386 posts
Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec
#272Earlier 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.
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
#273Earlier 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.
Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec
#274Earlier 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'.
Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec
#275Earlier 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.
Plugging my XML Prague 2017 paper on a SGML DTD for W3C HTML 5.1 here [1].
Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec
#276Earlier 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…
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
#277Earlier 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.
Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec
#278Earlier 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.
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
#279Earlier 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 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
#280Earlier 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.