You’re traveling through another dimension — a dimension numbered not one, but two. A journey into a wondrous context whose boundaries are that of a canvas. There’s a signpost up ahead; you’re entering...
🦇
🎃
<!-- ARC-ORDER note (see above):
some demos rely on the precise order of the arc() and arcTo()
methods, see https://bugzilla.mozilla.org/show_bug.cgi?id=623437
for an example, and its duplicates for more -->
👻
🧟
HTML once updated the relative order of the arc and arcTo members of
CanvasRenderingContext2D due to what appeared to be a web compatibility issue. It wasn’t, though — the only
thing that wasn’t web-compatible was the code being fixed. It relied on the “invariant” that no two
members of CRC2D have names whose first and seventh (or third if undefined) characters were the same as those
of another.
It was “fixable” from HTML by adjusting member order in the Web IDL definitions so that the original property would end up following the newer one. This is very specific to the one demo, which could as easily have been taking the first “collision” property instead of the last. Maybe it wasn’t realized at the time that the order was not the underlying issue, but whatever the case I love that HTML at one point appeared to endorse this as a characteristic authors could rely on 👻.
Inevitably another property ended up invalidating the demo script’s assumptions again later and it doesn’t work presently. To ensure it can never be brought back to life through changes to HTML again, this page makes the same assumptions but expects the current order for the offending pair. Neither page is more important than the other, but they can’t both work at the same time ... HTML, please don’t break my Web Page! :)