SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 32
  1. #1
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Modern UAs - Expected Improvements

    HTML5. CSS3. These are hot topics. Because of the novelty. But I feel there are a few things left browsers need to fix before engaging in a competition over who better supports these two.

    What interests me at this point is put in this honest question: "Are the modern UAs living up to their fame?" We know everybody's saying: "Die IE6, die!" and we know some UAs complain about the lack of attention they get. But, these modern UAs, are they all really a force to be reckon, or are they just an ongoing modern vogue?

    HTML5. CSS3. These are hot topics. If providing support for them is going to bring changes to the basic core of the way modern UAs is helping me with my coding, I'm all for it. If not, I say UAs can wait a little longer on these and start fixing the base.

    A series of practical tests, using real life situations developers are asked to solve, those are going to shed light on their capabilities, more than any other made up (or not), partially (or not) test. UAs new versions rain upon us, but is this raining bringing any improvement to help our coding? With that in mind, let's start the practicals!

  2. #2
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    #1: % to px



    Short Version




    Long Version
    In order to test how UAs transform % in px, I've made a simple box arangment: one box at the top, one box at the bottom, three boxes in the middle. The three boxes in the middle will have the 100% width divided among them: 33%, 49% and 18%. You can see it here:
    HTML Code:
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
       "http://www.w3.org/TR/html4/strict.dtd">
    <html lang="en" dir="ltr"><head>
    
      <meta	http-equiv="Content-Type" content="text/html; charset=utf-8">
      <meta	http-equiv="Content-Language" content="en">
    
      <style type="text/css">  
    
        body { 
          margin:1em; 
          border:0; 
          background:gray; 
          }
        
        div { 
          margin:0; 
          border:0; 
          }
        
        h2 { 
          margin:2em 0 0 2em; 
          text-decoration:underline; 
          }
        
        .short, .long { 
          border:1px solid white; 
          }
        
        .short { width:350px; }
        
        .long { width:616px; }
        
          .floats .main { 
            overflow:auto; 
            }
              
              .main div { 
                height:100%; 
                }
              
              .header { 
                background:yellow; 
                }
              
              .floats .main div { 
                float:left; 
                }
              
              .inlineblocks .main div { 
                display:inline-block; 
                vertical-align:top; 
                }
                
                .ms1 { 
                  width:33%; 
                  background:red; 
                  }
                
                .ms2 { 
                  width:49%; 
                  background:white; 
                  }
                
                .ms3 { 
                  width:18%; 
                  background:cyan; 
                  }
              
              .footer { 
                background:yellow; 
                }
        
      </style>
    
    </head><body>
        <h1>Floats vs. Inline Blocks: % to px</h1>
        <h2>1st test</h2>
        <h3>Floats</h3>
    
     
        <div class="short floats">
          <div class="header">
            header div
          </div>
    
          
          <div class="main">
          
            <div class="ms1">
              a floated div here
            </div>
            <div class="ms2">
              div floated
            </div>
            <div class="ms3">
              another floated div
            </div>
            
          </div>
    
          
          <div class="footer">
            footer div
          </div>
        </div>
      
      
    
      <h3>Inline Blocks</h3>
      
      
      <div class="short inlineblocks">
        <div class="header">
          header div
        </div>
    
        
        <div class="main">
        
          <div class="ms1">
            an inline block div here
          
          </div><div class="ms2">
            div inline block
          
          </div><div class="ms3">
            another inline block div
          </div>
          
        </div>
    
        
        <div class="footer">
          footer div
        </div>
      </div>
    
    
      <h2>2nd test</h2>
      <h3>Floats</h3>
      
      
    
      <div class="long floats">
        <div class="header">
          header div
        </div>
    
        
        <div class="main">
        
          <div class="ms1">
            a floated div here
          </div>
          <div class="ms2">
            div floated
          </div>
          <div class="ms3">
            another floated div
          </div>
          
        </div>
    
        
        <div class="footer">
          footer div
        </div>
      </div>
    
      
      
      <h3>Inline Blocks</h3>
      
      
    
      <div class="long inlineblocks">
        <div class="header">
          header div
        </div>
    
        
        <div class="main">
        
          <div class="ms1">
            an inline block div <br>here
          
          </div><div class="ms2">
            div inline block
          
          </div><div class="ms3">
            another <br>inline block <br>div
          </div>
          
        </div>
    
        
        <div class="footer">
          footer div
        </div>
      </div>
      
    
    </body></html>
    Whether we use floated boxes in the middle, or inline block boxes, the end result is identical. They behave the same way to this regard. Of course, there are some differences in the HTML and CSS.

    • HTML markup differences: html mark up for floats can have any formatting, the one for inline blocks needs a tag chaining (</div><div>) between the end tag and the start tag of two sibling elements (there may be better solutions for inline blocks, but this topic is not covered here).
      HTML Code:
      <div class="main">
      
        <div class="ms1">
          a floated div here
        </div>
        <div class="ms2">
          div floated
        </div>
        <div class="ms3">
          another floated div
        </div>
        
      </div>
      vs.
      HTML Code:
      <div class="main">
      
        <div class="ms1">
          an inline block div here
        
        </div><div class="ms2">
          div inline block
        
        </div><div class="ms3">
          another inline block div
        </div>
        
      </div>

    • CSS differences: floats parents should have an auto overflow to wrap them (any value for the overflow other than fixed will do), inline blocks should have vertical alignment set to top.
      Code CSS:
      .floats .main { 
        overflow:auto; 
        }
      [...]
      .floats .main div { 
        float:left; 
        }
      vs.
      Code CSS:
      .inlineblocks .main div { 
        display:inline-block; 
        vertical-align:top; 
        }


    Aside from an obvious floats vs. inline blocks definitions difference, so far, we have the same behaviour between floats and inline blocks. Let's see how modern UAs manage the % to px conversion for them.


    IE 8 ( * * * * )

    1st test

    No gaps on the far left or far right edges. Overlapping hidden.

    Floats: three div elements: 33% (116px), 49% (172px), 18% (63px). Total: 351px (>100%).

    Inline blocks: three div elements: 33% (116px), 49% (172px), 18% (63px). Total: 351px (>100%).

    % to px: Imperfect, but a good alignment with the parent's vertical edges!

    2nd test

    No gaps on the far left or far right edges. Rounding up perfectly.

    Floats: three div elements: 33% (203px), 49% (302px) and 18% (111px). Total: 616px (100%).

    Inline blocks: three div elements: 33% (203px), 49% (302px) and 18% (111px). Total: 616px (100%).

    % to px: Perfect!



    FF 3.6.12 ( * * * * )

    1st test

    No gaps on the far left or far right edges. Overlapping hidden.

    Floats: three div elements: 33% (115.5px = 116px), 49% (171.5px = 172px), 18% (63px). Total: 351px (>100%).

    Inline blocks: three div elements: 33% (115.5px = 116px), 49% (171.5px = 172px), 18% (63px). Total: 351px (>100%).

    % to px: Imperfect, but a good alignment with the parent's vertical edges!

    2nd test

    No gaps on the far left or far right edges. Rounding up perfectly.

    Floats: three div elements: 33% (203.267px = 203px), 49% ( 301.833px = 302px) and 18% (110.867px = 111px). Total: 616px (100%).

    Inline blocks: three div elements: 33% (203.267px = 203px), 49% ( 301.833px = 302px) and 18% (110.867px = 111px). Total: 616px (100%).

    % to px: Perfect!



    CH 7.0.517.41 | SAF 5.0.2 ( * * * )

    1st test

    One 1px gap between the far right edge of the parent div element and the last div element.

    Floats: three div elements: 33% (115px), 49% (171px) and 18% (63px). Total: 349px (<100%).

    Inline blocks: three div elements: 33% (115px), 49% (171px) and 18% (63px). Total: 349px (<100%).

    % to px: Bad!

    2nd test

    One 2px gap between the far right edge of the parent div element and the last div element.

    Floats: three div elements: 33% (203px), 49% (301px) and 18% (110px). Total: 614px (<100%).

    Inline blocks: three div elements: 33% (203px), 49% (301px) and 18% (110px). Total: 614px (<100%).

    % to px: Bad!


    OP 10.63 ( * * * )

    1st test

    One 1px gap on the far right edge of the parent div element and the last div element.

    Floats: three div elements: 33% (115px), 49% (171px) and 18% (63px). Total: 349px (<100%).

    Inline blocks: three div elements: 33% (115px), 49% (171px) and 18% (63px). Total: 349px (<100%).

    % to px: Bad!

    2nd test

    One 2px gap on the far right edge of the parent div element and the last div element.

    Floats: three div elements: 33% (203px), 49% (301px) and 18% (110px). Total: 614px (<100%).

    Inline blocks: three div elements: 33% (203px), 49% (301px) and 18% (110px). Total: 614px (<100%).

    % to px: Bad!




    Results

    IE 8 and FF 3.6.12 are the clear winners. These UAs provide a complete fill for the parent. One thing they do wrong: not losing the ocasional extra px.

    CH 7.0.517.41, SAF 5.0.2 and OP 10.63 are indeed losers. These UAs make severe concesions when transforming % to px, making "blind" calculations. No correlation is kept with the actual width of the parent, leading to up to 2px differences.


    Going further with this experiment, I feel UAs should provide more than this sometimes missing level of basic support for simple and clear solutions. UAs should provide enhancements for mixed % and px width values for elements inside a parent.

    Let's take this scenario: a parent having a 500px width. In it, three floats or inline blocks. The first one has the width also expressed in px: 100px. That makes the total width available for the two remaining child element equal to 400px.

    Now, if I was to specify 30% for one and 70% for the last one, I would like a good UA to understand that, in my mind, this 100% = 30% + 70% actually targets the remaining 400px.

  3. #3
    Robert Wellock silver trophybronze trophy xhtmlcoder's Avatar
    Join Date
    Apr 2002
    Location
    A Maze of Twisty Little Passages
    Posts
    6,316
    Mentioned
    60 Post(s)
    Tagged
    0 Thread(s)
    So you mean HTML5 is non normative and is partly a waste of space; one step forward, two backwards?

    Yes, I can see the logic behind your thinking on that one. I also agree they should be trying to fix the bugs in the current and up-and-coming versions rather than trying to follow the latest vapour markup fad first.

  4. #4
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well put: fad. I mean chase HTML5 and CSS3, yeah. But to what purpose? Are they done with all the previous remaining homework first? It's like they try to graduate while still having failed exams.

    Some browser makers should put aside their fear of not being trendy and get serious about some basic implementations.

    All new UA versions should cut down the problems you face as a developer instead of adding more and/or leaving the old ones unresolved.

    The latest buzz is "fast&glamour" but they don't show you the price for it. What about computational correctness?

  5. #5
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,266
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Meh, this isn't the only industry doing this sort of thing. Automakers will add new features before fixing minor nuisances as well (they're kinda forced to fix major issues, otherwise they fall in the Consumer Group ratings and people won't buy their products).

  6. #6
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,269
    Mentioned
    179 Post(s)
    Tagged
    6 Thread(s)
    I kind of agree in that the basic problems we always had - we still have in some cases. These rounding errors have always been a problem and Firefox has always been better at them (and now IE has improved also). Opera is very bad and can't handle fractions of a percent at all.

    Regarding browser improvements then you are already reaping the benefits in that IE has been forced to up its game and to try and keep pace. Previously IE was the worst at rounding errors and other bugs but IE8 has improved a lot and had to improve or get left behind.

    John Allsopp also states that's it the vendor extensions that are driving the browsers current rate of change and unlike previous proprietary implementations these extensions are made public from the start and available to all for use, discussion and finally implementation into the specs. This open mindedness has seen that a lot of new features are adopted more quickly.

    Whether we need them or not is another matter

    I am quite interested in the flexible box model module though as it specifically addresses layout problems that have dogged us from day one. If that works it will change the way we code layouts and make life a lot easier.

    But I still have to agree that all the old bugs should be fixed first. I tend to still not use a lot of the newer stuff simply because I can do it without. A reduced instruction set allows you to work quicker

  7. #7
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Interesting stuff about flexible box model module. Sounds a lot like the GridBagLayout layout manager in Java AWT.

    And fixing the old bugs before even considering the above it's a very good idea. Otherwise it might just make it useless since computational correctness will be missing. The gaps would make your super cool theoretical flexible box model layout flank the CSS SATs.

  8. #8
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Welcome to why I don't use % widths on columns -- ever.

    OH, and it's broken in IE7- too... and doubly broken here in Opera and IE since I'm a large font/120dpi user. For some reason it's doubling that right side gap. (which actually should not occur since default fonts size should be unrelated).

    That or I'd float the last one right, and set the entire wrapping div to the white background not setting background on the center one...

    Or I'd move the third one before the second one, then do left, right and unfloated.

    Or I'd move the content one first, give it it's own private wrapper, and do a content first columns allowing it to be dynamic.

    Because you can't trust browsers to round the same (NOT that as a programmer I believe fractions should be preserved during render) I would NEVER try to declare percentage widths to add up to 100% in the first place. That's one of the basic rules of creating layouts.

  9. #9
    Resident curmudgeon bronze trophy gary.turner's Avatar
    Join Date
    Jan 2009
    Location
    Dallas
    Posts
    990
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by noonnope
    Let's take this scenario: a parent having a 500px width. In it, three floats or inline blocks. The first one has the width also expressed in px: 100px. That makes the total width available for the two remaining child element equal to 400px.

    Now, if I was to specify 30% for one and 70% for the last one, I would like a good UA to understand that, in my mind, this 100% = 30% + 70% actually targets the remaining 400px.
    Existing UAs do just that, even old IEs, if you provide the proper structural context. That remaining 400px must have its own block formatting context, else the 70 & 30% boxes have the 500px box as their container.

    Why would you have any expectation that the UA should follow the rules, e.g. percentage width is based on parent width, then out of nowhere suddenly read your mind and apply the rule differently?

    cheers,

    gary
    Anyone can build a usable website. It takes a graphic
    designer to make it slow, confusing, and painful to use.

    Simple minded html & css demos and tutorials

  10. #10
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by gary.turner View Post
    Why would you have any expectation that the UA should follow the rules, e.g. percentage width is based on parent width, then out of nowhere suddenly read your mind and apply the rule differently?

    cheers,

    gary
    The algorithm UAs should employ it's not based on reading my mind

    It should be based on this trigger: the use of combined fixed and proportional values.

  11. #11
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    Welcome to why I don't use % widths on columns -- ever.

    [...]

    Because you can't trust browsers to round the same (NOT that as a programmer I believe fractions should be preserved during render) I would NEVER try to declare percentage widths to add up to 100% in the first place. That's one of the basic rules of creating layouts.
    But it's the first thing an unware developer would think of doing. And. let's face it, it's the logical thing to expect from UAs.


    No, you should have trust browsers to do a decent job at it: no fraction preservation but rounding. But a "big picture aware" rounding, not a "blind" or "dumb" rounding, that should be performed in more than just one single step.

  12. #12
    Resident curmudgeon bronze trophy gary.turner's Avatar
    Join Date
    Jan 2009
    Location
    Dallas
    Posts
    990
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by noonnope View Post
    The algorithm UAs should employ it's not based on reading my mind

    It should be based on this trigger: the use of combined fixed and proportional values.
    OK, sounds reasonable. Please describe the algorithm and the test cases.

    cheers,

    gary
    Anyone can build a usable website. It takes a graphic
    designer to make it slow, confusing, and painful to use.

    Simple minded html & css demos and tutorials

  13. #13
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Will do. Just not tonight

  14. #14
    Mouse catcher silver trophy Stevie D's Avatar
    Join Date
    Mar 2006
    Location
    Yorkshire, UK
    Posts
    5,881
    Mentioned
    122 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by gary.turner View Post
    Existing UAs do just that, even old IEs, if you provide the proper structural context. That remaining 400px must have its own block formatting context, else the 70 & 30% boxes have the 500px box as their container.

    Why would you have any expectation that the UA should follow the rules, e.g. percentage width is based on parent width, then out of nowhere suddenly read your mind and apply the rule differently?
    I would rather have UAs accept calculations than to randomly change the way they derive percentages depending on whether any siblings have a width declared in px. (How would it work if it was declared in em?)

    eg
    #div1 {width:"70% - 70px";}
    #div2 {width:"30% - 30px";}

    That would be infinitely more predictable, more user-friendly and more powerful.

  15. #15
    Resident curmudgeon bronze trophy gary.turner's Avatar
    Join Date
    Jan 2009
    Location
    Dallas
    Posts
    990
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stevie D View Post
    I would rather have UAs accept calculations than to randomly change the way they derive percentages depending on whether any siblings have a width declared in px. (How would it work if it was declared in em?)

    eg
    #div1 {width:"70% - 70px";}
    #div2 {width:"30% - 30px";}

    That would be infinitely more predictable, more user-friendly and more powerful.
    If you make sure each element references an immediate parent container, it works pretty well, as is. There may be some benefit to calculations, but for me, it just hasn't come up. Maybe I subconsciously structure to avoid the need.

    test case: px, em and pct.
    Code:
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
            "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
            
    <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
    <head>
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
      <title>test document</title>
      
      <style type="text/css">
    
      div {
        padding: 10px;  /* to uncollapse margins and for clarity */
        }
    
      #px, #em, #pct {
        background-color: silver;
        display: inline-block;
        padding: 10px;
        width: 500px;
        }
    
      .boxa {
        background-color: pink;
        float: left;
        }
    
      #px .boxa {
        width: 100px;
        }
    
      #em .boxa {
        width: 6em;
        }
    
      #pct .boxa {
        width: 20%;
        }
    
      .boxb {
        background-color: lightgreen;
        overflow: hidden;
        }
    
      .boxb-1 {
        background-color: lightblue;
        float: left;
        width: 30%;
        }
    
      .boxb-2 {
        background-color: yellow;
        overflow: hidden;
        }
      </style>
      
    </head>
    <body>
      <div id="px">
        <div class="boxa">
          <p>a box of set px width</p>
        </div>
        
        <div class="boxb">
          <p>what's left after box a</p>
          <div class="boxb-1">
            <p>30% of boxb</p>
          </div>
    
          <div class="boxb-2">
            <p>70% of boxb</p>
          </div>
        </div>
      </div>
    
      <div id="em">
        <div class="boxa">
          <p>a box of set em width</p>
        </div>
        
        <div class="boxb">
          <p>what's left after box a</p>
    
          <div class="boxb-1">
            <p>30% of boxb</p>
          </div>
    
          <div class="boxb-2">
            <p>70% of boxb</p>
          </div>
        </div>
      </div>
    
      <div id="pct">
        <div class="boxa">
          <p>a box of set percentage width</p>
        </div>
        
        <div class="boxb">
          <p>what's left after box a</p>
    
          <div class="boxb-1">
            <p>30% of boxb</p>
          </div>
    
          <div class="boxb-2">
            <p>70% of boxb</p>
          </div>
        </div>
      </div>
    </body>
    </html>
    cheers,

    gary
    Anyone can build a usable website. It takes a graphic
    designer to make it slow, confusing, and painful to use.

    Simple minded html & css demos and tutorials

  16. #16
    Mouse catcher silver trophy Stevie D's Avatar
    Join Date
    Mar 2006
    Location
    Yorkshire, UK
    Posts
    5,881
    Mentioned
    122 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by gary.turner View Post
    If you make sure each element references an immediate parent container, it works pretty well, as is. There may be some benefit to calculations, but for me, it just hasn't come up. Maybe I subconsciously structure to avoid the need.
    I know you can sometimes get round it by inserting unnecessary divs that are only there to gather elements together for layout purposes - which I don't particularly like doing, and which in any case doesn't solve the ultimate problem.

    Another common case is where you want to set the width of an object - from border to border - to be a certain proportion of the page, eg 30%, but you want to include padding in px/em. Calculations would enable you to do that easily, rather than having to hack it with spurious additional nested elements.

  17. #17
    Resident curmudgeon bronze trophy gary.turner's Avatar
    Join Date
    Jan 2009
    Location
    Dallas
    Posts
    990
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    eg 30%, but you want to include padding in px/em
    That's a part of css3. Firefox, Chrome, IE9b (I didn't check <9), and Opera support it now as
    Code:
    {
    -moz-box-sizing: border-box;
    -webkit-box-sizing: border-box;
    box-sizing: border-box;
        }
    IE9 (≤8?) and Opera support it as css3; Firefox and webkit require the proprietary prefix.

    cheers,

    gary
    Anyone can build a usable website. It takes a graphic
    designer to make it slow, confusing, and painful to use.

    Simple minded html & css demos and tutorials

  18. #18
    Community Advisor silver trophybronze trophy
    dresden_phoenix's Avatar
    Join Date
    Jun 2008
    Location
    Madison, WI
    Posts
    2,791
    Mentioned
    34 Post(s)
    Tagged
    2 Thread(s)
    1] for what I see CSS (whatever) and HTML (whatever) are quite irrelevant to browser rendering. HTML is the semantic structure.

    2] Because I would have opened a whole can of worms w/o giving this it's own point: I would figure a good UA would allow you to use CSS to assign(or override) any tag's display mode. Of course this open the possibility of coders creating tags on the flag ( I always thought we ought to have a <sarcasm> tag, for example) which would make maintaining semantic standards almost impossible or at least reduce them to the honor system. So back to HMTML5 which is the NEW standard.

    3]CSS3 has no baring on RENDERING accuracy of UA's so it companies should work on all these things simultaneously, rather than sacrifice on for the other.

    4] WHAT WE REALLY NEED IS... consistency.
    Why would you have any expectation that the UA should follow the rules, e.g. percentage width is based on parent width, then out of nowhere suddenly read your mind and apply the rule differently?
    I am kinda with Gary on this... just because I have learned that the standard says an element's width set to % is calculated based on THE PARENT'S WIDTH and not "the available width in the container" . I also understand why this was done.. I mean.. what of the situation in which a web-coder assigns a % total greater than 100%? Is the UA supposed to assume we want it to shrink-to fit to 100% or that we want to drop the last element below all the others since it doesn't fit? This is impossible to predict and both scenarios have useful implementation. Either way of thinking is fine as long as it becomes standard and pixel accurate.


    And to be honest. I could have gone either way on the box-model the assigned width is absolute for the element or just the content and anything else is tacked on .. the problem was that there was no consistency... essentially "box-sizing:" marries the two mode of thinking.

  19. #19
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    My view on the inside parent division, regarding px and %. em is not accounted for.

    Classic cases
    1. What happens if a fixed width parent has child elements with only fixed values for their width?
    a) If the total width of the child elements is less than the parent width
    b) If the total width of the child elements is equal to the parent width
    c) If the total width of the child elements is greater than the parent width

    2. What happens if a relative width parent has child elements with only relative values for their widths?
    a) If the total width of the child elements is less than the parent width
    b) If the total width of the child elements is equal to the parent width
    c) If the total width of the child elements is greater than the parent width

    Classic bad(?) cases
    3. What happens if a fixed width parent has child elements with mixed values, fixed and relative, for their width?
    a) If the total width of the child elements is less than the parent width
    b) If the total width of the child elements is equal to the parent width
    c) If the total width of the child elements is greater than the parent width

    4. What happens if a relative width parent has child elements with mixed values, fixed and relative, for their width?
    a) If the total width of the child elements is less than the parent width
    b) If the total width of the child elements is equal to the parent width
    c) If the total width of the child elements is greater than the parent width


    New good(?) cases
    5. What should happen if a fixed width parent has child elements with mixed values, fixed and relative, for their width?
    a) If the total width of the child elements is less than the parent width
    b) If the total width of the child elements is equal to the parent width
    c) If the total width of the child elements is greater than the parent width

    6. What should happen if a relative width parent has child elements with mixed values, fixed and relative, for their width?
    a) If the total width of the child elements is less than the parent width
    b) If the total width of the child elements is equal to the parent width
    c) If the total width of the child elements is greater than the parent width


    Do we need to go over cases #1-#4?


    The proposed algorithm for case #5 and #6
    Very simple: when there are mixed values, fixed and relative, for child elements, regardless of the parent having its width expressed in a fixed or relative system, AFTER assigning first the fixed values, the relative values should always reference the remaining parent width (as being "the new" 100%).

    The cases where the total widths values of the child elements is less/greater than the parent width, fixed and/or relative, should be treated the same way as they are now for the cases #1 and #2.


    The essential: "inside" box model.

    When there are mixed values, fixed and relative, the fixed value should be "assigned" first. The relative value should be "assigned" last, it should only account for the remainder of the width, referenced as "the new" 100%. This "the new" 100% should not be confused with what 100% width for the parent width means "outside" child elements context. "The new" 100% only exists "inside" child elements context. 100% width for the parent will still mean a full 100% for the parent, regarding the relation the parent has with its siblings or parent elements: its "outside" box model.




    Cases #1 and #2 are pretty straight forward.
    Here's the bad(?) behaviour for cases #3 and #4:
    Code:
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
       "http://www.w3.org/TR/html4/strict.dtd">
    <html lang="en" dir="ltr"><head>
    
      <meta	http-equiv="Content-Type" content="text/html; charset=utf-8">
      <meta	http-equiv="Content-Language" content="en">
      <title>Fixed vs. Relative</title>
    
      <style type="text/css">  
    
        body { 
          margin:1em; 
          border:0; 
          background:gray; 
          }
        
        div { 
          margin:0; 
          border:0; 
          }
        
        h2 { 
          margin:2em 0 0 2em; 
          text-decoration:underline; 
          }
        
        .fixed, .relative { 
          border:1px solid white; 
          }
        
        .fixed { width:500px; }
        
        .relative { width:100%; }
        
          .floats .main { 
            overflow:auto; 
            }
              
              .main div { 
                height:100%; 
                }
              
              .header { 
                background:yellow; 
                }
              
              .floats .main div { 
                float:left; 
                }
              
              .inlineblocks .main div { 
                display:inline-block; 
                vertical-align:top; 
                }
                
                .ms1 { 
                  width:100px; 
                  background:red; 
                  }
                
                .ms2 { 
                  width:70%; 
                  background:white; 
                  }
                
                .ms3 { 
                  width:30%; 
                  background:cyan; 
                  }
              
              .footer { 
                background:yellow; 
                }
        
      </style>
    
    </head><body>
        <h1>Mixed px & % child value - Fixed vs. Relative parent width</h1>
        <h2>1st test - fixed parent width w/ mixed child widths: px & %</h2>
        <h3>Floats</h3>
    
     
        <div class="fixed floats">
          <div class="header">
            header div
          </div>
    
          
          <div class="main">
          
            <div class="ms1">
              a floated div here
            </div>
            <div class="ms2">
              div floated
            </div>
            <div class="ms3">
              another floated div
            </div>
            
          </div>
    
          
          <div class="footer">
            footer div
          </div>
        </div>
      
      
    
      <h3>Inline Blocks</h3>
      
      
      <div class="fixed inlineblocks">
        <div class="header">
          header div
        </div>
    
        
        <div class="main">
        
          <div class="ms1">
            an inline block div here
          
          </div><div class="ms2">
            div inline block
          
          </div><div class="ms3">
            another inline block div
          </div>
          
        </div>
    
        
        <div class="footer">
          footer div
        </div>
      </div>
    
    
      <h2>2nd test - relative parent width w/ mixed child widths: px & %</h2>
      <h3>Floats</h3>
      
      
    
      <div class="relative floats">
        <div class="header">
          header div
        </div>
    
        
        <div class="main">
        
          <div class="ms1">
            a floated div here
          </div>
          <div class="ms2">
            div floated
          </div>
          <div class="ms3">
            another floated div
          </div>
          
        </div>
    
        
        <div class="footer">
          footer div
        </div>
      </div>
    
      
      
      <h3>Inline Blocks</h3>
      
      
    
      <div class="relative inlineblocks">
        <div class="header">
          header div
        </div>
    
        
        <div class="main">
        
          <div class="ms1">
            an inline block div <br>here
          
          </div><div class="ms2">
            div inline block
          
          </div><div class="ms3">
            another <br>inline block <br>div
          </div>
          
        </div>
    
        
        <div class="footer">
          footer div
        </div>
      </div>
      
    
    </body></html>

  20. #20
    Resident curmudgeon bronze trophy gary.turner's Avatar
    Join Date
    Jan 2009
    Location
    Dallas
    Posts
    990
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm not ignoring you, noonnope. I want to take some time to best understand your post. Unfortunately, real life is not taking a break, and all I can do on the forums is look at the more trivial issues.

    cheers,

    gary
    Anyone can build a usable website. It takes a graphic
    designer to make it slow, confusing, and painful to use.

    Simple minded html & css demos and tutorials

  21. #21
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for the courteousness. Looking forward to your insight. Feel free to charge upon it using any angle you see fit

  22. #22
    Resident curmudgeon bronze trophy gary.turner's Avatar
    Join Date
    Jan 2009
    Location
    Dallas
    Posts
    990
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Without having done more than glance at your reasoning, I believe it's all made moot by the css3 Flexible Box Layout Module.

    The Gecko and Webkit engines already support this module. Use the proprietary test prefixes, -moz- and -webkit- for the new properties. h/t to dresden_phoenix.

    cheers,

    gary
    Anyone can build a usable website. It takes a graphic
    designer to make it slow, confusing, and painful to use.

    Simple minded html & css demos and tutorials

  23. #23
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,266
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    h/t?

  24. #24
    Robert Wellock silver trophybronze trophy xhtmlcoder's Avatar
    Join Date
    Apr 2002
    Location
    A Maze of Twisty Little Passages
    Posts
    6,316
    Mentioned
    60 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    Hat tip (h/t) I suspect.

  25. #25
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,269
    Mentioned
    179 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by gary.turner View Post
    Without having done more than glance at your reasoning, I believe it's all made moot by the css3 Flexible Box Layout Module.
    Yes I mentioned that in post #6 and if it works as well as expected it will solve a lot of the problems. It doesn't seem as though there will be support in IE9 though which is a shame.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •