22

Considering:

  • For elements that are absolutely positioned inside a relatively positioned container.
  • If you want the element to fill the width of the container.
  • The element is also bottom-aligned.

enter image description here

Is it best for maximum browser compatibility to set a width in pixels for the element, or simply use left and right?

Any common bugs to watch out for with either method?

Clearly, using left: 0; and right: 0; would make the code more manageable in cases where the image's width or padding were to change, but are there any downsides where width: 300px would be favorable instead?

Baumr
  • 6,124
  • 14
  • 37
  • 63
  • 4
    Using `left: 0` and `right: 0` will work in every browser, except IE6 (and IE7 without the correct doctype). I'd say go with `left` and `right`, since it's easier to maintain the code in the long run (for example changing the size of the container). – BenM Apr 12 '13 at 13:14
  • 2
    I wouldn't worry about IE6 support anymore... – Xarcell May 17 '13 at 05:05
  • A lot of people still are forced to use IE6 at work, so it really depends on the implementation and target audience – Baumr May 17 '13 at 18:48

4 Answers4

16

Historically we learnt to use width instead of left & right because IE6 didn't support at the same time the two properties of the same axis

<div style="top:0;bottom:0;position:absolute;">modern browsers</div>

<div style="top:0;height:100%;position:absolute;">MSIE6</div>

<div style="left:0;right:0;position:absolute;">modern browsers</div>

<div style="left:0;width:100%;position:absolute;">MSIE6</div>

<div style="left:0;right:0;top:0;bottom:0;position:absolute;">modern browsers</div>

<div style="left:0;top:0;height:100%;width:100%;position:absolute;">MSIE6</div>

Also, this technique will not work on some elements (including on modern browsers, by spec )

<!-- these will not work -->
<!-- edit: on some browsers they may work,
but it's not standard, so don't rely on this -->

<iframe src="" style="position:absolute;top:0;bottom:0;left:0;right:0;"></iframe>

<textarea style="position:absolute;top:0;bottom:0;left:0;right:0;"></textarea>

<input type="text" style="position:absolute;left:0;right:0;">

<button ... ></button>

and possibly others... (some of these can't even be display:block)

But, analysing what happens in the normal static flow using the width:auto property

<div style="width:auto;padding:20px;margin:20px;background:lime;">a</div>

You will see it's very similar to...

<div style="width:auto;padding:20px;margin:20px;background:lime;
    position:absolute;top:0;left:0;bottom:0;right:0;">b</div>

... same properties with the same values! This is really nice! Otherwise it will look like:

<div style="width:100%;height:100%;
    position:absolute;top:0;left:0;">
    <div style="padding:20px;margin:20px;
        background:lime;">c</div>
</div>

Which is also different, because the inner div doesn't fill the y axis. To fix this we will need css calc() or box-sizing and an unnecessary headache.


My answer is, left + right | top + bottom are really cool since they are closest to the static positioning's width:auto and there is no reason to not use them. They are way easier to use compared to the alternative and they provide much more functionality (for example, using margin-left, padding-left and left at the same time in one single element).

left + right | top + bottom is considerably better supported by browsers compared to the alternative width:100% + box-sizing | calc() and it's also easier to use!

Of course if you don't need (as in your example) to grow the element also in the y axis, width:100% using some nested element for the padding, it's the only solution to archive support also for MSIE6

So, depends by your needs. If you want to support MSIE6 (it's the only actual reason to do that) you should use with:100%, otherwise use left + right!

Hoping to be helpful.

  • 1
    Would you mind explaining which part of the spec you linked to provides information about these elements that will not fill out the parent with only absolute coordinates specified? I had trouble understanding how the linked sentences lead to your list of elements. – davidtheclark Dec 07 '13 at 18:13
0

Both methods are fine, but if you want your design to be responsive or mobile phone compatible - I would recommend using Left: and Bottom: if the container is not enclosed in <div>.

If it is enclosed in a <div> then doing it with width: 100% ormax-width: 200px is a way in my opinion that causes least display problems.

Avoid using fixed widths in CSS if you want your theme to be responsive.

Arts Fantasy
  • 157
  • 2
  • 6
-1

Both of the solution is working in every browser without any problems. In these cases I like to add a width: 100%; left: 0; bottom: 0; for the element, but if you like left:0;right:0; bottom:0; more, than you can use that, too.

Seer
  • 739
  • 4
  • 22
  • 2
    Specifying `width: 100%` without a box-sizing method would cause the element to become increased in size when a padding is applied. – BenM Apr 12 '13 at 13:21
  • I think that was not the part of the question – Seer Apr 12 '13 at 13:25
  • 1
    *Clearly, using left: 0; and right: 0; would make the code more manageable in cases where the image's width **or padding** were to change* – BenM Apr 12 '13 at 13:26
  • @Seer, are you sure about "every browser"? I should have maybe made it clearer: all major browser releases, to which [BenM's suggestion disagrees](http://stackoverflow.com/questions/15972192/css-positioning-to-fill-container-width-vs-left-right/15972598?noredirect=1#comment22766609_15972192) – Baumr Apr 12 '13 at 14:10
  • @Baumr, that's right, _all major browser_ is more correct than _every browser_. But I think this is only a 'logic-chopper' thing, _every browser_ should mean _every browser in which a developer needs to check the site_. And this doesn't include IE6, nor IE7. – Seer Apr 12 '13 at 14:39
  • 1
    @Seer, I don't want to go into the debate, but you can't categorically discount IE6/7 — it depends on each individual website's traffic – Baumr Apr 12 '13 at 14:56
  • @Baumr, correct. Everybody can decide if is it worth to work more, or a lot more when the usage of IE6 is 0.2% and IE7 is 0.8%. And I think the half of these numbers are only developers, who checks the sites in old browsers to see if it is working or not :) Anyway, I think we are a little bit off topic. And I agree with you what you wrote above in your comment for Khanh To. – Seer Apr 12 '13 at 15:03
-1

I haven't tested this on all browsers (and modes) but for the IE quirks mode (e.g. in an .HTA without !DOCTYPE defined), I have created a subroutine that corrects the WIDTH or HEIGHT on elements where the LEFT/RIGHT style or the TOP/BOTTOM style are set (not “auto”). To avoid going in to all kind of unit conversions, the routine temporary removes the LEFT (or TOP) style and sets the WIDTH (or HEIGHT) to 100% to determine the RIGHT (or BOTTOM) offset in pixels.

The script is written in VBScript, but it should be do difficult to translate the idea to JavaScript.

<html>
<head>
    <script language="VBScript">

Option Explicit

Sub Justify(ByVal hElement)

    Dim sStyleTop, iTop, iBottom, sStyleLeft, iLeft, iRight

    With hElement
        If .currentStyle.top <> "auto" And .currentStyle.height = "auto" And .currentStyle.bottom <> "auto" Then
            iTop = .offsetTop
            sStyleTop = .currentStyle.top
            .style.top = "auto"
            .style.height = "100%"
            iBottom = -.offsetTop 
            .style.height = .offsetHeight - iTop - iBottom & "px"
            .style.top = sStyleTop
        End If
        If .currentStyle.left <> "auto" And .currentStyle.width = "auto" And .currentStyle.right <> "auto" Then
            iLeft = .offsetLeft
            sStyleLeft = .currentStyle.left
            .style.left = "auto"
            .style.width = "100%"
            iRight = -.offsetLeft 
            .style.width = .offsetWidth - iLeft - iRight & "px"
            .style.left = sStyleLeft
        End If
        For Each hElement In .Children
            Justify hElement
        Next
    End With

End Sub

Sub window_onload

    Justify Document.body

End Sub

    </script>
    <style type="text/css">
    body {
        position:absolute;
        width:100%;
        height:100%;
    }
    #outer{
        background:blue;
        position:absolute;
        top:10px;
        right:20px;
        bottom:30px;
        left:40px;
    }
    #inner{
        background:green;
        position:absolute;
        top:40px;
        right:30px;
        bottom:20px;
        left:10px;
    }
    </style>
</head>
<body>
    <div id="outer">
        <div id="inner">
        </div>
    </div>
</body>
</html>

The command to justify all elements in a document is:

Justify Document.body

I am invoking this from the onload event as it concerns a fixed size .HTA in my case but I expect the routine also to work on the onsize event for sizable windows (or parent elements).

iRon
  • 20,463
  • 10
  • 53
  • 79
  • 1
    Welcome to SO! Did you mistakenly post your answer on the wrong question? – Baumr Jul 10 '13 at 12:06
  • Why?, I think this answers the expectation that when you predefine the left and the right (or top and bottom) with CSS, the width (or height) should be calculated by the browser. – iRon Jul 10 '13 at 12:11
  • I didn't down-vote, but please [refer to my questions](http://stackoverflow.com/q/15972192/1779823) and [SO guidelines](http://stackoverflow.com/help/how-to-answer) — hope that helps? – Baumr Jul 10 '13 at 12:12
  • It indirectly answeres "_are there any downsides where width: 300px would be favorable instead?_": Yes, where you can't predict the width of the Window or parent element and want to have both left and right 'fixed' aligned. It is actually an answere for situations where you "_would make the code more manageable_". – iRon Jul 10 '13 at 12:23
  • Please refer to the SO guidelines, answers should address questions directly. Also, for the record, adding VBScript or JavaScript to achieve a simple layout is excessive for this CSS question. I wouldn't say it makes code more manageable; though I appreciate you trying — thank you – Baumr Jul 10 '13 at 13:31