I'd like to adjust the outdated banner for the archived pages to be something always up to date. #2928

dead-claudia · 2019-09-23T22:43:56Z

dead-claudia
Sep 23, 2019
Maintainer

Currently, we have a "deprecated" banner on all v0.2.x stuff. I feel I could easily hack together thing where I could append a quick script to each the archived pages' bodies for a better, more informative, more useful banner. Wouldn't have to be much - I'd just use a couple simple elements to configure:

<script src="/static/warn-outdated.js"></script> - This loads the warning label this at the end of the <body>, as a closeable dropdown at the top. It will handle its own styling, too, so I'm not having to add more data to the page than I have to.
<meta name="x-mithril-version" content="x.x.x"> - This lets our script know what the current version is, for comparison. x.x.x is the version, where 2.0.4 is for v2.0.4, 0.2.1 is for v0.2.1, and so on. (I would've preferred to use a query parameter on the script, but there's no way I could reliably get the currently executing script element to check that on IE11, and a <meta> element is much easier than the alternatives.)
Both elements would be placed in the <head> immediately before the first element other than <meta charset="utf-8">.

Not 100% sure about the design side, but I can get to that later when I get around to implementing this. Do note that the existing deprecation notices in the v0.1/v0.2 docs would also have to disappear.

Script-wise, I could probably get away with something as simple as this:

// This should work on even some of the most ancient of browsers, including IE6.
;(function () {
"use strict";
var meta = document.head.firstChild;
while (meta.tagName !== "meta" && meta.name !== "x-mithril-version") {
	meta = meta.nextSibling;
}
var thisVersion = meta.content;
var domReady = false, xhrReady = false
var xhr = typeof XMLHttpRequest === "undefined"
	? new ActiveXObject("Microsoft.XMLHTTP")
	: new XMLHttpRequest()
var versions

document.onreadystatechange = function () {
	if (document.readyState !== 'interactive') return;
	domReady = true;
	if (xhrReady) next(versions);
};

xhr.onreadystatechange = function () {
	if (xhr.readyState !== 4) return;
	xhrReady = true;
	if (xhr.status >= 200 && xhr.status < 300 || xhr.status === 304) {
		versions = typeof JSON !== "undefined" && JSON.parse
			? JSON.parse(xhr.responseText)
			// The response shouldn't contain any invalid JS characters anyways.
			: eval("(" + xhr.responseText + ")");
	}
	if (domReady) next(versions);
}

// The versions would be stored here.
xhr.open("GET", "/versions.json", true);
xhr.send();

function next(versionsFound) {
	// Create element, style it, and add it
}
})();

Edit: fix a bug in the script loading side

pygy · 2019-12-16T18:28:50Z

pygy
Dec 16, 2019
Maintainer

@isiahmeadows couldn’t we rather hardcore the version number in a small script that would be generated on release by our npm script?

0 replies

dead-claudia · 2019-12-19T05:59:42Z

dead-claudia
Dec 19, 2019
Maintainer Author

@pygy We could, if you mean something like injecting <script>MITHRIL_VERSION="x.x.x"</script> instead. It functionally works the same way, but it'd save maybe a few dozen bytes if that off the entire page load (not likely to even save a single TCP frame). And besides, we don't have any other critical scripts to load - it's all statically generated HTML.

0 replies

pygy · 2019-12-23T22:57:01Z

pygy
Dec 23, 2019
Maintainer

I mean this (but I may be missing your intent).

The latest version is v<span id=mithrilVersion></span>
<script src="latest.js"></script>

// latest.js
mithrilVersion.textContent = "x.y.z"

0 replies

dead-claudia · 2019-12-26T13:41:23Z

dead-claudia
Dec 26, 2019
Maintainer Author

Oh okay. Detecting the latest version was the point of my /versions.json, the file the script would fetch. That file would have an array of versions, something like this (but obviously without the whitespace):

[
	"0.1.3",
	// ...
	"0.2.4",
	"0.2.5",
	"0.2.6",
	// ...
	"1.0.0",
	// ...
	"1.1.7",
	"2.0.0-rc.0",
	// ...
	"2.0.1",
	"2.0.3",
	"2.0.4",
]

Note: broken and unpublished releases like 0.2.3 and 2.0.0 would be intentionally excluded.

I was referring to putting the relative version (like <meta name="x-mithril-version" content="0.2.6">, etc.) in the page's <head> itself, so we can read the version that page's documentation is for.

We can then use that and knowledge of the latest version (as per /versions.json) to decide whether to hide the banner (for the current version), so we can have a dropdown of all the versions where the version you're currently looking at is the one initially selected in the dropdown (like what Python does in their docs).

0 replies

pygy · 2019-12-26T21:05:29Z

pygy
Dec 26, 2019
Maintainer

Now this makes complete sense, thanks for clarifying.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

I'd like to adjust the outdated banner for the archived pages to be something always up to date. #2928

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 5 comments

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Uh oh!

I'd like to adjust the outdated banner for the archived pages to be something always up to date. #2928

Uh oh!

Uh oh!

dead-claudia Sep 23, 2019 Maintainer

Replies: 5 comments

Uh oh!

pygy Dec 16, 2019 Maintainer

Uh oh!

dead-claudia Dec 19, 2019 Maintainer Author

Uh oh!

pygy Dec 23, 2019 Maintainer

Uh oh!

dead-claudia Dec 26, 2019 Maintainer Author

Uh oh!

pygy Dec 26, 2019 Maintainer

dead-claudia
Sep 23, 2019
Maintainer

pygy
Dec 16, 2019
Maintainer

dead-claudia
Dec 19, 2019
Maintainer Author

pygy
Dec 23, 2019
Maintainer

dead-claudia
Dec 26, 2019
Maintainer Author

pygy
Dec 26, 2019
Maintainer