4 ms·

> Unfortunately I'm not aware of any other organization working on a widely accepted list of web standards. Maybe I'm misunderstanding, but the HTML 5 spec is

> Unfortunately I'm not aware of any other organization working on a widely accepted list of web standards. Maybe I'm misunderstanding, but the HTML 5 spec is entirely the work of Ian Hickson/WHATWG (financed by Google), and has been for over ten years. Until about 2018 W3C has merely snapshotted, rubberstamped, and editorialized WHATWG's specs, and has since stopped doing even that, and now W3C's HTML5.2 spec has a banner retroactively redirecting you to WHATWG's current head [1]. W3C is involved via the CSS WG and ARIA still. But yeah, as a standardization body, W3C has failed spectacularly. There's no standard as such; WHATWG's "living standard" is merely a stagnant (yet still unversioned) memorandum of understanding of extant browser vendors (Google Chrome and Google-financed Mozilla plus Safari) to implement features, with a large part of browser APIs not implemented by FF and Safari due to fingerprinting concerns. [1]: https://www.w3.org/TR/2017/REC-html52-20171214/ https://www.w3.org/TR/2017/REC-html52-20171214/

echelon 4y ago
Alternate interpretation: w3c's XHTML was machine understandable. It took great care to introduce rigid and reusable semantics. You could spider the web and directly extract facts without ML or heuristics. It spiritually brought HTML closer to RSS and RDF, and there would have been a lot you could do with that. Google didn't want anything to do with that future. Search is their moat. They pushed a format that is easy for humans to author, tolerably messy, and knowledgeless for machines. If the format was difficult to extract knowledge from in a scalable and reusable way, Google could keep their search kingdom. XHTML was a ladder rung into the semantic web. A distributed knowledge graph that could be mined, remixed, and extended with little effort. It was marginally harder to author (the mimetype issue was ridiculous), but extending it was low hanging fruit. This isn't necessarily how it went down, but the incentives do align. I do think we'd have more automation in the world today if we'd have adopted XHTML. Now with AI/ML and NLP I think we'll get to this kind of web without a format to rigidly specify semantics. I still have to think that the ideas of semantic web and P2P could have delivered decades ago if Google and Facebook hadn't overwhelmingly pushed the envelope on centralized resources.
- zozbot234 4y ago
  HTML5 can be auto-translated into an XML surface syntax. You aren't losing anything compared to the old XHTML, though only the XML syntax can include content from other XML namespaces. Google even cooperates with other search engines in promoting unified formats to "extract knowledge from in a scalable and reusable way", namely the schema.org standards.
  - echelon 4y ago
    XHTML treated schemas as a first class order of business, though. It would require people to use extra effort to author a table of "address information" (or whatever). Maybe that would not have happened, but the format also suggested the building of reusable components, browser integrations for semantic understanding, and much more. The world it alluded to was much brighter for machine understanding and reusability.
    - Devasta 4y ago
      Data served in a tree structure and then rendered with client side templating with the ability to create custom elements... those crazy W3C eggheads in their ivory tower, why did they think anyone would want that? /s
  - schemescape 4y ago
    Is the “can be translated into XML” part of the HTML5 spec? That would be interesting to me, and I wasn’t aware of it until your comment. Edit: sounds like it’s not a thing: > The DOM, the HTML syntax, and the XML syntax cannot all represent the same content. https://html.spec.whatwg.org/multipage/introduction.html#html-vs-xhtml https://html.spec.whatwg.org/multipage/introduction.html#htm...
    - domenicd 4y ago
      The non-translatable features are extremely niche, though. To continue the quote: > For example, namespaces cannot be represented using the HTML syntax, but they are supported in the DOM and in the XML syntax. Similarly, documents that use the noscript feature can be represented using the HTML syntax, but cannot be represented with the DOM or in the XML syntax. Comments that contain the string "-->" can only be represented in the DOM, not in the HTML and XML syntaxes. I.e. the big thing you'd fail to capture when doing an automated HTML -> parsed DOM -> XML trip is noscript tags. No big loss. Others I can remember are similarly tiny, e.g. some issues around textarea elements containing only newlines as their initial contents. Some discussion at https://html.spec.whatwg.org/multipage/parsing.html#parsing https://html.spec.whatwg.org/multipage/parsing.html#parsing Ctrl+F "roundtrip", although note that most of that is actually about what happens if you construct weird DOMs with JS and try to do a DOM -> serialized HTML -> reparsed DOM roundtrip. I think it's pretty safe to say in general that the procedure of "parse HTML to DOM, serialize to XML" will preserve everything interesting about a document. Especially if that document is already valid HTML.
bawolff 4y ago
Even outside of the web stuff, SPARQL standard is really old at this point and seems like it could really use a revision, but nobody seems to be working on it.
- jerven 4y ago
  Rdf-star workgroup has just started and they will update some parts of sparql rdf etc. They are also looking at making it easier to update. I.e. living standards like.
Jasper_ 4y ago
Ian Hickson stepped down a few years ago and has started working on Flutter instead (Flutter started as a "what would a browser look like if we removed a bunch of legacy from the HTML spec" project). It's now maintained by Dominic Denicola, Anne van Kesteren, Tentek Celik, and a few others.
domenicd 4y ago
Let me clarify some things about the WHATWG HTML Standard: The HTML Standard has not been maintained by Ian since 2015. It has since then been maintained by myself, Anne, Simon, and Philip. Affiliations during that time are, respectively: Google, Mozilla then Apple, Bocoup then Mozilla, and Google. (Indeed, mostly only browser companies have been paying people to be editors for web specs!) https://html.spec.whatwg.org/multipage/acknowledgements.html#acknowledgments https://html.spec.whatwg.org/multipage/acknowledgements.html... But the contributor pool is much larger. We're quite proud of the vibrant (not stagnant) community we've created, which is continually evolving and improving the spec. Contributions come from all corners; many are from people employed by browser engine companies, but others include students, web developers, consultancies like Igalia and Bocoup which various companies hire to work on web standards, W3C staff and members, representatives from server-side runtimes like Node and Deno, and so on. Some interesting pages to peruse might be https://github.com/whatwg/html/commits/main https://github.com/whatwg/html/commits/main , https://github.com/whatwg/html/graphs/contributors?type=c https://github.com/whatwg/html/graphs/contributors?type=c , and https://blog.whatwg.org/ https://blog.whatwg.org/ . Overall I think it's pretty exciting you can run a successful standards organization like this, getting such high engagement levels despite employing no full-time staff and with operating costs being entirely server bills. Including, no membership fees. Which is perhaps relevant to the OP. https://twitter.com/Hixie/status/1603917371214729216 https://twitter.com/Hixie/status/1603917371214729216 The WHATWG only includes features in our standards which have multi-implementer commitment: https://whatwg.org/working-mode#additions https://whatwg.org/working-mode#additions . This is different than some places where anyone can publish a "standard", even if the target platforms have no intention of implementing it. I don't think this reduces to "merely a memorandum of understanding"; I think it's best when standards reflect reality. Other SDOs can disagree, and that's fine; it's healthy to have a marketplace. As for the scare quotes around "living standard", you might enjoy https://whatwg.org/faq#living-standard https://whatwg.org/faq#living-standard and the follow-up questions.

echelon 4y ago

Alternate interpretation: w3c's XHTML was machine understandable. It took great care to introduce rigid and reusable semantics. You could spider the web and directly extract facts without ML or heuristics. It spiritually brought HTML closer to RSS and RDF, and there would have been a lot you could do with that. Google didn't want anything to do with that future. Search is their moat. They pushed a format that is easy for humans to author, tolerably messy, and knowledgeless for machines. If the format was difficult to extract knowledge from in a scalable and reusable way, Google could keep their search kingdom. XHTML was a ladder rung into the semantic web. A distributed knowledge graph that could be mined, remixed, and extended with little effort. It was marginally harder to author (the mimetype issue was ridiculous), but extending it was low hanging fruit. This isn't necessarily how it went down, but the incentives do align. I do think we'd have more automation in the world today if we'd have adopted XHTML. Now with AI/ML and NLP I think we'll get to this kind of web without a format to rigidly specify semantics. I still have to think that the ideas of semantic web and P2P could have delivered decades ago if Google and Facebook hadn't overwhelmingly pushed the envelope on centralized resources.

zozbot234 4y ago
HTML5 can be auto-translated into an XML surface syntax. You aren't losing anything compared to the old XHTML, though only the XML syntax can include content from other XML namespaces. Google even cooperates with other search engines in promoting unified formats to "extract knowledge from in a scalable and reusable way", namely the schema.org standards.
- echelon 4y ago
  XHTML treated schemas as a first class order of business, though. It would require people to use extra effort to author a table of "address information" (or whatever). Maybe that would not have happened, but the format also suggested the building of reusable components, browser integrations for semantic understanding, and much more. The world it alluded to was much brighter for machine understanding and reusability.
  - Devasta 4y ago
    Data served in a tree structure and then rendered with client side templating with the ability to create custom elements... those crazy W3C eggheads in their ivory tower, why did they think anyone would want that? /s
- schemescape 4y ago
  Is the “can be translated into XML” part of the HTML5 spec? That would be interesting to me, and I wasn’t aware of it until your comment. Edit: sounds like it’s not a thing: > The DOM, the HTML syntax, and the XML syntax cannot all represent the same content. https://html.spec.whatwg.org/multipage/introduction.html#html-vs-xhtml https://html.spec.whatwg.org/multipage/introduction.html#htm...
  - domenicd 4y ago
    The non-translatable features are extremely niche, though. To continue the quote: > For example, namespaces cannot be represented using the HTML syntax, but they are supported in the DOM and in the XML syntax. Similarly, documents that use the noscript feature can be represented using the HTML syntax, but cannot be represented with the DOM or in the XML syntax. Comments that contain the string "-->" can only be represented in the DOM, not in the HTML and XML syntaxes. I.e. the big thing you'd fail to capture when doing an automated HTML -> parsed DOM -> XML trip is noscript tags. No big loss. Others I can remember are similarly tiny, e.g. some issues around textarea elements containing only newlines as their initial contents. Some discussion at https://html.spec.whatwg.org/multipage/parsing.html#parsing https://html.spec.whatwg.org/multipage/parsing.html#parsing Ctrl+F "roundtrip", although note that most of that is actually about what happens if you construct weird DOMs with JS and try to do a DOM -> serialized HTML -> reparsed DOM roundtrip. I think it's pretty safe to say in general that the procedure of "parse HTML to DOM, serialize to XML" will preserve everything interesting about a document. Especially if that document is already valid HTML.

bawolff 4y ago

Even outside of the web stuff, SPARQL standard is really old at this point and seems like it could really use a revision, but nobody seems to be working on it.

jerven 4y ago
Rdf-star workgroup has just started and they will update some parts of sparql rdf etc. They are also looking at making it easier to update. I.e. living standards like.

Jasper_ 4y ago

Ian Hickson stepped down a few years ago and has started working on Flutter instead (Flutter started as a "what would a browser look like if we removed a bunch of legacy from the HTML spec" project). It's now maintained by Dominic Denicola, Anne van Kesteren, Tentek Celik, and a few others.

domenicd 4y ago

Let me clarify some things about the WHATWG HTML Standard: The HTML Standard has not been maintained by Ian since 2015. It has since then been maintained by myself, Anne, Simon, and Philip. Affiliations during that time are, respectively: Google, Mozilla then Apple, Bocoup then Mozilla, and Google. (Indeed, mostly only browser companies have been paying people to be editors for web specs!) https://html.spec.whatwg.org/multipage/acknowledgements.html#acknowledgments https://html.spec.whatwg.org/multipage/acknowledgements.html... But the contributor pool is much larger. We're quite proud of the vibrant (not stagnant) community we've created, which is continually evolving and improving the spec. Contributions come from all corners; many are from people employed by browser engine companies, but others include students, web developers, consultancies like Igalia and Bocoup which various companies hire to work on web standards, W3C staff and members, representatives from server-side runtimes like Node and Deno, and so on. Some interesting pages to peruse might be https://github.com/whatwg/html/commits/main https://github.com/whatwg/html/commits/main , https://github.com/whatwg/html/graphs/contributors?type=c https://github.com/whatwg/html/graphs/contributors?type=c , and https://blog.whatwg.org/ https://blog.whatwg.org/ . Overall I think it's pretty exciting you can run a successful standards organization like this, getting such high engagement levels despite employing no full-time staff and with operating costs being entirely server bills. Including, no membership fees. Which is perhaps relevant to the OP. https://twitter.com/Hixie/status/1603917371214729216 https://twitter.com/Hixie/status/1603917371214729216 The WHATWG only includes features in our standards which have multi-implementer commitment: https://whatwg.org/working-mode#additions https://whatwg.org/working-mode#additions . This is different than some places where anyone can publish a "standard", even if the target platforms have no intention of implementing it. I don't think this reduces to "merely a memorandum of understanding"; I think it's best when standards reflect reality. Other SDOs can disagree, and that's fine; it's healthy to have a marketplace. As for the scare quotes around "living standard", you might enjoy https://whatwg.org/faq#living-standard https://whatwg.org/faq#living-standard and the follow-up questions.