Overview of HTML5 Standardization Activities.
License: The Unlicense
This is the repository for the HTML5 Overview published at html5-overview.net.
Please respect the license.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
An overview of HTML5 standardization activities should include the ARIA spec.
It’s odd to have an “overview of all HTML5 standardization activities“ that doesn’t include a DOM spec.
A lot of the spec spec links in this overview are to outdated TR drafts. But those TR versions are almost always not the most helpful versions for users. Instead users should typically be reading and using the latest editor’s drafts.
I understand the rationale for classifying the specs that have W3C versions maintained by W3C WGs into Rec/CR/WD/Note and I agree there’s real value in providing that information and I think that should be kept. But from that it does not necessarily follow that the spec links should be to the TR versions—or even to the W3C versions, if there's a more up-to-date version elsewhere.
The Fetch spec is very much part of “HTML5 standardization activities” as far as the scope of that is outlined in the intro to the docs here. Yeah, it’s not a spec in any W3C working group, but the intro here doesn’t say the scope of this overview is limited only to specs being developed in W3C working groups.
The Web NFC API is a CG spec, not a WG spec, but it’s included in http://www.w3.org/2015/05/mobile-web-app-state/ so it makes some sense to add it to this overview also.
The Generic Sensor API is a deliverable in the Device APIs WG, currently just a sketch at https://github.com/w3c/sensors#sensor-api-unification-sketch but perhaps worth adding a section titled Early Work to Keep an Eye On or Incubation Stage or On the Horizon something like that? (And maybe not including it in the counts published about number of specs in progress.)
Despite the lack of even an ED at this point, there's been some real work going on and I think it has a good chance of maturing into something that actually gets implemented and becomes part of the platform. Not at all a sure thing of course, but for a few more details and history, see http://www.w3.org/2015/05/14-dap-minutes.html#item07 and https://lists.w3.org/Archives/Public/public-device-apis/2015May/0039.html and https://lists.w3.org/Archives/Public/public-device-apis/2014Nov/0018.html
The Web Bluetooth spec is a CG spec, not a WG spec, but it’s included in http://www.w3.org/2015/05/mobile-web-app-state/ so it makes some sense to add it to this overview also.
I should have thought to mention this when I raised issue #13 but in the specific case of the Web NFC API, the existence of the CG spec at http://w3c.github.io/web-nfc/ by design completely obviates and supersedes the http://www.w3.org/TR/nfc/ WD version.
For background, see https://lists.w3.org/Archives/Public/public-nfc/2015Mar/0020.html and https://lists.w3.org/Archives/Public/public-nfc/2015Apr/0005.html
As those messages indicate, the NFC WG has been closed, and the intent was for the WG draft of the API to be moved to Note when the group closed. For whatever reason, that hasn’t happened yet (and I’ve started a W3C team-internal discussion to get it done now) but regardless it’s clear that draft has been abandoned by the WG that created it, so it can be safely removed from this overview.
I don’t think it’s necessary to wait for it to be formally moved to Note, because as I outlined in issue #19 IMHO this overview should not include a Notes section anyway.
The Fullscreen spec is alive and actively maintained at https://fullscreen.spec.whatwg.org/ but this overviewjust lists the spec as W3C Note, which indicates that W3C work on it has stopped and it’s no longer being actively maintained.
I think presenting the information about the Fullscreen spec that way is misleading to users. It essentially causes them to think the Fullscreen spec is dead.
Any overview of HTML5 standardization activities should include a link to the WebGL specs.
this work is part of HTML http://www.w3.org/TR/html-aam-1.0/
HTML Accessibility API Mappings (HTML-AAM) defines how user agents map HTML 5.1 [HTML51] elements and attributes to platform accessibility application programming interfaces (APIs). It leverages and extends the Core Accessibility API Mappings 1.1 [CORE-AAM] and the Accessible Name and Description: Computation and API Mappings 1.1 [ACCNAME-AAM] for use with the HTML 5.1 host language. Documenting these mappings promotes interoperable exposure of roles, states, properties, and events implemented by accessibility APIs and helps to ensure that this information appears in a manner consistent with author intent.
Most HTML5 specifications are W3C TR documents, moving through the well-defined lifecycle of W3C specifications. There also is a small number of non-W3C specifications (which occasionally get adopted as W3C specifications when they gain widespread support).
In actuality, many foundational specifications are developed at other standards organizations: for example, HTTP at the IETF; JavaScript (ECMAScript) at Ecma; and most importantly, the many specs at https://spec.whatwg.org/ developed and maintained by the WHATWG.
The W3C sometimes copies and pastes/forks WHATWG work and puts their logo on it; see https://wiki.whatwg.org/wiki/Fork_tracking. We've asked them many times to stop doing this, but they continue; see e.g. http://lists.w3.org/Archives/Public/www-archive/2014Apr/0034.html. So far they have not started copying from the IETF or Ecma, but it's worth keeping an eye out for instances of that happening in the future. The copying does not indicate that the standard has transitioned to widespread support, simply that the W3C has taken notice and devoted staff resources to forking.
Additionally, TR documents are generally not valuable; "TR stands for trash" is the common way of saying that TR documents are almost always outdated snapshots of the editors drafts, which are what web developers and browser implementers should be consulting.
My suggested revision, omitting any mention of the forking, would be something like:
Several standards organizations collaborate in the development of the web platform ("HTML5"), notably Ecma, the IETF, the W3C, and the WHATWG. The main HTML Standard (often called "HTML5") is maintained by the WHATWG, along with other foundational parts of the ecosystem like the DOM, URLs, or Fetch. The JavaScript language is maintained by Ecma under the name "ECMAScript". Much of the networking layer, such as HTTP, is maintained by the IETF. The W3C serves as a home for many more specifications touching on other areas of the web platform, such as media and web application security specifications.
I have a feeling this discussion is not going to result in the kind of changes that I think would be healthy for developers, given the site's current W3C-centric and process-centric focus. (E.g. delineating things by their stage in the process, instead of just pointing to the most up to date editor's draft.) That is fine; I have so far referred people to https://platform.html5.org/ as something which I think does a healthy job of referring developers to the most up to date spec, and not linking to forks. So please forgive me for not engaging extensively in this discussion beyond just filing this issue, if the site is intent on maintaining its current course. But from the quick Twitter discussion I saw between you and @sideshowbarker, it seems like there is some desire to produce something that's most helpful for developers, and perhaps the current setup is just a result of being misled by the W3C marketing team in various ways. If that's the case I'd love to help guide the site toward something that's better for the health of the web.
The Web Speech API spec is a CG spec, not a WG spec, but it’s included in http://www.w3.org/2015/05/mobile-web-app-state/ so it makes some sense to add it to this overview also.
https://dom.spec.whatwg.org/ is the only DOM spec now being actively maintained—the one that implementors are actually working from and the only one that’s incorporating new features and receiving bug fixes. (https://www.w3.org/TR/dom/ is a frozen Rec that’s not up to date with current implementations and so should not be used by implementors or web developers, and nobody is working on WD to replace it.)
From #23 (comment)
added lifecycle for completeness b14b2f9, but it now shows up as "other" since it is not an official W3C NOTE. maybe not quite what you were looking for, @sideshowbarker?
Well, I personally wouldn't include that spec, since it's not been updated in more than a year, doesn't seem to have any implementor support, and at this point has no home in any W3C WGs nor anywhere.
But I won't object to it being included if you want to. At least it's in scope as far as being intended for implementation in the Web runtime and the Web security model (as opposed to the other SysApp WG drafts, which were intended for a hypothetical off-Web runtime/security-model that never materialized).
Still I think that lifecycle spec has near-zero chance of ever getting implemented across UAs (or probably any UAs), and so near-zero chance of every becoming part of the Web platform.
The System Applications WG is no longer functioning as a WG (see related details in issue #20) and per items 6 to 9 in https://lists.w3.org/Archives/Public/public-sysapps/2015Apr/0017.html and https://lists.w3.org/Archives/Public/public-sysapps/2015Apr/0029.html the group has abandoned all work on the Task Scheduler, App Lifecycle, TCP UDP Sockets, App URI specs and it’s not clear that any other WG will pick up work on those specs, nor even that they would fit in any other group.
Rightly the SysApps WG should have already moved all those specs to Note, but they have not yet, and since the WG is not actually functioning any longer, they will not be moving them to Note any time soon.
So given all that aand the fact that none of those specs actually have any implementations, IMHO the right thing to do for now would be to remove all of them from this overview (lest people reading the overview be misled into thinking any of those specs are actually still progressing anywhere).
Pointer Events spec uri is wrong. URI should be http://www.w3.org/TR/pointerevents instead of http://www.w3.org/TR/pointer-events.
See the persistent warning now on https://www.w3.org/TR/url-1/
We are now asking readers of https://www.w3.org/TR/url-1/ to no longer use or reference it (it is no longer being maintained) and to instead use https://url.spec.whatwg.org/
http://www.w3.org/TR/html-aria/
This specification defines the web developer rules (author conformance requirements) for the use of [wai-aria-1.1] attributes on [HTML51] elements. It also defines requirements for Conformance Checking tools.
The Runtime and Security Model for Web Applications spec should be removed.
Work on that spec was actually abandoned by the System Applications WG quite a long time ago. See https://lists.w3.org/Archives/Public/public-sysapps/2015Apr/0017.html where it’s noted “Approach abandoned by WG while WG was still functioning.“
That spec is just limbo/zombie state due to the fact that the System Applications WG is in fact no longer functioning as a group and has no actual active chair and is no longer actually even making decisions about things like closing up loose ends by moving their abandoned work to Notes.
Note for example the fact that I sent a message about the Runtime and Security Model draft to the WG mailing list more than a week ago but didn’t get a single response. And note that my message was only one of two messages that have been posted to the list in the last 2 months. https://lists.w3.org/Archives/Public/public-sysapps/
So while it’s not completely inaccurate to include the Runtime and Security Model draft in this overview as being something at W3C WD status, it is misleading to do so given that the spec has in practice been abandoned and has zero chance of ever getting implemented and becoming part of the Web platform.
I do not know where you draw the line on what you consider part of the HTML5 world but, with the increasingly widespread usage of schema.org you may consider adding at least RDFa+HTML and Microdata (RDFa+HTML refers to the other RDFa documents but those are not to be added I believe).
If you prefer and agree, I can prepare a PR on this (at some point, not necessarily right now).
The Web Notifications spec at https://notifications.spec.whatwg.org/ is in active development. Omitting any reference to it at all misleads users into thinking the (essentially frozen) W3C Web Notifications spec represents the latest development for Notifications.
I think it’d be fine to list both versions, with some kind of note indicating what each represents (e.g., the W3C spec represents what’s already been implemented and shipped in some browsers, while the other spec represents the latest consensus on what the API should be going forward.)
Despite the “Audio Processing API” title of the WD at http://www.w3.org/TR/audioproc/ that document does not actually itself define any API, nor does it normatively define anything at all. Instead it simply references two other documents:
Given all that and the fact that this overview already lists the Web Audio API, I think that listing of the Web Audio API is sufficient, and it’s not necessary or useful for this overview to also list the “Audio Processing API” document.
To be complete, why not add this one too?
http://www.w3.org/TR/html5/
I believe it’s not actually helpful for this overview to include any specs that have been abandoned by a W3C WG—especially not specs for which there are either no current implementations or that have no probability of ever being implemented across multiple UAs in such a way that anybody can say they will have become part of the Web Platform.
Concretely that would mean the entire Notes section should be dropped from this overview, because it includes only specs that have for whatever reasons been formally abandoned by W3C WGs.
I can see the Notes section being over historical interest, but as far as I understand the scope of this overview, the overview is not intended to provide a historical record (otherwise there's actually a whole lot of other specs it ought to include) but instead to capture the current state of development of “HTML5“ as a programming platform, reflected by the set of technologies for which there are either relevant specs which are still active progressing, or that have versions that have become W3C Recommendations.
So I think the Notes section could better be moved out to become a separate document, titled retired.md or some such (if it’s kept at all).
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.
