Using all four positioning parameters with position:absolute - is this acceptable?

I provided this idea for providing overlay CSS, as an answer to another question. I hadn't thought of using this type of syntax in the past but I can't think of any problems that might be associated with using it.

As far a开发者_如何转开发s I can tell this works - and if admissible I think it provides an innovative solution - but I don't see it used often.

Could someone explain to me why it might be bad?

.ui-widget-overlay { 
  position: absolute;
  top: 0;
  left: 0;
  right: 0;
  bottom: 0;

  background-color: #444;

  /* add some opacity here */
} 

---

The branching is this based the spec for non-replaced elements ( a div is a non-replaced element ):

If all three of 'left', 'width', and 'right' are 'auto': First set any 'auto' values for 'margin-left' and 'margin-right' to 0. Then, if the 'direction' property of the element establishing the static-position containing block is 'ltr' set 'left' to the static position and apply rule number three below; otherwise, set 'right' to the static position and apply rule number one below.

( since all 3 properties are not auto, the above condition is not met )

If none of the three is 'auto': If both 'margin-left' and 'margin-right' are 'auto', solve the equation under the extra constraint that the two margins get equal values, unless this would make them negative, in which case when direction of the containing block is 'ltr' ('rtl'), set 'margin-left' ('margin-right') to zero and solve for 'margin-right' ('margin-left'). If one of 'margin-left' or 'margin-right' is 'auto', solve the equation for that value. If the values are over-constrained, ignore the value for 'left' (in case the 'direction' property of the containing block is 'rtl') or 'right' (in case 'direction' is 'ltr') and solve for that value.

( since width is auto, the above condition is not met )

Otherwise, set 'auto' values for 'margin-left' and 'margin-right' to 0, and pick the one of the following six rules that applies.

( the above condition is met )

And so we're left with these 6:

1. 'left' and 'width' are 'auto' and 'right' is not 'auto', then the width is shrink-to-fit. Then solve for 'left'

2. 'left' and 'right' are 'auto' and 'width' is not 'auto', then if the 'direction' property of the element establishing the static-position containing block is 'ltr' set 'left' to the static position, otherwise set 'right' to the static position. Then solve for 'left' (if 'direction is 'rtl') or 'right' (if 'direction' is 'ltr').

3. 'width' and 'right' are 'auto' and 'left' is not 'auto', then the width is shrink-to-fit . Then solve for 'right'

4. 'left' is 'auto', 'width' and 'right' are not 'auto', then solve for 'left'

5. 'width' is 'auto', 'left' and 'right' are not 'auto', then solve for 'width'

6. 'right' is 'auto', 'left' and 'width' are not 'auto', then solve for 'right'

Based on the above the width in that element is auto and so if you specify a left and right it solves for width, so it should be valid.

So while it is completely valid per the CSS2.1/CSS3 spec, it fails to work in IE6. It works in IE7, IE8, Firefox 3 and Chrome.

---

Your solution does not work with images, iframes and other replaced elements.

This is because the CSS standard imposes a different dimension calculation mechanism on replaced elements. (Boring specs: http://www.w3.org/TR/CSS21/visudet.html#abs-replaced-width)

---

I guess the question to ask is what benefit is there by using your solution over this:

.ui-widget-overlay { 
  position: absolute;
  top: 0;
  left: 0;
  width: 100%; 
  height: 100%
} 

Which is more compatible and easier to read. While yours is a more innovative solution, it seems like unexpected CSS behavior to set an element's width/height by setting its bounds, and browser implementation may change for this case in the future.