Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better support for looking at past snapshots of the standard #4042

Closed
benwiley4000 opened this issue Sep 20, 2018 · 8 comments

Comments

@benwiley4000
Copy link

commented Sep 20, 2018

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

This comment has been minimized.

Copy link
Author

commented Sep 20, 2018

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

This comment has been minimized.

Copy link
Author

commented Sep 20, 2018

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

This comment has been minimized.

Copy link
Member

commented Sep 20, 2018

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

Given that I think this can be closed.

@benwiley4000

This comment has been minimized.

Copy link
Author

commented Sep 20, 2018

@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

This comment has been minimized.

Copy link
Member

commented Sep 20, 2018

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

This comment has been minimized.

Copy link
Author

commented Sep 20, 2018

Ah I see! Thanks!

@domenic

This comment has been minimized.

Copy link
Member

commented Sep 20, 2018

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

This comment has been minimized.

Copy link
Author

commented Sep 20, 2018

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants
You can’t perform that action at this time.