9 ms·

My read: A) WHATWG is totally controlled by the browser vendors, which have become even more of a small oligopoly than it seemed they would be 10 years ago. It

My read: A) WHATWG is totally controlled by the browser vendors, which have become even more of a small oligopoly than it seemed they would be 10 years ago. It's basically Apple, Mozilla, Google and Microsoft -- so those four organizations, three of which are enormous corporations, are controlling web standards. (And in practice it seems to mostly just be Google-controlled for whatever reason, but either way). Whereas W3C at least hypothetically was accountable to multiple stakeholders. B) The WHATWG "living standard" is not really a standard at all as many engineers understand or would like it.

bawolff 4y ago
The counter to (a) that, is if your standard is beholden to a bunch a stakeholders who aren't actually making the software, you're going to end up with something useless that nobody implements. The biggest difference between whatwg html and earlier w3c html is that people actually implemented whatwg html where w3c standards were more wishful thinking that never got used or implemented (rip xhtml).
- WorldMaker 4y ago
  XHTML 1.x was well implemented in most browsers and was highly used by a subset of web developers. XHTML 1.x also did a lot to help shake out things like "quirks mode" versus "standards mode". HTML 5 imported a lot of things that worked from XHTML 1.x. It's true that XHTML 2.0 was murdered before the spec finished but that was part and parcel of the WHATWG coup. We have no idea what the final product from XHTML 2.0 would have looked like (it certainly didn't look useless, though it aimed for the stars and probably wouldn't have met them) or if it had implemented if it would have been used because the browser implementors had already decided they were going to take charge instead.
  - bawolff 4y ago
    > it certainly didn't look useless, though it aimed for the stars and probably wouldn't have met them That one sentence pretty much sums up why w3c is a bad standards body. A standards body is not a research group. If you are aiming for the stars you are doing it wrong. A standards body is supposed to be doing the boring work of formalizing what is known to work well, not try and invent new untested things.
    - WorldMaker 4y ago
      I think there is a large spectrum of standards bodies and working to productize outside research and aspirations is a part of some good standards bodies. Not a lot of people are calling WHATWG a bad standards body, but it is even worse at taking stuff directly out of Blink research and labeling it a draft standard with only a single implementation with sometimes seemingly very little study into its safety or long-term viability. I suppose there is a small distinction between Ivory Tower academic aspirations and research versus Walled Garden corporate aspirations and research, but at the end of the day it certainly feels the same, and I have more reasons, myself, to admire the academic aspirations that aren't tied to corporate interests and profit motives, but I can understand why some feel what Google and WHATWG is doing is better for the web because they start with that first "implementation" of their research instead of a chalkboard and a hope for a better web.
    - willseth 4y ago
      In order for a standards body to be successful, it must be possible to attempt standards and fail them before they leave the standards body. Otherwise they would lose credibility by publishing recommendations that won't get wide acceptance. XHTML2 is an example of a W3C WG exercising restraint. That is a good thing. You seem to think standards should only be built in reverse, which is essentially the WHATWG philosophy: Browser vendors implement something they think is useful, then try to negotiate to get it standardized. That's not bad per se, but it's limited and it's a different system of accountability.
  - goto11 4y ago
    XHTML 2.0 was not backwards compatible with HTML and was therefore doomed from the start. It would never have succeeded.
    - WorldMaker 4y ago
      As I recall even in draft standards you could mix XHTML 1.0 namespaces and XHTML 2.0 namespaces to use "backwards compatible markup" where you needed to. It wasn't pretty as most things involving XML and lots of mixed namespaces isn't, but it was possible. We still don't know if it would have gotten more backwards compatible had browsers tried to actually implement it.
  - bentley 4y ago
    > XHTML 1.x was well implemented in most browsers and was highly used by a subset of web developers. Well, the XML part wasn’t. Serve your XHTML as text/html and it was “supported” by virtue of being treated like HTML with some minor syntax errors. Serve your XHTML as application/xhtml+xml, as required to get any XML features, and it wouldn’t display in Internet Explorer at all. XHTML 1.0 was allowed to be served with text/html for compatibility reasons, if you were careful to not make it too different from HTML (don’t self‐close an empty <textarea>, for example, and add a space before every “/>”). XHTML 1.1 didn’t allow the text/html MIME type at all, and so basically nobody used it. That’s not even getting into XML’s unpopularly draconic error handling for pages that did get served as XML…
    - WorldMaker 4y ago
      I recall I had XHTML 1.x Strict served as XML working in Internet Explorer (that would have been my primary testing/dev browser at the time, even). It was certainly no cakewalk, but it was briefly possible. As I recall it the XML mime types stopped working again shortly after HTML 5 became the headwind.
- willseth 4y ago
  Great argument for zero accountability to users and everyone else impacted by decisions of browser vendors. You don't seem to be aware that the W3C has been chugging along, publishing real web standards that do get implemented, for years - or the actual roles of W3C and WHATWG in the standards process - so just stop. (Also FYI https://caniuse.com/?search=xhtml https://caniuse.com/?search=xhtml)
  - bawolff 4y ago
    > You don't seem to be aware that the W3C has been chugging along, publishing real web standards Including most recently standards that are basically a way to give a thin veneer of respectability to crypto shit (e.g. DID) To be clear, i am not saying everything w3c does is totally devoid of value. They have done useful work. But its still an org that generally makes bad standards that are rarely followed. The recent bitcoin stuff is shit and basically not a standard. The historical standards are also often terrible, especially when you step away from html (you can't possibly read XMLSignature and think any of it is a remotely good idea). As an org, its riding almost entirely on the coat tails of HTML, and now that that is gone, what is the point? > zero accountability to users Has w3c ever done anything at all that actually helped users over browser vendors? Things like P3P that aren't implemented don't count.
    - willseth 4y ago
      [flagged]
no_wizard 4y ago
Two use Blink, which is a fork of Webkit (Google owned. Microsoft uses its own forked version for Microsoft Edge since Edge Version 79). Apple uses Webkit proper, and Mozilla is Gecko driven.
- rascul 4y ago
  I find it interesting that KDE is the original creators of the most used browser engine today.
  - account42 4y ago
    The power of open source. Next you will discover how widespread software is that was primarily written by individuals like Jean-loup Gailly, Mark Adler, Daniel Stenberg or Dwayne Richard Hipp.
JoshTriplett 4y ago
> B) The WHATWG "living standard" is not really a standard at all as many engineers understand or would like it. I've found it incredibly useful. For the first time, someone actually wrote down all the details of how to do real-world HTML parsing, rather than having that knowledge all embedded in web browsers. WHATWG specifies how HTML actually works. You can follow the WHATWG standard and actually implement a web browser, or an HTML parser.
- rhdunn 4y ago
  The key issue is the "Living Standard" part, not the technical details of the specification. Practically, it means that an implementor needs to record the date at which they implemented a given piece of functionality. It means that: 1. different implementors (e.g. the various HTML parsers in Java, C#, etc.) can be on different revisions, so can have subtly different behaviour while being conformant to those versions of the spec; 2. an implementor that implements a given algorithm/behaviour in the spec can have the details of that change -- therefore, they need to follow all commits to the spec in order to figure out what has changed; 3. references to the spec (numbered headings -- e.g. "5. parsing", and URIs) can change when content gets moved, merged, renamed, making other specs that reference those easily outdated. Having numbered specifications makes it easier to tell what is in that version and what has changed between the versions. Imagine writing a Java, C#, etc. application to a Living Standard. It would quickly become unmanageable as libraries would be using different features from different revisions.
  - JoshTriplett 4y ago
    I personally think the web should have used a more solid standard from day 1. If something like strictly validated XHTML had been the very first thing shipped on the web, and anything that didn't validate wouldn't display, we'd have had a very different web. But given the web we have, I think we need to document it. > It would quickly become unmanageable as libraries would be using different features from different revisions. As far as I know, HTML5 is generally forward-compatible. Once something has actually shipped in the standard, there's a question of "how new of a browser do you need to use this", but not "how old".

bawolff 4y ago

The counter to (a) that, is if your standard is beholden to a bunch a stakeholders who aren't actually making the software, you're going to end up with something useless that nobody implements. The biggest difference between whatwg html and earlier w3c html is that people actually implemented whatwg html where w3c standards were more wishful thinking that never got used or implemented (rip xhtml).

WorldMaker 4y ago
XHTML 1.x was well implemented in most browsers and was highly used by a subset of web developers. XHTML 1.x also did a lot to help shake out things like "quirks mode" versus "standards mode". HTML 5 imported a lot of things that worked from XHTML 1.x. It's true that XHTML 2.0 was murdered before the spec finished but that was part and parcel of the WHATWG coup. We have no idea what the final product from XHTML 2.0 would have looked like (it certainly didn't look useless, though it aimed for the stars and probably wouldn't have met them) or if it had implemented if it would have been used because the browser implementors had already decided they were going to take charge instead.
- bawolff 4y ago
  > it certainly didn't look useless, though it aimed for the stars and probably wouldn't have met them That one sentence pretty much sums up why w3c is a bad standards body. A standards body is not a research group. If you are aiming for the stars you are doing it wrong. A standards body is supposed to be doing the boring work of formalizing what is known to work well, not try and invent new untested things.
  - WorldMaker 4y ago
    I think there is a large spectrum of standards bodies and working to productize outside research and aspirations is a part of some good standards bodies. Not a lot of people are calling WHATWG a bad standards body, but it is even worse at taking stuff directly out of Blink research and labeling it a draft standard with only a single implementation with sometimes seemingly very little study into its safety or long-term viability. I suppose there is a small distinction between Ivory Tower academic aspirations and research versus Walled Garden corporate aspirations and research, but at the end of the day it certainly feels the same, and I have more reasons, myself, to admire the academic aspirations that aren't tied to corporate interests and profit motives, but I can understand why some feel what Google and WHATWG is doing is better for the web because they start with that first "implementation" of their research instead of a chalkboard and a hope for a better web.
  - willseth 4y ago
    In order for a standards body to be successful, it must be possible to attempt standards and fail them before they leave the standards body. Otherwise they would lose credibility by publishing recommendations that won't get wide acceptance. XHTML2 is an example of a W3C WG exercising restraint. That is a good thing. You seem to think standards should only be built in reverse, which is essentially the WHATWG philosophy: Browser vendors implement something they think is useful, then try to negotiate to get it standardized. That's not bad per se, but it's limited and it's a different system of accountability.
- goto11 4y ago
  XHTML 2.0 was not backwards compatible with HTML and was therefore doomed from the start. It would never have succeeded.
  - WorldMaker 4y ago
    As I recall even in draft standards you could mix XHTML 1.0 namespaces and XHTML 2.0 namespaces to use "backwards compatible markup" where you needed to. It wasn't pretty as most things involving XML and lots of mixed namespaces isn't, but it was possible. We still don't know if it would have gotten more backwards compatible had browsers tried to actually implement it.
- bentley 4y ago
  > XHTML 1.x was well implemented in most browsers and was highly used by a subset of web developers. Well, the XML part wasn’t. Serve your XHTML as text/html and it was “supported” by virtue of being treated like HTML with some minor syntax errors. Serve your XHTML as application/xhtml+xml, as required to get any XML features, and it wouldn’t display in Internet Explorer at all. XHTML 1.0 was allowed to be served with text/html for compatibility reasons, if you were careful to not make it too different from HTML (don’t self‐close an empty <textarea>, for example, and add a space before every “/>”). XHTML 1.1 didn’t allow the text/html MIME type at all, and so basically nobody used it. That’s not even getting into XML’s unpopularly draconic error handling for pages that did get served as XML…
  - WorldMaker 4y ago
    I recall I had XHTML 1.x Strict served as XML working in Internet Explorer (that would have been my primary testing/dev browser at the time, even). It was certainly no cakewalk, but it was briefly possible. As I recall it the XML mime types stopped working again shortly after HTML 5 became the headwind.
willseth 4y ago
Great argument for zero accountability to users and everyone else impacted by decisions of browser vendors. You don't seem to be aware that the W3C has been chugging along, publishing real web standards that do get implemented, for years - or the actual roles of W3C and WHATWG in the standards process - so just stop. (Also FYI https://caniuse.com/?search=xhtml https://caniuse.com/?search=xhtml)
- bawolff 4y ago
  > You don't seem to be aware that the W3C has been chugging along, publishing real web standards Including most recently standards that are basically a way to give a thin veneer of respectability to crypto shit (e.g. DID) To be clear, i am not saying everything w3c does is totally devoid of value. They have done useful work. But its still an org that generally makes bad standards that are rarely followed. The recent bitcoin stuff is shit and basically not a standard. The historical standards are also often terrible, especially when you step away from html (you can't possibly read XMLSignature and think any of it is a remotely good idea). As an org, its riding almost entirely on the coat tails of HTML, and now that that is gone, what is the point? > zero accountability to users Has w3c ever done anything at all that actually helped users over browser vendors? Things like P3P that aren't implemented don't count.
  - willseth 4y ago
    [flagged]

no_wizard 4y ago

Two use Blink, which is a fork of Webkit (Google owned. Microsoft uses its own forked version for Microsoft Edge since Edge Version 79). Apple uses Webkit proper, and Mozilla is Gecko driven.

rascul 4y ago
I find it interesting that KDE is the original creators of the most used browser engine today.
- account42 4y ago
  The power of open source. Next you will discover how widespread software is that was primarily written by individuals like Jean-loup Gailly, Mark Adler, Daniel Stenberg or Dwayne Richard Hipp.

JoshTriplett 4y ago

> B) The WHATWG "living standard" is not really a standard at all as many engineers understand or would like it. I've found it incredibly useful. For the first time, someone actually wrote down all the details of how to do real-world HTML parsing, rather than having that knowledge all embedded in web browsers. WHATWG specifies how HTML actually works. You can follow the WHATWG standard and actually implement a web browser, or an HTML parser.

rhdunn 4y ago
The key issue is the "Living Standard" part, not the technical details of the specification. Practically, it means that an implementor needs to record the date at which they implemented a given piece of functionality. It means that: 1. different implementors (e.g. the various HTML parsers in Java, C#, etc.) can be on different revisions, so can have subtly different behaviour while being conformant to those versions of the spec; 2. an implementor that implements a given algorithm/behaviour in the spec can have the details of that change -- therefore, they need to follow all commits to the spec in order to figure out what has changed; 3. references to the spec (numbered headings -- e.g. "5. parsing", and URIs) can change when content gets moved, merged, renamed, making other specs that reference those easily outdated. Having numbered specifications makes it easier to tell what is in that version and what has changed between the versions. Imagine writing a Java, C#, etc. application to a Living Standard. It would quickly become unmanageable as libraries would be using different features from different revisions.
- JoshTriplett 4y ago
  I personally think the web should have used a more solid standard from day 1. If something like strictly validated XHTML had been the very first thing shipped on the web, and anything that didn't validate wouldn't display, we'd have had a very different web. But given the web we have, I think we need to document it. > It would quickly become unmanageable as libraries would be using different features from different revisions. As far as I know, HTML5 is generally forward-compatible. Once something has actually shipped in the standard, there's a question of "how new of a browser do you need to use this", but not "how old".