Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@norman70688 The problem wasn't with the units. The problem was that FF doesn't give back what I had put in, only something equivalent.
If they have done that with translate(), then I cannot safely assume that they would never do that with another function, like matrix().
They could even juggle a translateX(0px) into just clearing the property with an empty string, that's the point that shadow variables get me around because now my access to that interface is write-only. -
@Charon92 that would work for a simple case where you just displace an object by a constant amount like on/off.
Not only that I would need a lot of classes for all possible X offsets plus those for all possible Y offsets, but also for all possible transition times because the screen speed shall be constant when moving from A to B.
And then the code to first toggle away all old displacement and transition classes, then toggle in new ones because the objects usually don't just move back to their origin, but somewhere else. That would be a lot more code both in CSS and in JS.
The design mistake was not working with shadow variables and instead storing the state only in the DOM. -
@TylerDDevRant but then I would have to extract the actual translateValue first, i.e. the stuff that's inside the brackets.
What I'm paranoid about: that there is no translate value with brackets at all because some browser dev could come up with clearing the whole property. Once bitten, twice shy.
I wanted to fix that area once and for all, plus that I eliminated the yo-yo code resulting from the integer-string-integer conversion. The shadow variables are just integers. -
@norman70688 It's with SVG (actually sprited SVG #id paths in a single file to cut down on requests) as div backgrounds. Originally, it was with PNG sprites, but SVG looks much crisper on hiDPI displays.
I'm not sure whether I could use the SVG directly because I need some way to duplicate paths for duplicate pieces. Currently, that works with setting div classes where the background references the correct path ID.
E.g. I can have 2 divs for white rooks that both have the #id for a white rook in their background. The divs are what's being animated via their translate property. -
@norman70688 I think that would work - but without much difference over the solution I have now, except that it's use instead of div and doesn't have the option for any other image format.
Also, I'd still need CSS translation because together with will-change, that enables GPU acceleration while SVG attributes probably don't, or do they?
When I finally understand where my bug comes from
I literally spent 3h looking at all the freaking formulas in my pathtracer which was producing the wierdest ps...
Mozilla you stinking kangaroo pouches!
When you set an object's CSS translation via JS like so:
obj.style.transform="translate(0px,0px)";
and then read it back, every browser including FF until 66 gives this, with additional space:
"translate(0px, 0px)"
However, bloody FF 67 returns "translate(0px)". Because it's always a good idea to just introduce external changes nilly-willy, right?
That screwed up my crappy string slicing because it relied on the presence of the comma. It was a quick and dirty solution, but with additional future proof if/else logic, it wouldn't even be quick anymore.
Besides, the whole string slicing looked like yo-yo code anyway so that I instead added shadow integer variables to the objects. That solution not only works, but is even faster.
rant
stupid bug