IE7 and the border-box model

Is there any way of getting IE6/7 to use the border-box model, width inclusive of borders and padding, while in xhtml strict mode and without relying on javascript or iframes?

Why would you want to do such a thing? just to confuse the maintainers ? :slight_smile:

I suspect the majority of people find the border box model much easier to understand and implement than the w3c standard, but let’s not go down that path. :wink:

Force them into quirks mode.

But as stated - this will make ensuring cross-browser uninimity very hard - there’s no advantage to it that I could think of.

I am migrating some code encapsulated within tools that emit markup to xhtml strict compliance. Forcing quirksmode defeats that purpose. I want xhtml strict for more consistent behaviour.

Users can apply width to these tools, but expect border-box behaviour, not content-box. This is why I need to use the border-box model. I can cheat by taking the width of the control and applying it to a wrapper, but that is something I am hoping to avoid.

Then slap the XML encoding above the DOCTYPE for IE6.

Am I not understanding something? Won’t that force IE into quirksmode?

You want to use the border-box model but you don’t want to use quirksmode you are in a sticky situation.

anyways is this what you are looking for?
http://www.quirksmode.org/css/box.html
but oh such a shame box-sizing doesn’t working IE Win just Mac.

Isn’t that what you’re saying you want? A standards-based (W3C) box model is only possible in standards mode. A border box model needs to use quirks mode.

Thanks for trying to help guys. After much research and experimentation the answer is obviously no, or at least not directly.

Explain images in the border-box context then because that’s one big reason it was abandoned.

I suspect the majority of people find the border box model much easier to understand and implement than the w3c standard
Which is the SGML model which has been the publishing model for many, many years. It makes a lot of sense to people in the business.

Who abandoned it exactly? I think it went like this: The W3C invented a “standard” that made sense to them; browser developers thought, “ah, better support that” and most designers went along kicking and screaming because there wasn’t any choice. But now there is, as CSS3 will support “border-box” - I wonder why, if “content-box” was some kind of godsend?

This explains it far more elegantly than I can:
w’s.quirksmode.org/css/box.html

Summary: Designers care about how big an area of “content” is, and don’t tell me, as a designer, that if I take a big fat pen and draw a big fat box around some text on a page that the box isn’t also “content”. It’s on my page and people see it, so what else is it? An annotation? A doodle? It’s content. Sorry but the W3C got their conceptualisation completely and utterly wrong.

Imagine a picture frame. Imagine one of those picture frames which have a bit of white paper behind the image, visible around the edges of it, then the frame (or border) surrounds that.

The image is content, like text, no argument there. The white spacing around it is “padding”. Like packaging in a box. The frame (sides of the box) is the border. The minimum space allowed around it is margin.

But let’s be clear - if I have a wall on which to hang pictures in frames, then as far as I’m concerned, as a designer, the wall is the canvas, and the pictures, padding and frames included, is my content for that canvas.

Sure, you can draw a parallel with the word “contents” = “that which is inside a container” to say how the W3C model makes sense. But who are they designing their standards for - linguists, semanticists or visual designers? That is the bone of contention here. The W3C got caught up in semantics and lost the plot with this one. Much as I hate to say it, MS got it right as far as designers were concerned.

Explain why a design-based model was abandoned for one in which content can flow through its border?! That doesn’t follow the idea of “contents of a box” either. Not any box I’d like to use anyway. Use of padding messes with sub-box positioning.

Even a box itself can flow outside of its container box! If I put my picture frame inside a “box”, should I assume the box will contain it, or that bits of it may stick out? If I throw alphabet noodles in a box, should they flow outside the box?

If I want to put my box inside another box, should I have to remember how much padding I used inside the first one to work out how wide it is? Does it help me when its padding magically projects through the outer box like some 80’s 3D game? (Mercenary for the C64 comes to mind). :slight_smile:

I note that the box surrounding the Smilies to the right of this textarea is flowing outside its container box. Who exactly does that make sense to? If the answer is “oh they didn’t code it properly” then my question is why do I need to code especially to make a box stay inside another box?

There is a reason why all browsers now support “border-box”, and I for one intend to use it wherever possible because it makes design easier, something the W3C had difficulty understanding.

(this my first post after joining btw - it’s a “rejoinder join”) :slight_smile:

IE6/7 do not support XHTML. Neither does IE8.

Not that it matters in this case, because I believe you are talking about the CSS rendering mode (standards vs quirks), which is a completely different thing. :slight_smile:

How odd that this debate gets re-opened so often.

Sure, you can draw a parallel with the word “contents” = “that which is inside a container” to say how the W3C model makes sense. But who are they designing their standards for - linguists, semanticists or visual designers? That is the bone of contention here. The W3C got caught up in semantics and lost the plot with this one. Much as I hate to say it, MS got it right as far as designers were concerned.
You might want to include structuralists in your who-are-the-standards-for question. The concept of wrapping the container around the content is patently obvious. Stuffing content into a given box, not so much. At least, that’s true for designers who are comfortable with a dynamic, interactive medium such as the web, as opposed to a static, non-interactive medium such as print.

That’s not to say that the border-box model isn’t handy at times. Firefox has long used the border-box model for tables. It isn’t done to appease graphic designers, but to properly handle the special structural considerations required of the table container. There are other specific problems that might be more easily dealt with using a border-box model. The trouble is that the model has serious WAD logic bugs that the content model doesn’t. The content model may sometimes require a little more thinking on the part of the coder, but is unlikely to break the well designed page.

cheers,

gary

Not at all, it’s because people find the new model objectionable. It’ll calm down a lot once it’s clear there’s an easy way to switch.

… to structuralists I assume. :slight_smile:

Oh please, that smacks of elitism (though that was also a great C64 game). The web was a “dynamic, interactive medium” long the before the W3C came along.

Even as a coder it doesn’t make much sense: When I ask the DOM “what is the width of element xyz?” I want the width of the element. I’m not asking about the width of the element’s text node - which should stay where I want it to stay, inside the bounds of my dynamic and interactive box. If the text overflows the box’s border, does width return the real actual width of the text outside the box as rendered? Strangely, no. So, suddenly, there’s no access to this so-called “content box” anyway. Content has a bit of a life of its own now.

Besides this “bug”, perhaps the argument of what constitutes “width” is academic. Measure it from wherever, as long as it’s uniformly adopted and behaves itself. The real problems are all this business of overflowing a parent box’s boundaries and the affect padding now has on positioning reference points. What a headache that is. Seriously, tell me this new box model means less javascript code for dhtml than the old one (assuming the old one had become standard)?

WAD stands for “works as designed” so “WAD bug” is an oxymoron, isn’t it? Maybe depends what you’re calling a bug… you mean the conflicts between browser implementations?

A fairly recent forum by the W3C themselves discussed the limitations and problems of the current CSS version. It’s always under review. Perhaps not the same bugs, just different ones.
w’s.w3.org/Talks/2008/0911-CSS-Amsterdam/

You could say that of the border-box model too. Except content didn’t flow out of them! The box grew with the content. Did W3C provide an alternative like “overflow: growbox” or something in case we want different behaviour? Nup. Nice idea perhaps, sloppy implementation definitely.

Perhaps if you explained why content overflow is a good idea and how to manage it, I’ll understand your css position (pardon the pun) better. :slight_smile:

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.

We need a body to regulate and standardise the language, of course. But it needs to be more practical and real-world, less academic and political. Even in terms of “structure” the thing is a mess IMO. We’ve gone from nested tables to nested divs - not a huge improvement there.

They keep missing opportunities to really advance the medium. Why else are we seeing Silverlight and Flash competing now in the application space? Because HTML & CSS for apps is still a mess for coders and designers in any complex application. Look into any popular JS library - YUI, jQuery, Mootools, whatever (bless their socks) - you’ll see many sizing and positioning complexities introduced by the content-box model which would be so much simpler in the border-box model. And it would still be dynamic and interactive. :wink:

I am not going to reply to all your gripes.

It is not a new model. There was no width attribute until html3.2, and then only on select elements such as hr, but not div or p. CSS1 described the content box model from the get-go. If you learned the wrong way, what’s your beef?

…[sic] to structuralists I assume. :slight_smile:
HTML is a markup language for describing the structure of a document, so I hope so.

Oh please, that smacks of elitism (though that was also a great C64 game). The web was a “dynamic, interactive medium” long the before the W3C came along.
That, elitism, is a specious argument. Until Netscape brought us a scripting language, the web was not what you’d call dynamic. It did offer forms. The W3 formalized IETF’s rfc 1866 in 1995 as html2. HTML had only existed since 1990.

Even as a coder it doesn’t make much sense: When I ask the DOM “what is the width of element xyz?” I want the width of the element. I’m not asking about the width of the element’s text node - which should stay where I want it to stay, inside the bounds of my dynamic and interactive box. If the text overflows the box’s border, does width return the real actual width of the text outside the box as rendered? Strangely, no. So, suddenly, there’s no access to this so-called “content box” anyway. Content has a bit of a life of its own now.
I have no idea what you’re going on about. Overflow is not a box model issue. I assume that you’re melding IE’s faulty border box model with IE’s really, really stupid version of a new block formatting context known as hasLayout. hasLayout was the epitome of WAD bugs in action. Most of IE6 and below’s rendering bugs, including its really screwed up mistreatment of overflow:visible are due to hasLayout. IE7 was patched to fix most of the hasLayout rendering bugs, and IE8 has killed the concept, and adopted a proper block formatting context.

Besides this “bug”, perhaps the argument of what constitutes “width” is academic. Measure it from wherever, as long as it’s uniformly adopted and behaves itself. The real problems are all this business of overflowing a parent box’s boundaries and the affect padding now has on positioning reference points. What a headache that is. Seriously, tell me this new box model means less javascript code for dhtml than the old one (assuming the old one had become standard)?
One, overflow is not, I repeat, not a box model issue. Two, I have never dealt with a javascript/positioning issue where there would have been more than a trivial difference.

WAD stands for “works as designed” so “WAD bug” is an oxymoron, isn’t it? Maybe depends what you’re calling a bug… you mean the conflicts between browser implementations?
No, I mean that the border model will/can break itself due to its design.

<snip>

You could say that of the border-box model too. Except content didn’t flow out of them! The box grew with the content. Did W3C provide an alternative like “overflow: growbox” or something in case we want different behaviour? Nup. Nice idea perhaps, sloppy implementation definitely.
The content didn’t grow out of them because of that massive WAD bug, hasLayout; a different and orthogonal issue from the box model.

Perhaps if you explained why content overflow is a good idea and how to manage it, I’ll understand your css position (pardon the pun) better. :slight_smile:
Because it is better for the content to overflow than have the box expand, breaking the layout.

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?
We do have it. Learn css.

Their focus seems remarkably misplaced. I mean, if you want to replace tables with CSS, then give us equivalent functionality at least.
Again, learn css and well structured, semantic html. CSS does not replace tables. Tables are structural elements, and css is a presentational declarative language.

We need a body to regulate and standardise the language, of course. But it needs to be more practical and real-world, less academic and political.
The standards are written primarily by the UA vendors, for the UA vendors, to describe how those UAs should render html, css, and javascript. It is up to developers to understand these standards. It doesn’t get much more real world than that. If you don’t understand it, perhaps you should study it a bit more.

Even in terms of “structure” the thing is a mess IMO. We’ve gone from nested tables to nested divs - not a huge improvement there.
Anyone who has done that, doesn’t understand what css and semantic html are all about.

They keep missing opportunities to really advance the medium. Why else are we seeing Silverlight and Flash competing now in the application space? Because HTML & CSS for apps is still a mess for coders and designers in any complex application.
HTML, css, and js are for documents. Flash, Silverlight, audio and video players, pdf viewers, etc. are plugins that extend the document. I see no conflict.

Look into any popular JS library - YUI, jQuery, Mootools, whatever (bless their socks) - you’ll see many sizing and positioning complexities introduced by the content-box model which would be so much simpler in the border-box model. And it would still be dynamic and interactive. :wink:
Look into any of those libraries, and you’ll see potloads of cruft, all due to their attempts to be all things to all people. Write your own lean, mean, fighting machine library.

gary

interesting discussion, I have to admit I’ve never though much about how the box models compare but I definitely like waveform’s style of discussion, welcome to Sitepoint ;).

Much like this discussion does, applying analogies that are true for non-interactive mediums to this argument was something I guess (as I wasn’t in the web profession then) the W3C did when it developed the box model.

However, the same logic that applies to pictures/paintings etc, cannot necessarily be transferred to the web; for example, artists who practice on static mediums don’t have to deal with the relationship between percentage and fixed values when applied to the same box. This issue in particular, is something I have difficulty imagining the W3C didn’t invisage, when it developed the spec.

You’re right, the analogy only goes so far, but I just wanted to illustrate the differing views about content and composition - coming from an artistic/design standpoint it doesn’t matter what the medium is - it could be sand or a physically interactive installation - all we want is control (cue evil laughter) over it, and/or at its behaviours. We need good tools, because we care about the visual & interactive result. The web isn’t just a series of documents. Everyone who puts up a page about their school or their dog is wanting to communicate something. That’s what design is about.

And I just noticed Gary’s sig. :slight_smile: Yes, bad designers end up creating a bad experience. We’re clearly coming from different perspectives with different needs in mind.

But I don’t see why a language (which for a long time has been more than just a “markup” language) can’t cater for different uses for the medium of the Web. Great document model and accessibility doesn’t have to be exclusive of great presentation & design ability.

Perhaps one day we’ll have markup which directs different readers/apps in different ways through a document. Same idea as specifying tab-order through form fields. Perhaps tags which surround “semantic blocks”, linked to each other by contextual pointers. Like anchors, but strung together, marking different routes through connected documents, not just point A to B links as we have now. But I digress…