Enhancement refactor element.style

[ibolmo]

Don't merge. It's no where near done. Just wanted to get some feedback.

A couple of things.

1. I unrolled the Element.ShortStyles which significantly increased Element.Styles. I still think there's room to play with this. Keeping in mind, however, that we want to keep it simple. Let compilers and gzip do the hard work.
2. Getter and setters are separated, but there may be collisions and a lot of repetition (element.getComputedStyle).
3. There's also some normalization in setStyle and getStyle ... how are we going to handle this? Per getter/setter or against all results.

[ibolmo]

Oh and this is definitely untested.. :D ala 1.0.x style (a "kami commit")

[arian]

there isn't a getGetter function yet.

[ibolmo]

hehe good call. Must have forgotten. I'll fix soon

[arian]

Also why not just keep https://github.com/mootools/mootools-core/blob/cb327bf3/Source/Element/Element.Style.js#L216-232 which is a bit shorter.

[arian]

get: getOpacity,
set: setOpacity

should be able to handle it..

[ibolmo]

actually I'm considering moving that logic inside the get and set. Just haven't gotten to it

[arian]

Nice work, good start! 👍

[gonchuki]

code will wrongly enter here when result && !Element.ShortStyles.hasOwnProperty(property), you only need to run the getComputedStyle part if we got no result from the this.style[property]

Even better, I'm also not sure if doing: var result = this.style[property] || this.getComputedStyle(property); would break anything, current specs pass but that doesn't say much. Any reason to give ShortStyles precedence over trying to getComputedStyle on the element?

[ibolmo]

You're right the change is not 1:1 with the previous logic. I'll modify soon.

Regards to your suggest change, again you're right. It's not clear why we can't default to getComputedStyle. If style getter doesn't work.

My other thought is, why can't we always use getComputedStyle? Was the original idea used to save CPU cycles?

[gonchuki]

saving CPU cycles is a sure thing, remember than only IE has .currentStyle so other browsers will go though the longer function-call-heavy path. Considering that getStyle is used a lot on animations, we should always have the fastest possible path here to avoid jerkiness.

That being said, if it's safe to do style || getComputedStyle on this part of the code then we could integrate this default behavior right inside getComputedStyle if (this.style[property]) return this.style[property]; etc. as the rest of the uses of getComputedStyle are always as a default when the element.style cannot be retrieved (getOpacity, setFilter on #2411, etc)

[gonchuki]

investigated this, it's not safe to just integrate the element style inside getComputedStyle. Several tests break on different browsers so it seems it is like that for a reason. Removing the element.style querying altogether is neither an option, once again several tests break. Keeping in line with the comment I left on #2417 I think this part of the code should stay with the same logic flow unless we get way more specs to cover all bases.

edit: also a small correction to my comment above: seems that Opera also has currentStyle and it has a serious bug on getComputedStyle where if you set something as a %, the getComputedStyle call rounds the result to the nearest pixel integer instead of returning the exact sub-pixel value as Firefox/IE9/IE10 does (this unit conversion from % to px was addressed on #2160, some browsers convert from % to px, others don't).

Take this as misc info to reinforce the fact that current logic flow is mostly ok, even though I would still like to have getComputedStyle used if available instead of currentStyle as that's the standard and I will probably get up a PR later with these changes. I still think that doing small incremental changes gets us in a position where we can ship code now without requiring a ton of new specs.

[ibolmo]

The reason I unrolled the https://github.com/mootools/mootoolscore/blob/cb327bf3/Source/Element/Element.Style.js#L216-232 is simply that it wasn't easy to read.

My logic is that we're no longer in 2000 when JS compilers were non-existant and that most people didn't bother to gzip .. CDNs are prolific now.

Lastly, I'm not done with Element.ShortStyle and Element.Styles. I think there's a lot of room to explore. To explore, I thought let's see all properties unrolled.

I have some ideas with increased effort:

1. Instead of defaulting to '@' we could default to '@px' in line: https://github.com/mootools/mootools-core/pull/2414/files#L0R86. That'll save a lot of bytes. I'm not sure, however, of the consequences. Need more test coverage.
2. I was thinking we could do a BoxModel class that we can use to say contain this stuff. Especially rules about accepted input and marginTop-like (, borderTopWidth...) definitions that would be implicit to the model. Again, this is very vapor but I thought it might be interesting to see if it'll simplify development.
3. Finally, if we decide that we don't need developers to understand the code we can save a lot of bytes by having a script that scrapes the w3 css definition and comes up with a literally mapping of the accepted input and the expected output. Notice that sometimes we map some outputs to px or convert rgba to rgb. That's really bad. or how we round floats ow.

[ibolmo]

Closing due to no longer relevant. If at any point we'll refactor this, we'll do so then.