Box Model Massacre

Just a quick post to share a useful regular expression that finds styles that might be in need of a box model hack:

{([^}wp]*(width|padding)){2}[^}]*}

This pattern will match any style that contains both a width and padding declaration, regardless of order, giving you a good starting point to determine where you might need need to apply your IE 5.x PC hack/filter of choice. It’s a little loose (it will also match any style with two width or padding declarations) but it gets the job done.

In BBEdit (or your regexp-compatible text-editor of choice), open up the Find and Replace window, paste it into the Find box, make sure “Use Grep” (or “Use Regular Expressions” if applicable) is checked and click “Find All.”

Previous
sIFR 2.0rc
Next
Friends don’t let friends use IE
Author
Shaun Inman
Posted
October 7th, 2004 at 10:04 am
Categories
Apple
CSS
Comments
012 (Now closed)

012 Comments

001

It’s times like these I’m ashamed to call myself “Senior Java Programmer” when all I do is point-and-click in a behemoth of an IDE, and I know nothing of regular expressions. :-(

You have mad programming skills! Thank you for sharing with the rest of us!

Author
Gabriel Mihalache
Posted
Oct 7th, 2004 7:00 am
002

This pattern will match any style that contains both a width and padding declaration, regardless of order

Unless you have repeated either of those in a declaration:

.foo {
   width : 100px !important;
   /* some hack stuff */
   width : 120px;
}

I think it will fail with the following as well:

.bar {
   padding-left : 20px;
   padding-right : 10px;

For actual matching, you may need to specify more detail, at least so you don’t catch the .bar case.

Author
David Schontzler
Posted
Oct 7th, 2004 7:09 am
003

I mentioned that it will match two occurrences of either width or padding in my post. I also mentioned that it was a “good start” not a stand-alone solution. If you want to talk about where it really falls down let’s talk about declaring the width with one selector and the padding with a separate (possibly the same) selector:

body .foo { width: 100px; }
.foo { padding: 20px; }

Like I said, it’s a good start and easier than scanning 2,000 lines of CSS for two properties. Once the potential issues it does pick up are addressed, then you can worry about the lingering issues it missed.

Author
Shaun Inman
Posted
Oct 7th, 2004 7:22 am
004

Nice work Shaun.

To make it really standalone, you would need to first congregate all styles applicable to an element and then do the regex.

So while it fails to match all box model caveats, it is a very good solution indeed.

I’m not sure if you can use back-references in BBedit’s regex but that would help out when the same rule is applied twice in the same element.

Author
Vincent Grouls
Posted
Oct 7th, 2004 2:11 pm
005

it’s a good start and easier than scanning 2,000 lines of CSS for two properties.

It is, it is. Further things you could do to keep the base css positioning construct rules apart from the aesthetic rules. (Viz. base.css and colour.css) That way you’ll only have to worry about the base file.

However, I’ve begun to use IE7*, and it really takes care of all box-model problems related to IE. This includes the 3px-float and padding problems.

*A javascript file which, in essence, does the same as Shaun’s grep rules here but also fixes them on the fly.

Author
AkaXakA
Posted
Oct 8th, 2004 10:27 am
006

I’ve been wandering about this for a while. Is there any way of using a slightly more advanced version of this and just processing our css files through php to allow the css to remain cached, and completely untouched by server side languages or javascript or box model hacks.

You would then tell apache to process all css files with said imaginary script - adding in the box model hack, keeping the real css clean and hack free.

Note I have no idea if this is far to difficult to do but I’ll have aplay with your regex I think and see where I end up - thanks a lot btw!

Author
Andrew Phillipo
Posted
Oct 8th, 2004 12:18 pm
007

Now that, Andrew, is a great idea. It might need to be my next little “waste” of time.

Author
Shaun Inman
Posted
Oct 10th, 2004 1:36 pm
008

Perhaps XML-based CSS with XSLT would be a consideration for serving up different “variants” of CSS.. as convoluted and roundabout as that may sound (And I’m surprised I’m saying it myself,) there it is ;)

Author
Scott Schiller
Posted
Oct 13th, 2004 7:22 am
009

Hey that looks like it could be handy. Let me play with that for a while. I’m sure there could be more usefull tricks cooked up with the use of regular expressions.

Author
Egor Kloos
Posted
Oct 18th, 2004 4:15 am
010

You would then tell apache to process all css files with said >imaginary script - adding in the box model hack, keeping the real css >clean and hack free.

… and thereby loosing all caching related advantages of CSS.

Doh!

Handy Regex though Shaun, thanks for sharing :)

Author
Andrew Krespanis
Posted
Oct 20th, 2004 2:46 pm
011

The IE7 script isn’t fully reliable; I’m working on seeing how much I can simplify my page and still recreate the problem, but certain complicated pages send it into what seems to be an infinite loop (either infinite or over ten minutes, not sure which at the moment).

If you had a simple XML spec (we don’t), and a simple page, view, and container model (which we don’t), then you could have small, fast, compliant browsers that all could process the data reliably.

However instead, what we have is HTML/XHTML, a bloated standard with tons of markup that has no relevance when it is used in conjunction with CSS.

We have an XML stanard which means that 90% or more of the applications that claim to put out XML or read XML actually read or write a tag-soup that isn’t compliant enough with the XML specification to reliably interoperate with other programs. A lot of people think they can write out a less than, a tag name, a greater than and the matching end tag, and put any random data they like in the middle and still have readable XML. The worst offenders let you write data that they themselves cannot parse.

We have a CSS2 standard that is so complicated that there isn’t even a reference implementation that is relatively bug free. Every single implementation of CSS2 that exists on the planet fails to handle portions of the standard correctly.

The only way things can change is if there is a new standard written not by some huge committee of 80 browser vendors all pushing for features to complicate the standard that they know that their competitors don’t have and that they believe will be difficult for their competitors to write (the current mechanism), but instead a small team of people.

Look at Flash for a moment. No standards committee wrote “this is how Flash should work.” They didn’t sit down in a committee with a bunch of people from other companies to develop a standard, they went and wrote what they needed to get the job done. People use Flash on pages because it works, it does the job, etc. It’s not a web standard, it’s not formed by a committee, the browser folks didn’t all sit down and chat with each other, Macromedia just implemented it how they wanted it to work.

Author
Dave Bacher
Posted
Nov 1st, 2004 1:54 pm
012

It would be cool to have a script that would fix them for you as well. Not just find them. I am sure it’s possible to do in, say, Perl.

Author
Ottawa
Posted
Nov 5th, 2004 10:57 am