What can wonky APIs tell us about the web?
25 points by sloanelybutsurely
25 points by sloanelybutsurely
The history entry title thing is an interesting one, because it seems to me that it was really rather important, because without it it’s genuinely not clear what history entries’ titles should be.
// You load a page. Its title is "A".
// After some time, possibly via some user interaction:
document.title = "B";
sleep 1 second;
document.title = "C";
history.pushState(…);
document.title = "D";
sleep 1 second;
document.title = "E";
The previous history entry: should its title be A, B or C? All three can be justified.
The current history entry: should its title be C, D or E? All three can be justified.
Do the answers change depending on whether the “sleep 1 second” occurs synchronously, asynchronously via new microtask, asynchronously via new task? Or what user interactions may or may not have occurred?
Summarised another way: do you change your DOM and then push state, or push state and then update your DOM?
I don’t see anything about titles in the history and session parts of the HTML Standard (§7.2, §7.4). So I don’t think the behaviour is specified anywhere, and I don’t know if browsers are consistent. The only example in the spec updates DOM and then pushes state, but makes no remark on it.
Even the newer navigation API (only recently shipping in all major browsers) doesn’t seem to address the question of titles.
I think the answer is that whatever the browser considers to be your title, as shown in the title bar, is what gets stored in history when pushing state. At least that's what I'm getting.
That’s definitely not the complete story. Running basically what I posted before, in both Firefox and Chromium, I get C for the previous and E for the current, which will then be changed to C when the entire process is repeated.
If this is correct, this indicates you should pushState and then set title after that, or else the previous one gets corrupted, having the previous URL but the new title.
For some reason I forgot about updating, which is fairly common. Browsers seem to be showing the last title before the new entry was pushed. Which makes the example in the spec bad.
what’s the story with canPlayType though? are fuzzy answers an attempt to prevent fingerprinting?
Fundamentally there's so many layers to supporting a format that actually providing a strict yes/no answer in an API would be near impossible without sticking tendrils really deep into the decoders. Not to mention that the "mime type" and "codec" is nowhere near enough in most cases.
For example, if you have an MP4 container with an H.264 stream, that information isn't enough alone to say a definite yes. What profile is used? What color space?
Fingerprinting would become a larger issue if implemented in a yes/no manner, but it was never going to get implemented in a yes/no manner anyways, there's too many practical barriers.