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. 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.
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')
Want to report a bug? Feed Microsoft!
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.
|||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.|
|||I just notice that the existence of the phrase “crashing a document“ is a rather characteristic symptom of the state of the Web.|