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!

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.

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?

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

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 :slight_smile:

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 :slight_smile:

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.

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.

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

The algorithm UAs should employ it’s not based on reading my mind :slight_smile:

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

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.

OK, sounds reasonable. Please describe the algorithm and the test cases.

cheers,

gary

Will do. Just not tonight :slight_smile:

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.

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

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.

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

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

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.

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

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

  1. 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:

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

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

Thanks for the courteousness. Looking forward to your insight. Feel free to charge upon it using any angle you see fit :slight_smile: