getStyle returns auto when value exists #2518

Closed
holodyn opened this Issue Aug 7, 2013 · 14 comments

Comments

Projects
None yet
7 participants
@holodyn

holodyn commented Aug 7, 2013

zIndex value not being returned properly in Chrome 28.0.1500.95 m
Mootools v1.4.5

On element:
Request: $(el).getStyle('z-index') and $(el).getStyle('zIndex') Both return INCORRECTLY: auto Request: $(el).getStyle('fontWeight') Returns CORRECTLY: bold

@sitorush

This comment has been minimized.

Show comment Hide comment
@sitorush

sitorush Sep 9, 2013

This is vendor bug. Try add css position (other than static) to the element. http://yagudaev.com/posts/getting-reliable-z-index-cross-browser/

sitorush commented Sep 9, 2013

This is vendor bug. Try add css position (other than static) to the element. http://yagudaev.com/posts/getting-reliable-z-index-cross-browser/

@ibolmo ibolmo added this to the 1.5.1 milestone Mar 3, 2014

@ibolmo ibolmo added the bug label Mar 3, 2014

@SergioCrisostomo

This comment has been minimized.

Show comment Hide comment
@SergioCrisostomo

SergioCrisostomo Mar 25, 2014

Member

This problem happens when the CSS position is not defined. This is not MooTools related but maybe MooTools could provide a fix for this(?).

I made a a fiddle with the problem, adapted from @sitorush 's link.

One idea could be something like this:

function zIndexGetter(ele) {
        var inlinePosition = ele.style.position;
    ele.style.position = 'relative';
    var parents = ele.getStyle('z-index') != 'auto' ? [ele] : ele.getParents();
    ele.style.position = inlinePosition;
            var toReset = [],
        definedParent;
    for (var i = 0; i < parents.length; i++) {
        var el = parents[i];
        if (el.getStyle('z-index') == 'auto') {
            var inlinePosition = el.style.position;
            el.style.position = 'relative';
            if (el.getStyle('z-index') != 'auto') {
                definedParent = el;
                break;
            }
            if (i > 0) parents[i - 1].style.zIndex = 'inherit';
            toReset[i] = {
                index: i,
                positionToRestore: inlinePosition
            };
        } else {
            definedParent = el;
            break;
        }
    }
    toReset.each(function () {
        parents[this.index] = this.positionToRestore;
    });
    return definedParent.getStyle('z-index');
}

jsFiddle example here. This works on IE8+, Chrome, FF and Safari 7.

If more people think this is worth a try I can sleep on it and make a better version.

Member

SergioCrisostomo commented Mar 25, 2014

This problem happens when the CSS position is not defined. This is not MooTools related but maybe MooTools could provide a fix for this(?).

I made a a fiddle with the problem, adapted from @sitorush 's link.

One idea could be something like this:

function zIndexGetter(ele) {
        var inlinePosition = ele.style.position;
    ele.style.position = 'relative';
    var parents = ele.getStyle('z-index') != 'auto' ? [ele] : ele.getParents();
    ele.style.position = inlinePosition;
            var toReset = [],
        definedParent;
    for (var i = 0; i < parents.length; i++) {
        var el = parents[i];
        if (el.getStyle('z-index') == 'auto') {
            var inlinePosition = el.style.position;
            el.style.position = 'relative';
            if (el.getStyle('z-index') != 'auto') {
                definedParent = el;
                break;
            }
            if (i > 0) parents[i - 1].style.zIndex = 'inherit';
            toReset[i] = {
                index: i,
                positionToRestore: inlinePosition
            };
        } else {
            definedParent = el;
            break;
        }
    }
    toReset.each(function () {
        parents[this.index] = this.positionToRestore;
    });
    return definedParent.getStyle('z-index');
}

jsFiddle example here. This works on IE8+, Chrome, FF and Safari 7.

If more people think this is worth a try I can sleep on it and make a better version.

@gonchuki

This comment has been minimized.

Show comment Hide comment
@gonchuki

gonchuki Mar 25, 2014

Contributor

Since MooTools uses getComputedStyle to gather the applied styles, I see no reason for this workaround. If getComputedStyle is returning auto then there's a good reason for it and we should trust what the browser returned in this case because that's what the browser is using internally when rendering the different layers.

Contributor

gonchuki commented Mar 25, 2014

Since MooTools uses getComputedStyle to gather the applied styles, I see no reason for this workaround. If getComputedStyle is returning auto then there's a good reason for it and we should trust what the browser returned in this case because that's what the browser is using internally when rendering the different layers.

@SergioCrisostomo

This comment has been minimized.

Show comment Hide comment
@SergioCrisostomo

SergioCrisostomo Mar 25, 2014

Member

@gonchuki, yes, sure. We either close this issue or find a fix for it. Since it was still open I just made a suggestion. Still if a element has defined z-index and getter returns auto something is wrong.

Member

SergioCrisostomo commented Mar 25, 2014

@gonchuki, yes, sure. We either close this issue or find a fix for it. Since it was still open I just made a suggestion. Still if a element has defined z-index and getter returns auto something is wrong.

@gonchuki

This comment has been minimized.

Show comment Hide comment
@gonchuki

gonchuki Mar 25, 2014

Contributor

no, it's returning auto because the browser hasn't applied your z-index (due to the element lacking a non-static position), so there's nothing to fix here.

The idea of getStyle is to fix inconsistencies across browsers, but it should not return values that the browser is not applying to an element.

Contributor

gonchuki commented Mar 25, 2014

no, it's returning auto because the browser hasn't applied your z-index (due to the element lacking a non-static position), so there's nothing to fix here.

The idea of getStyle is to fix inconsistencies across browsers, but it should not return values that the browser is not applying to an element.

@arian

This comment has been minimized.

Show comment Hide comment
@arian

arian Mar 25, 2014

Member

Thanks for the insights @gonchuki!

Member

arian commented Mar 25, 2014

Thanks for the insights @gonchuki!

@arian arian closed this Mar 25, 2014

@arian arian added wontfix and removed bug labels Mar 25, 2014

@SergioCrisostomo

This comment has been minimized.

Show comment Hide comment
@SergioCrisostomo

SergioCrisostomo Mar 25, 2014

Member

@gonchuki , yeah, nice to have your insight here!

Have one more doubt, in this case should getStyle return 100 for A1 or is auto the correct value (although z-index for A1's parent is > B)

Member

SergioCrisostomo commented Mar 25, 2014

@gonchuki , yeah, nice to have your insight here!

Have one more doubt, in this case should getStyle return 100 for A1 or is auto the correct value (although z-index for A1's parent is > B)

@SergioCrisostomo

This comment has been minimized.

Show comment Hide comment
@SergioCrisostomo

SergioCrisostomo Mar 25, 2014

Member

@gonchuki, found my answer, so I am also settled with this issue now.
Thank you again for input in this!

From W3C:

CSS value: auto
The stack level of the generated box in the current stacking context is 0. The box does not establish a new stacking context unless it is the root element.

Member

SergioCrisostomo commented Mar 25, 2014

@gonchuki, found my answer, so I am also settled with this issue now.
Thank you again for input in this!

From W3C:

CSS value: auto
The stack level of the generated box in the current stacking context is 0. The box does not establish a new stacking context unless it is the root element.

@holodyn

This comment has been minimized.

Show comment Hide comment
@holodyn

holodyn Mar 25, 2014

@gonchuki This was reported because in Chrome MooTools was returning a different value. While "auto" is a valid value, the zIndex in this case was not "auto" in all browsers. If getStyle is intended to fix inconsistencies as you suggest, then this would be a case where the fix is not taking place While I appreciate the argument that an incorrectly defined "position" may affect output, the MooTools getStyle function should be resolving this conflict. I believe @sitorush hit the nail on the head.

holodyn commented Mar 25, 2014

@gonchuki This was reported because in Chrome MooTools was returning a different value. While "auto" is a valid value, the zIndex in this case was not "auto" in all browsers. If getStyle is intended to fix inconsistencies as you suggest, then this would be a case where the fix is not taking place While I appreciate the argument that an incorrectly defined "position" may affect output, the MooTools getStyle function should be resolving this conflict. I believe @sitorush hit the nail on the head.

@gonchuki

This comment has been minimized.

Show comment Hide comment
@gonchuki

gonchuki Mar 25, 2014

Contributor

I might be getting lost here, but the thing is: is Chrome applying the z-index on a static element? If the answer is "no", then auto is a correct value for getStyle.

What I'm trying to highlight here is that if what the browser is rendering matches with what getComputedStyle returns, then there's nothing to fix.

Contributor

gonchuki commented Mar 25, 2014

I might be getting lost here, but the thing is: is Chrome applying the z-index on a static element? If the answer is "no", then auto is a correct value for getStyle.

What I'm trying to highlight here is that if what the browser is rendering matches with what getComputedStyle returns, then there's nothing to fix.

@holodyn

This comment has been minimized.

Show comment Hide comment
@holodyn

holodyn Mar 25, 2014

@gonchuki Unfortunately I do not have the original code for testing but I think we're on the same page, just disagree on the conclusion. In the example from sitorush you can test the conflict in Chrome vs FF or IE. As you indicate, the position is implicitly "static" and Chrome is reporting "auto" to the Mootools properly request. I would argue that regardless the case, getStyle should return the same value in all browsers. Since FF and IE allow the value to persist, so should Mootools sanitize the value for Chrome.

holodyn commented Mar 25, 2014

@gonchuki Unfortunately I do not have the original code for testing but I think we're on the same page, just disagree on the conclusion. In the example from sitorush you can test the conflict in Chrome vs FF or IE. As you indicate, the position is implicitly "static" and Chrome is reporting "auto" to the Mootools properly request. I would argue that regardless the case, getStyle should return the same value in all browsers. Since FF and IE allow the value to persist, so should Mootools sanitize the value for Chrome.

@SergioCrisostomo

This comment has been minimized.

Show comment Hide comment
@SergioCrisostomo

SergioCrisostomo Mar 25, 2014

Member

I follow this discussion with no opinion, just sure that I will learn from it!

I posted above a fiddle with the Mootools version of the link @sitorush posted. This gives:

// Chrome
Example 1 z-index = 'auto', expected = 4
Example 2 z-index = 'auto', expected = 4

// IE & FF
Example 1 z-index = '4', expected = 4
Example 2 z-index = 'auto', expected = 4
Member

SergioCrisostomo commented Mar 25, 2014

I follow this discussion with no opinion, just sure that I will learn from it!

I posted above a fiddle with the Mootools version of the link @sitorush posted. This gives:

// Chrome
Example 1 z-index = 'auto', expected = 4
Example 2 z-index = 'auto', expected = 4

// IE & FF
Example 1 z-index = '4', expected = 4
Example 2 z-index = 'auto', expected = 4
@kentaromiura

This comment has been minimized.

Show comment Hide comment
@kentaromiura

kentaromiura Mar 25, 2014

Member

I concur with @gonchuki, if the browser computes the value as 'auto' it means it uses that value, and MooTools should return 'auto' so any developer can apply his own logic and choose what to do basing on real value and not made up values.

Besides since the element.style.zIndex returns '' if the value has been set via css there's no way of fixing this (without reading the css through document.styleSheets and implementing a css parser to know which rules applies to the element)

Member

kentaromiura commented Mar 25, 2014

I concur with @gonchuki, if the browser computes the value as 'auto' it means it uses that value, and MooTools should return 'auto' so any developer can apply his own logic and choose what to do basing on real value and not made up values.

Besides since the element.style.zIndex returns '' if the value has been set via css there's no way of fixing this (without reading the css through document.styleSheets and implementing a css parser to know which rules applies to the element)

@holodyn

This comment has been minimized.

Show comment Hide comment
@holodyn

holodyn Mar 26, 2014

The real crime here is the browsers caching the value differently. I've created a fiddle that overlays a simple switch on the getStyle function, forcing an "auto" result whenever the position is static (inherited or not).

Element.implement('getStyleCore', Element.prototype.getStyle);
Element.implement('getStyle',function(name){
    if( String(name).match(/^(z|z-)index/i) 
       && this.getStyleCore('position')=='static' ) 
        return 'auto';
    return this.getStyleCore(name);
});

holodyn commented Mar 26, 2014

The real crime here is the browsers caching the value differently. I've created a fiddle that overlays a simple switch on the getStyle function, forcing an "auto" result whenever the position is static (inherited or not).

Element.implement('getStyleCore', Element.prototype.getStyle);
Element.implement('getStyle',function(name){
    if( String(name).match(/^(z|z-)index/i) 
       && this.getStyleCore('position')=='static' ) 
        return 'auto';
    return this.getStyleCore(name);
});
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment