Html: Better support for looking at past snapshots of the standard

[benwiley4000]

Although I appreciate the value of the living standard approach, and don't think it should change, it's pretty unfortunate that there's no easy way to look for past snapshots.

As I have been doing a lot of work lately where I need to read the standard, there have been many times I wanted to know the history of a certain part of the spec (for thinking about supporting older browsers), and that's just not been an option. Many modern software projects' documentation has the ability to select past snapshots for reference, and I think there's inherent value in this even if the project chooses to not release "versions." HTML shouldn't be an exception.

At the moment I'm aware of two potential solutions that are accessible via the web:

1. View the commit history using GitHub. This has the severe disadvantage that GitHub doesn't offer an interface for finding a commit by date. The only first-class traversal method is paging back, one page at a time.
2. Use Archive.org's wayback machine. This is nice because it allows you select a snapshot by date, but it's not a great solution because a. the history only goes back to 2014 and b. it depends on a third-party service which isn't built for this purpose.

A couple better solutions I can think of:

1. Run a service that can serve arbitrary versions of the standard based on git commit, and offer an interface in the web page for selecting commits based on date.
2. Like option 1, but if the cost of running a service sounds prohibitive, then the "service" can be run in the browser itself. Clients wishing to look through past history of the standard can asynchronously load the git repository in the browser (using a tool like isomorphic git), which will be used to dynamically replace page content with the selected snapshot.

[benwiley4000]

Thinking about it, among the two options I proposed, one serious advantage of the second is that search engine results would not become polluted with past snapshots of the standard - someone arriving from Google will always see the latest.

[benwiley4000]

And just to sort of explain why I think this is valuable and not replaceable by, say, browser compatibility tables for certain features: I'm often interested in the specifications for update algorithms (e.g. the algorithm that defines what happens when you change the src on an img), and how those might have changed (or not) over time. Browser compatibility tables don't give you that.

[annevk]

https://html.spec.whatwg.org/commit-snapshots/ exists (as well as https://html.spec.whatwg.org/review-drafts/). https://github.com/whatwg/html-build/issues/97 is about linking it more prominently.

Given that I think this can be closed.

[benwiley4000]

@annevk aha! Thanks for the links. I think you're right, that mostly covers this.

Indeed it would be nice if that were more prominently linked in the spec.

A couple of other comments:

1. Some sort of date selector on the page of snapshots would be a big plus
2. Do the snapshots only go back to 2015?

[annevk]

Yeah, before that would be hard as well since the source format changed over time. What I usually use for archaeology is blame: https://github.com/whatwg/html/#blame. It's a little tedious as you have to read the HTML as well, but it's quite good at tracking down changes and also why they changed.

[benwiley4000]

Ah I see! Thanks!

[domenic]

Note also that looking at old spec snapshots is unlikely to work well for your stated purpose of investigating historical browser support. The algorithm in the spec at time X will not necessarily match all, or even any, of the contemporary implementations, especially as you go further back. (Hundreds of open and closed issues on this tracker document such mismatches.) For your stated purpose, I would instead suggest looking at the contemporary source code for the open source browser engines.

[benwiley4000]

@domenic for sure, that makes a lot of sense.

That said it would help give me an idea for how long and algorithm's spec has been somewhat stable. For example, one question I've had and never resolved is how playback errors were handled for media elements before promises were included in the algorithm for handling a request to play(). Did they throw errors at all? This is something that I might not have a definitive answer to by reading the old spec, but reading an old description of the algorithm could give me an idea if error handling was a concern.