IE7 and the border-box model

Sounds interesting. Would really like to know what this border-box model is all about

I dont like IE , thats why I use Safari or Firefox…but IE??..just for test!!

Because it is better for the content to overflow than have the box expand, breaking the layout.

That’s what real boxes do, anyway. Fill a moving box with too many books, and they spill out. The moving box doesn’t grow. Except in IE6.

They just don’t think about practicalities. Why else do we still not have vertical centering of content or a host of other dead-simple but invaluable layout features? Their focus seems remarkably misplaced. I mean, if you want to replace tables with CSS, then give us equivalent functionality at least.

I’ve always wondered why the ease of figuring out equal, auto margins on the sides couldn’t be used for the equal, auto margins vertically. Math is math?
Though the 100% height thing… people were making 100% high tabled pages, when apparently height wasn’t ever supposed to be an attribute of tables. But again, we can make something 100% wide. While the default of collapsing to fit vertical amounts of content is fine, it would be nice to easily be able to override that, instead of the complicated multiple-container tricks you find on Paul’s or Stu’s pages.

So I point to those things to tell programmers that no, clearly, the CSS specs were NOT written by designers, because designers would have insisted on being able to do some of these things with blocks.

Though I suppose you could call display: table the equivalent functionality, but most of the time, if someone’s supposed to look and act like a table, it’s probably supposed to be a real table anyway. I don’t like adding display: table on stuff JUST to be able to vertically center my freakin’ text (so, I don’t).

I am glad the border-box model (what we see in quirks modes in IE) didn’t catch on. The idea that boxes’ outer skins and borders expand out when padding is added makes total sense, esp for me, coming from a medical background : ) What happens when you add padding to a human? What happens to their outer edge? What happens to the amount of non-padding that’s inside of them? Content-box model seems to follow the human box model : )

Because the height usually depends on the content. That means you’d have to lay out the content before you could place the container, which would make incremental rendering impossible.

It’s different with width, since it depends on the width of the containing block, which is known beforehand. There are cases where it might depend on the content as well, but the CSS spec says these are ‘undefined’.

You could allow automatic vertical margins, but you’d have to require a fixed height on the parent container and that would be too much of a restriction to make it useful. Or you could forgo incremental rendering, but who’d want that?

Tables do it perfectly well. I don’t see the difference between that and not knowing where to, say, word-break a page of text based on a fixed-width box. There’s no incremental rendering there. As content is added to the DOM, the objects of the page re-adjust themselves. Dynamically add some content and the page adjusts. Where is the problem?

Not really - the width of a table, for example again, often isn’t know until the entire set of rows is loaded. Browsers manage it perfectly fine.

Which is odd, since almost every object on a page has undefined aspects - it’s position depends on the position of everything around it. I’d say width is one of the only attributes which is most often fixed beforehand. But take inline instead of block elements, then that’s not true either.

Again, tables handle this routinely. There really is no problem with any of these things you mention IMO. Every time you resize your browser window (which is what HTML is designed to support after all) the page continually readjusts itself. What makes vertical centring any different?

That’s right. There is no incremental rendering for tables if you use the automatic layout algorithm. That’s one of the disadvantages of using tables for layout: you have to download the whole page before anything is rendered. If you have a fast connection it may not be too noticeable, but we who live out in the sticks will notice.

The page reflows when you add content to it. That part is usually pretty quick; the issues arise when you’re incrementally rendering something while downloading the document, especially on a slow connection.

You could remove incremental rendering and require the entire document to be downloaded before rendering. But the browser would be perceived as slow and sluggish, except perhaps by those on really fast lines.

Table layout is fairly complicated and it’s anything but fast (using the automatic algorithm). It requires a two-pass strategy where the first pass assesses the table’s content and the second pass starts rendering it.

Try loading a large document with a table-based layout over dial-up, and you’ll see what I mean.

The total load+render time isn’t much slower with tables, but the perceived experience is slower since you have to wait for anything to happen. With incremental rendering you can begin to read the content while the latter parts are still loading.

Remember, far from everyone is on a 100 MB/s connection.

The rendering contexts (block and inline) in CSS-compliant browsers are quite fascinating. But if you study how the CSS spec is written, you can see why some things are allowed while others aren’t. It has to do with how you can determine the layout without look-ahead.

Inline boxes can be laid out without look-ahead, since each one depends only on the preceding boxes.

Not if you are willing to forgo incremental rendering, no. But most people aren’t. We want the content to start appearing as quickly as possible.

Again, a window resize only requires a reflow. You don’t have to make a new HTTP request to download the entire document, parse it, build a document object model, apply the CSS rules and then render it. You only have to recompute the layout and render it, which is much faster.

We’re getting into esoteric arcana. A considerable amount of study should be devoted to the nuances of the the presentational properties. You must also be aware of the critical part played by the various browsers’ degree and accuracy of support

Please understand that there are significant differences among display properties, e.g. block, inline, inline-block, table, and table-cell. You have gone on and on about the wonders of the table/table-cell properties; well, about html table elements, but table rendering is a function of css display rules. You can certainly apply these values to a <div> or <p> element, but do keep in mind that there are serious layout issues and a severe performance hit when using the table group values.

Not really - the width of a table, for example again, often isn’t know until the entire set of rows is loaded. Browsers manage it perfectly fine.
True, and it requires two passes through the parsing/rendering process. The table is a container for a particular class of data, and has very specific rendering requirements.

Which is odd, since almost every object on a page has undefined aspects - it’s position depends on the position of everything around it. I’d say width is one of the only attributes which is most often fixed beforehand. But take inline instead of block elements, then that’s not true either.
Have you even read the display property specs? Each value has its own, very unique set of rules. With well structured, semantic markup, you are free to use css to apply nearly any display value to almost any element.

Again, tables handle this routinely. There really is no problem with any of these things you mention IMO. Every time you resize your browser window (which is what HTML is designed to support after all) the page continually readjusts itself. What makes vertical centring any different?
Do not confuse browser shortcomings (mostly IE’s), or your inability to understand How Things Work® with “the specs don’t allow …”

gary

I’m hearing just two main points here, being put forward as legitimate reasons why a) we don’t use tables, b) we shouldn’t expect things like vertical centring or anything requiring look-ahead:

  1. It affects overall browser experience, bad for slow lines, performance hit, etc.

No. This comes down to page design, not eliminating tables, incremental loading and look-ahead. There are old rules, like keeping the total download to less than 100k; images etc. included. It means keeping the contents of tables to a minimum, or using the great table CSS attribute “table-layout:fixed” - which fixes column width, eliminating look-ahead, or so it says on the box.

Forget tables, you can also have a terrible user experience with lots of Flash, 50 separate css & js files, lots and lots of tiny images - ping doesn’t just suck on dialup but also when loading overseas pages (~300ms to US from Oz). I know all about 300ms ping on ADSL2+, you’re right it’s not fun, but lots of pages have tables or whatever and load in a split second. The problem is page-bloat. Google’s search page is very quick (uses a couple of tables last I looked).

Example 1: CNN. 3 small tables, but 126 items to load for a single home page… 710k in all, around 40 secs to load on ADSL2, and that’s with Flashbock on.

Example 2: wikipedia. 10 tables in all, some even nested (don’t faint); 30 items, 140k in total, 9 seconds to completion. And my notebook doesn’t go up 3 degrees in the process like with CNN.

Call me Susan if you can show me how tables, incremental loading and look-ahead are only - or even mostly - to blame for slow site load. It’s bloat and bad design, not a matter of single-mindedly ruling out this tag or that technique.

  1. My apparent inability to understand something clearly understood by my intellectual superiors.

Well I can’t argue with someone who’s faith is stronger than mine.

We very clearly write one thing, and you very obdurately read something else.

We object to the use of html tables for layout because 1) it’s semantically wrong, 2) it’s structurally wrong, and 3) it has side effects that have the potential to break the layout, for example the shape-shifting you’re so enamored of.

The use of the html table element has zero, zip, zilch, nada to do with vertical centering other than having the presentational vertical-align default value of middle, and a display value of table. Any other element with appropriate display and vertical-align values will center its content vertically.

  1. It affects overall browser experience, bad for slow lines, performance hit, etc.
    True

No. This comes down to page design, not eliminating tables, incremental loading and look-ahead. There are old rules, like keeping the total download to less than 100k; images etc. included. It means keeping the contents of tables to a minimum, or using the great table CSS attribute “table-layout:fixed” - which fixes column width, eliminating look-ahead, or so it says on the box.
There are a number of factors affecting the user experience, table rendering being one of them. That it’s not the only factor, or that its effect may be greater or smaller than another factor is not at issue. Do not throw straw men into the fray.

As to the table-layout property, no UA, to my knowledge, properly implements the fixed value.

The side effects can be surprising.

Forget tables, you can also have a terrible user experience with lots of Flash, 50 separate css & js files, lots and lots of tiny images - ping doesn’t just suck on dialup but also when loading overseas pages …
Again, specious arguments. That a hot griddle can burn you is not negated by the argument that being hit in the knee with a baseball bat hurts like hell. The effects may be cumulative, but the arguments are orthogonal.

  1. My apparent inability to understand something clearly understood by my intellectual superiors.

Well I can’t argue with someone who’s faith is stronger than mine.
It’s you arguing from faith, a belief held in spite of the facts. I would not argue that anyone is your intellectual superior, myself included. I do argue that you do not sufficiently understand the subject, and that your position is untenable in that light.

gary

Of course things like document size and the number of replaced elements (images, Flash, etc.) have a great impact on load time. No-one is disputing that.

But for any given document size, a layout requiring look-ahead will be perceived to load slower than the corresponding design that can render incrementally. It will also be slightly slower if you measure the total time for download+render, but that difference is usually negligible.

And comparing layouts with table markup to semantic structures and CSS, the markup will be more bloated which will increase the document size. (Note that I said semantic structures, you can write bloated markup without using tables, too. :))

It does, but it also eliminates much of the flexibility of the table, requiring you to know beforehand how wide each ‘column’ should be.

I can’t. But where did I make such a claim?

All I’ve said is that the CSS specification is written so that a compliant user agent will be able to implement layout algorithms that don’t require look-ahead.

We object to the use of html tables for layout because 1) it’s semantically wrong

By that, do you mean the order in which the cells are read is not the order in which the document is supposed to be read? If so, well that just depends on what you do with the tables. You can make the same mistake with CSS, particularly using absolute positioning, conditionally hidden element (with use of CSS alone, not js, just by employing :hover) so it’s not a table-specific problem. It’s a design issue.

, 2) it’s structurally wrong

Explain?

and 3) it has side effects that have the potential to break the layout, for example the shape-shifting you’re so enamored of.[quote]
Sure, but not if used properly. Lots of sites have fixed layouts which don’t ever move. A lot of wordpress/blog/commercial sites are like that. No issue there. Again, it’s choice of design, you don’t have to be “against tables”. That single-mindedness is what I object to in particular. God forbid that attitude causes table to be deprecated. That would be a loss, not a gain IMO.

[quote]It does, but it also eliminates much of the flexibility of the table, requiring you to know beforehand how wide each ‘column’ should be.

Lots of sites are like that. So it makes use of tables easy, but I agree use of CSS is just as easy in that situation, and therefore preferable. But if we’re talking need for vertical centring, it can come in handy. It’s a valid tool is what I’m saying!

The use of the html table element has zero, zip, zilch, nada to do with vertical centering other than having the presentational vertical-align default value of middle, and a display value of table. Any other element with appropriate display and vertical-align values will center its content vertically.

Sure, and your next statement was…

As to the table-layout property, no UA, to my knowledge, properly implements the fixed value.

I’ve heard the same thing. Thanks for making my job easier. :slight_smile:

Again, specious arguments. That a hot griddle can burn you is not negated by the argument that being hit in the knee with a baseball bat hurts like hell. The effects may be cumulative, but the arguments are orthogonal.

Is “orthogonal” some kind of hip word at the moment? I see it everywhere! And no, not always in a reply to one of my posts.

It’s you arguing from faith, a belief held in spite of the facts. I would not argue that anyone is your intellectual superior, myself included. I do argue that you do not sufficiently understand the subject, and that your position is untenable in that light.

Explain to me in one paragraph how you have somehow made my position untenable? I don’t see it. And I’m not being stubborn, I really don’t see it based on your arguments.

The problem is exactly those “specific problems that might be more easily dealt with using a border-box model”. Sometimes they are darn near impossible to solve in a content-box model. And the fact that the option to use the border-box was removed (a separate issue from its buggy implementation - even buggy specification) is the reason that the debate pops up again and again.

I never saw where the debate occurred in the first place. There was suddenly a spec that didn’t include border-box rendering and it was somehow “right”. This has caused me much frustration through the years - it would have been nice to chime in… Not that I stood much chance of finding it - I’m replying to a post that has long ago finished…

This is an old thread, and given that no current browser supports the border-box-model without special effort, I hesitated to answer.

First, please understand that beginning with css1, there has never been a border-box-model as part of the standards. See §4 Formatting model, css1, 1996. Note that css1 was adopted five years before IE6 was released.

Why did MSFT choose to use that model in spite of its not being the correct model? My own, unsupported by evidence, belief is that MSFT was attempting to lock developers and users into IE, and it had nothing to do with choosing a superior model.

cheers,

gary

This is an old thread, and given that no current browser supports the border-box-model without special effort, I hesitated to answer.[/QUOTE]

I certainly appreciate the reply all the same. I’ve often search for this discussion through the years, but I never ran across it (surprising that now the quirksmode article pops right up in my searches which in turn led me here).

Right, but css1 was not adopted 5 years before IE implemented CSS. Too be fair IE must have had a hand in the spec and released IE 3 with its limited CSS based somewhat upon the the spec (that was forecoming as they coded IE3)…

And I’m certain there is truth in that. But I guess the whole point of my posting was to ask: Is there any public record of the CSS 1 discussions? Was MSFT (or anyone else) involved at all. How did we get here (or there - with it being removed).

I realize now that question didn’t come across well in the first post. Can I also ask: What is the current industry standard work around? For fixed width layouts this seems to be trivial. But I constantly encounter an environment where I am required to deliver pages that stretch to unknown dimensions with various pieces of nested content that all most also stretch… and have padding (margins actually - which involve an extra parent with padding). How does the rest of the world do that? My non-js attempts have never impressed me, and js for layout certainly doesn’t.

This was trivial in the IE quirksmode world, but not so much anymore, which is why I whole heartedly welcome the inclusion of border-box in CSS3.

I’m not at all sure I’m answering your question. For one, if it has come up for me, it’s such an automagical thing that I haven’t given it conscious thought in too long to recall. You effectively have a margin-box-model if you don’t state a width at all. The content width will adjust itself to accommodate itself, its padding, border, and margin to fit the available width of its parent. If you create a container element of the desired width, then its block children will fit without your sweating the details.

cheers,

gary

You have a margin-box-model with a with locked at 100% only. So to get two elements side by side with that approach you have to have a parent element set to 50% with no padding margin or border (just to establish the 50% stretch effect) and then the child with auto width and a margin (not a padding since you’re right it is effectively a margin-box-model). Easy enough and it works in Firefox et al., but it’s totally flaky in IE. Sometimes the boxes will wrap to the next line sometimes they won’t. Sometimes you can get away with 49.9% sometimes you can’t.

I guess since MSFT botched even the auto width, there is no guarantee they’ll get border-box right either.

MSFT aren’t the only ones. With FF, Opera, IE and lord knows who else all rounding stuff in different directions, I’d be a little wary of 49.9% boxes myself. IE6 certainly has some extra bugs there.