Enhancement refactor element.style #2414

Closed
wants to merge 3 commits into
from

Conversation

Projects
None yet
3 participants
@ibolmo
Member

ibolmo commented Aug 22, 2012

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

This comment has been minimized.

Show comment Hide comment
@ibolmo

ibolmo Aug 22, 2012

Member

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

Member

ibolmo commented Aug 22, 2012

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

+
+ property = (property == 'float') ? floatName : property.camelCase();
+
+ var getter = getGetter(property);

This comment has been minimized.

Show comment Hide comment
@arian

arian Aug 22, 2012

Member

there isn't a getGetter function yet.

@arian

arian Aug 22, 2012

Member

there isn't a getGetter function yet.

This comment has been minimized.

Show comment Hide comment
@ibolmo

ibolmo Aug 22, 2012

Member

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

@ibolmo

ibolmo Aug 22, 2012

Member

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

@@ -213,23 +200,232 @@ Element.Styles = new Hash(Element.Styles);
//</1.2compat>
-Element.ShortStyles = {margin: {}, padding: {}, border: {}, borderWidth: {}, borderStyle: {}, borderColor: {}};
+Element.Styles = {
+ left: {map: '@px'},

This comment has been minimized.

Show comment Hide comment
@arian

arian Aug 22, 2012

Member

why not keep left: '@px' by default, only for special cases use an object. Is smaller and probably better for backward compat.

@arian

arian Aug 22, 2012

Member

why not keep left: '@px' by default, only for special cases use an object. Is smaller and probably better for backward compat.

This comment has been minimized.

Show comment Hide comment
@ibolmo

ibolmo Aug 22, 2012

Member

We could reduce this by adding more logic to the getGetter, getMap, and getStyle, but I'm also trying to encourage a simple hook mechanism. See the following comment.

@ibolmo

ibolmo Aug 22, 2012

Member

We could reduce this by adding more logic to the getGetter, getMap, and getStyle, but I'm also trying to encourage a simple hook mechanism. See the following comment.

This comment has been minimized.

Show comment Hide comment
@ibolmo

ibolmo Aug 22, 2012

Member

oh and there is a simple byte reduction I had thought of, but I'm not implementing yet. give me your 2c:

'left,top,bottom,right,width,height,letterSpacing,lineHeight,...'.split(',').forEach(function(property){
    Element.Styles[property] = {map: '@px'};
});
@ibolmo

ibolmo Aug 22, 2012

Member

oh and there is a simple byte reduction I had thought of, but I'm not implementing yet. give me your 2c:

'left,top,bottom,right,width,height,letterSpacing,lineHeight,...'.split(',').forEach(function(property){
    Element.Styles[property] = {map: '@px'};
});

This comment has been minimized.

Show comment Hide comment
@ibolmo

ibolmo Aug 22, 2012

Member

Even further:

{
  '@px': 'left,top,bottom,right,width,height,letterSpacing,lineHeight,...',
  '@': 'zIndex',
  ...
}

And just have the initializer code once.
@ibolmo

ibolmo Aug 22, 2012

Member

Even further:

{
  '@px': 'left,top,bottom,right,width,height,letterSpacing,lineHeight,...',
  '@': 'zIndex',
  ...
}

And just have the initializer code once.
@arian

This comment has been minimized.

Show comment Hide comment
@arian

arian Aug 22, 2012

Member
+ textIndent: {map: '@px'},
+ opacity: {
+ map: '@',
+ get: function(element){

This comment has been minimized.

Show comment Hide comment
@arian

arian Aug 22, 2012

Member
get: getOpacity,
set: setOpacity

should be able to handle it..

@arian

arian Aug 22, 2012

Member
get: getOpacity,
set: setOpacity

should be able to handle it..

This comment has been minimized.

Show comment Hide comment
@ibolmo

ibolmo Aug 22, 2012

Member

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

@ibolmo

ibolmo Aug 22, 2012

Member

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

+ opacity: {
+ map: '@',
+ get: function(element){
+ return getOpacity(this);

This comment has been minimized.

Show comment Hide comment
@arian

arian Aug 22, 2012

Member

also you're using this here, instead of element.

@arian

arian Aug 22, 2012

Member

also you're using this here, instead of element.

This comment has been minimized.

Show comment Hide comment
@ibolmo

ibolmo Aug 22, 2012

Member

right, forgot to update. nice catch

@ibolmo

ibolmo Aug 22, 2012

Member

right, forgot to update. nice catch

+
+// todo(ibolmo): collisions?
+
+if (hasBackgroundPositionXY){

This comment has been minimized.

Show comment Hide comment
@arian

arian Aug 22, 2012

Member

maybe also move the feature detections here, closer where it's actually used.

@arian

arian Aug 22, 2012

Member

maybe also move the feature detections here, closer where it's actually used.

This comment has been minimized.

Show comment Hide comment
@ibolmo

ibolmo Aug 22, 2012

Member

agreed

@ibolmo

ibolmo Aug 22, 2012

Member

agreed

@arian

This comment has been minimized.

Show comment Hide comment
@arian

arian Aug 22, 2012

Member

Nice work, good start! 👍

Member

arian commented Aug 22, 2012

Nice work, good start! 👍

+ result = [];
+ for (var s in Element.ShortStyles[property]) result.push(this.getStyle(s));
+ return result.join(' ');
+ } else {

This comment has been minimized.

Show comment Hide comment
@gonchuki

gonchuki Aug 22, 2012

Contributor

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?

@gonchuki

gonchuki Aug 22, 2012

Contributor

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?

This comment has been minimized.

Show comment Hide comment
@ibolmo

ibolmo Aug 22, 2012

Member

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?

@ibolmo

ibolmo Aug 22, 2012

Member

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?

This comment has been minimized.

Show comment Hide comment
@gonchuki

gonchuki Aug 22, 2012

Contributor

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

gonchuki Aug 22, 2012

Contributor

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)

This comment has been minimized.

Show comment Hide comment
@gonchuki

gonchuki Aug 28, 2012

Contributor

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.

@gonchuki

gonchuki Aug 28, 2012

Contributor

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

This comment has been minimized.

Show comment Hide comment
@ibolmo

ibolmo Aug 22, 2012

Member

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.
Member

ibolmo commented Aug 22, 2012

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

This comment has been minimized.

Show comment Hide comment
@ibolmo

ibolmo Jul 2, 2014

Member

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

Member

ibolmo commented Jul 2, 2014

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

@ibolmo ibolmo closed this Jul 2, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment