In the 'Astronomical units' section, the parsec unit (pc
) is defined as the absolute unit equal to 3.086E18 cm
, and there is the following note:
This specification does not address relativistic effects of scrolling or animations and transitions at (or beyond) the speed of light.
However, all browsers I tested don't preserve this proportion. Instead, they render 1 parsec as something about 0.38 to 0.4 cm
(see JSfiddle example: https://jsfiddle.net/oxqoqkxh/1/).
The only explanation to this phenomenon I can come up with is that, according to the Special Relativity theory, "traditional" units and astronomical units are measured in the different reference frames: the Lorentz factor of the reference frame where "traditional" absolute units are measured is extremely lower than that of the reference frame used for astronomical units. While the Lorentz factor of the former is usually below 2 (e.g., on iPhone and iPad mini 1in
at 100% scale is about 0.59 physical inches), the latter is several orders of magnitude higher. And because the proportion of the "static" centimeter and the "Lorentz transformed" parsec is nearly the same in all browsers, I suppose that the speed rate of these two reference frames must be a fundamental constant.
I haven't calculated which speed does the Lorentz factor used for astronomical units correspond, but given that the CSS EGG spec has many references to CERN, I guess that this speed has something to do with the LHC (maybe it's the speed of the proton beam at its maximum energy?).
Technically, this speed is not "the speed of light or beyond", so I can't say that the current Note in the spec is _absolutely_ wrong. But because it's 1) very close to it and 2) its Lorentz factor is _in constant proportion_ to that of other physical units in all browsers, I believe this fact is also worth noting in the spec!
Sadly the parsec unit pc
conflicts with the picas unit. Anyways I think one parsec is too small for some usecases, e.g. to represent the Milky Way at real scale. So I propose replacing the parsec unit with kpc
, i.e. kiloparsec.
I just hope this ships before I finish the Kessel Run app I'm building.
Since the picas unit doesn't seem used much in the wild, maybe this conflict can be resolved by replacing it with _picopica_ (1e-12 picas) unit? I assume that, given the constantly growing screen resolutions of the mobile devices, this unit could be really useful in VR/AR applications like _PokemonGo_ in the super-high-definition Web context...
I did calculate the speed, and inertial frames ain't gonna cut it: the faster frame would have to be moving at something like 0.9999999999999999999999999999999999999905c
. And javascript says that number鈥攁pproximately 1 - 9.4E-39
鈥攊s equal to the speed of light. _(Experts: I had to Taylor-expand the square root. So I only used one term, effectively discarding terms of O(distance_ratio**4) and above.)_
No, I think we can only reasonably explain the discrepancy via gravitational contraction. Specifically, CSS is a massive black hole and we're all deep within that region where events can be captured but not bubble up back to the initiating universe.
All your Christoffel symbols are belong to CSSWG.
Closing this to make more space and time for more serious issues.
Most helpful comment
I did calculate the speed, and inertial frames ain't gonna cut it: the faster frame would have to be moving at something like
0.9999999999999999999999999999999999999905c
. And javascript says that number鈥攁pproximately1 - 9.4E-39
鈥攊s equal to the speed of light. _(Experts: I had to Taylor-expand the square root. So I only used one term, effectively discarding terms of O(distance_ratio**4) and above.)_No, I think we can only reasonably explain the discrepancy via gravitational contraction. Specifically, CSS is a massive black hole and we're all deep within that region where events can be captured but not bubble up back to the initiating universe.
All your Christoffel symbols are belong to CSSWG.