Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


getStyle returns auto when value exists #2518

holodyn opened this Issue · 14 comments

7 participants


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


This is vendor bug. Try add css position (other than static) to the element.

@ibolmo ibolmo added this to the 1.5.1 milestone
@ibolmo ibolmo added the bug label

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 =; = 'relative';
    var parents = ele.getStyle('z-index') != 'auto' ? [ele] : ele.getParents(); = inlinePosition;
            var toReset = [],
    for (var i = 0; i < parents.length; i++) {
        var el = parents[i];
        if (el.getStyle('z-index') == 'auto') {
            var inlinePosition =;
   = 'relative';
            if (el.getStyle('z-index') != 'auto') {
                definedParent = el;
            if (i > 0) parents[i - 1].style.zIndex = 'inherit';
            toReset[i] = {
                index: i,
                positionToRestore: inlinePosition
        } else {
            definedParent = el;
    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.


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.


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


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.


Thanks for the insights @gonchuki!

@arian arian closed this
@arian arian added wontfix and removed bug labels

@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)


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


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


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.


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


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

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 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)


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);
    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
Something went wrong with that request. Please try again.