Oracle, Mozilla, W3C: Broken Links, Broken Web, Slugs in a Bucket

Oracle clickjacks W3C links

My problem sounded simple: In an XSLT stylesheet applied within a web-browser, I wanted to make sure that large or small numbers are as readable (to people dealing with these kinds of numbers) as 7.206e+16 rather than show up as a digit soup like 72057594037927936.

This made me inspect the XSLT specification at the W3C[1]. Yes, that's more than 20 years old, but it's the sort of XSLT that browsers (and libxml) support today, as opposed to XSLT's later versions. We are not talking “legacy“ material at all.

In the XSLT spec, you can read about the format-number function:

The format pattern string is in the syntax specified by the JDK 1.1 DecimalFormat class.

Aw, I said to myself, couldn't they just have used the venerable printf format codes? Undeterred, I tried to follow the DecimalFormat link, which points to http://java.sun.com/products/jdk/1.1/docs/api/java.text.DecimalFormat.html. In my browser, that looks like this with its default settings:

Yes: That's a header trying to sell me something and then a lot of white space. About 1000 pixels down, there's „Click to view our Accessibility Policy [line feed] Skip to content“, where „Skip to Content“ is a link to a „maincontent“ anchor that doesn't exist on the page.

Given the utter breakage of the page on even a relatively mainstream browser (webkit-based), I expected the “Accessibility Policy“ to be utterly depressing. I therefore refrained from even trying to click on the link, although it probably would have been broken, too, and hence there would have been no harm. In all fairness: If I let Oracle execute Javascript, the page looks a bit better, but it's still stupid advertising rather than information on DecimalFormat.

No wonder – look at the address bar: Oracle has redirected from the URL the W3C links to to the ad page at https://www.oracle.com/java/technologies/. Now, I don't expect much from a commercial entity, but they could at least return a proper 404 Not Found response and a page apologising they broke it; that way, machines could automatically notice the broken link and humans wouldn't irritatedly enable Javascript to see if that gives the expected content after all.

Well: of course they shouldn't break links from a major specification from the governing body of Web tech – and from a spec they are widely using themselves on top – in the first place.

A long history of evil getting worse

I must concede that it didn't take the pure evil of Oracle to fool around with redirects instead of 404s and to wantonly tear down static pages that could have been maintained forever at zero cost. Even the lesser evil that Sun was did that, as evinced by this 2006 capture from the Web Archive. That's already less than ten years after JDK 1.1 was released a quarter century ago (February 1997).

Which brings me to another reason to want to retire: This link has been broken for more than 15 years now. I suspect I'm imagining the W3C to be a lot better staffed than it actually is, and yes, touching normative content is a tricky thing to do. But either through an Erratum or as an editorial change the W3C could and should have fixed the clickjacked link some time within those 15 years. That would have been particularly thoughtful given that my reaction probably isn't too untypical: Rather than go to the Internet Archive to fetch the original documentation right away, I looked for DecimalFormat in today's Java documentation. And yay!, it says:

It also supports […] scientific notation […] Example: "0.###E0" formats the number 1234 as "1.234E3".

Except it didn't for me. The numbers were stubbornly unformatted regardless of what I did as soon as I tried any sort of scientific notation. Which drove me entirely crazy until I ran the browser from a terminal and saw log output there:

error
xsltFormatNumberConversion : error in format string '0.###E0', using default

It still took a while until I realised the problem was not actually with the format string – that I had taken literally from the modern documentation: Gnah! – but that JDK 1.1 just didn't have the feature. I actually had to go to an older capture of Sun's documentation to figure that out (do donate to the Internet Archive, please).

That was not the end of my webaches of the day.

Mozilla: Crashes in the supply chain

Proclamation: I'm a huge fan of the MDN whenever I do “web development“. You may hence get an idea of my desperation when, minutes after I had somewhat worked out the Sun-Oracle-W3C debacle, I was looking up the border-spacing CSS property at MDN and just saw a brief flash of content and then this:

What deviltry…? From folks who are at least reasonably concerned about standards compliance and accessability? Well, a quick glance into the developer tools made my me shiver. Here's what I found in the error console:

[Error] The source list for Content Security Policy directive 'script-src' contains an invalid source: ''report-sample''. It will be ignored.
[and a lot more CSP stuff]
[Error] Failed to load resource: Unacceptable TLS certificate (analytics.js, line 0)
"Error executing Glean task: NotFoundError: Failed to execute 'transaction' on 'IDBDatabase': One of the specified object stores was not found."
[Error] (Glean.core.Dispatcher) – "Error initializing dispatcher, won't execute anything further." – "There might be more error logs above."
[Error] TypeError: null is not an object (evaluating 'localStorage.getItem')
[Error] TypeError: null is not an object (evaluating 'localStorage.getItem')

So… the Mozilla folks list all kinds of new-fangled (i.e., bullseye Webkit doesn't know about them) Content Security Policies. I'll allow they do that out of concern for my privacy – though frankly, I'm not much worried about cross-site scripting from MDN, in particular because the site generally works fine without Javascript (I don't remember when or why I switched it on for them). Be that as it may, after all the CSP-ing, they turn around and try to rat me out to Google analytics (which fails here because google-analytics.com resolves to 127.0.0.1 on my boxes). Hu?

Want to report a bug? Feed Microsoft!

Anyway, I had Javascript on, and then I got the blank page because rendering crashes when the thing cannot do Javascript local storage. If you wonder why I keep that off by default, check out my rant against it; sorry: in German). That's why I get a blank page. It all goes belly-up starting with a message “Unable to read theme from localStorage“ from witin some React code. Call me a purist, but I don't even see how you'd need the ghastly React Javascript “framework“ <cough> for a documentation site. Why this would need to store a theme at all and why this should be crashing the whole doument[2] when it can't do that is entirely beyond me.

Given that Mozilla are (to some extent) good guys, I wanted to file a bug. They also were home to the premier bugtracker of the 2000s, bugzilla, so… No. Even the contribution guide [warning: github link] – a static document! – sits in github, collecting behavioural surplus for Microsoft.

Ah… sorry, Mozilla, if React and github are your ideas of an open, accessible, and standards-compliant Web, there is no point filing bugs against MDN. That's not a good use of the surveillance capital I have to give.

But then: being a gardener isn't all that idyllic either:

Given that, Oracle and Mozilla are not much worse. So, I guess I'll keep doing computers for a little while, at least as long as I can somehow still work around the postmodern Web's breakage most of the time.

[1]	Well, actually I was looking at a local mirror of that, but if turns out that looking at the online material right away wouldn't have made a difference.

[2]	I just notice that the existence of the phrase “crashing a document“ is a rather characteristic symptom of the state of the Web.