IE7 and minWidth

IE7 was supposed to have supported min-width in CSS.  It doesn’t work right

Their spec says it applies to “floating block-level elements”, but they don’t mention that it also requires an explicit width — “auto” won’t work.  While that’s fine for “stretchy” layouts, it’s useless for what I want: a flexible, tableless form layout (with elements which can expand to their contents’ sizes).

In fact, my previous IE6 hacks to force it with CSS expressions now don’t work, because while the min-width attribute is valid in IE7, the feature is not actually implemented.  SO, while I previously could pick it up in IE6 with something like this:

IE7 now requires the same trick to be like so:

Unfortunately, forking logic inside CSS expressions is a bit of a pain.  That, combined with the limitations of this technique (IE6 treats width as min-width only when the contained elements can’t be wrapped), prompted me to write a solution script.  Here it is:

author: Rob Eberhardt
desc: fix MinWidth for IE6 & IE7
params: none
returns: nothing
notes: cannot yet fix childless elements like INPUT or SELECT
   2006-11-20 revised for standards-mode compatibility
   2006-11-17 first version
function fixMinWidthForIE(){
if(!document.body.currentStyle){return} //IE only
var elems=document.getElementsByTagName(“*”);
for(e=0; e<elems.length; e++){
      var eCurStyle = elems[e].currentStyle;
l_minWidth = (eCurStyle.minWidth) ? eCurStyle.minWidth : eCurStyle.getAttribute(“min-width”); //IE7 : IE6
      if(l_minWidth && l_minWidth != ‘auto’){
         var shim = document.createElement(“DIV”); = ‘margin:0 !important; padding:0 !important; border:0 !important; line-height:0 !important; height:0 !important; BACKGROUND:RED;’; = l_minWidth;

It uses a shim technique to fix it only for IE (other browsers don’t support currentStyle).  The remaining limitation here is that it only works on elements which canHaveChildren, so it does not work on childless elements, like form INPUTs or SELECTs.  Any suggestions for this case are welcome!

To use it, just call fixMinWidthForIE() in the window.onload, or better yet when the DOM has loaded, and you’re set.

2006-11-20: I updated the script for better standards-mode compatibility (it was causing extra blank lines).  I had missed the doctype switch in my current project.  The good news is that IE7 in standards mode does do min-width.  (I wish I’d noticed that sooner!)  However, I still have a lot of IE6 miles to go before I can put it to sleep…


Finally off dotText!

It took ages, but I’m on dasBlog now.  Good riddance to dotText!  — I bid it lovingly, though, since it served well for a 1st generation blog engine — Somehow a couple hundred legitimate posts + comments garnered many thousands of comment spams.  I expect dasBlog will handle that all better; captchas are a tad annoying but effective, I hear.

That dasBlog is still under active development is a good sign.  I find that quality much more  important these days.  For reference, dotText was last updated almost 2yrs ago (and wasn’t even really released).

So in other news (in the sense that no news is its own news), I haven’t posted much of anything in a couple months, and even then there wasn’t much meat.  I plan to start writing/posting with something like BlogJet.  (Yes, I actually used dotText’s web-based editor, which was text-only in Firefox — I’m entirely too comfortable with code for my own good).  Hopefully this ease will lubricate the writing process.

Regarding the transition: I used two great tools.  One was Aaron Junod’s great dotText to dasBlog converter to migrate the content.  This would have done the trick many moons ago, except that I didn’t want to orphan all my incoming links (a big no-no to a web dev like me).  Fortunately, Scott Hanselman published a Regex to remap URLs from dotText’s format to dasBlog’s (If only I hadn’t fat-fingered that one the first time I tried it way back, it’d actually have worked). 

Finally, some outstanding meta-throbs junk:

  1. Comments were probably lost.  Sorry.  I noticed spammers were usually changing the subject from the default “re: whatever”, so I killed most of the rest. 
  2. Search is gone for the moment.  I’ll add it back in Real Soon Now.
  3. Images and other locally-hosted junk is probably all broken.  I’ll fix that slightly sooner.
  4. Comments are screwy (dotText saved as HTML.  dasBlog doesn’t.)
  5. Layout is messed in IE6.

Ever celebrated one billion anything?

Hard to explain (I’m a geek, nuff said), but I just noticed my One-Billionth birthsecond is coming up soon.  Furthermore, my (almost 3yr old) son’s One-Hundred-Millionth birthsecond will be about a month earlier!

Want to know when you/a loved one reached/will celebrate a major birthsecond?  In that case, I proudly (?) introduce my Birthsecond Calculator (;>) :

  1. Date/Time of birth:
  2. + a birthsecond:
  3. (but you don\’t look a second over ‘ + (iSeconds-10000).toString() + ‘!)‘;
    $(‘PartyDay’).innerHTML = dtResult + strFlatter;
    return false;”>=


Note: This surely won’t work in a feed reader, so come visit for the fun.

(web geek colophon: This works thanks to jsDate, my port of VBScript Date functions to Javascript.)

Update 2007-04-15: My 7yo son wants to know when his 250 millionth birthsecond is, so here’s a customizable version.

CSS includes + HTTP headers = big mess

Anne van Kesteren just posted about the Opera 9 Preview.  More notable to me is the testcase for Linking to style sheets with HTTP headers.

Here’s the code:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "">
<html lang="en">
  <title>CSS: Linking to style sheets with HTTP headers</title>
  <meta name="Author" content="Krijn Hoetmer ~">
  <h1>Linking to style sheets with <abbr title="HyperText Transfer Protocol">HTTP</abbr> headers</h1>

  <p>This line should (or could) be red.</p>
  <pre><code>Link: &lt;index.css&gt;; REL=&quot;stylesheet&quot;; MEDIA=&quot;screen&quot;</code></pre>


The testcase already works (P element in red) in the current Firefox 1.07 (but not IE, natch).  Style code is utterly missing from the document — there are no style attributes, and no <style> or <link> elements.

That’s because they’re not in the document.  It’s in the headers of the HTTP response which delivered the document.  I had to find the style insertion with the Fiddler tool (a great IE addin), and this is what I found in the HTTP headers:

Link: <index.css>; REL="stylesheet"; MEDIA="screen"

I must’ve missed the memo where this became a standard (since multiple browsers now support it).  I miss how it’s a good idea too…

Yes, there’s a gee whiz factor to it.  I could even think of possible uses for HTTP style includes (like configuring includes at the website level via the web server, something which IIS already can do with normal include files). 

But it just seems like a bad idea.

Granted, the line between protocol and document was crossed long ago with HTTP-EQUIV META tags.  This, however, crosses it in the opposite direction, by putting not meta-data, not layout or behavior data, but style data into a transport protocol!

Now I’m no code purist — I feel most like a “SAVD” on Molly’s scale  (What’s bizarre is that I’d consider Anne much closer to a purist, a “SASS” to Molly.) 

We have CSS to get the font tags out of HTML.  Why not cram it into something even more poorly suited like HTTP?!

VERY bad idea.

Another SBS SP1 hangup

I upgraded another client’s SBS 2003 machine to SP1 this past weekend.  It went remarkably smoothly, but we forgot to check their smartphones’ access to Exchange til today.  No connection, we checked the /OMA virtual directory, and got this error:

“A System error has occurred while processing your request. Please try again. If the problem persists, contact your administrator.”

Much “jiggling” (yknow, rerunning wizards, regenerating the web certificate, etc), and googling got me no answer.  I did see this error in the Application Log, though:

An unknown error occurred while processing the current request:
Message: The remote server returned an error: (403) Forbidden.
Source: Microsoft.Exchange.OMA.ExchangeDataProvider
Stack trace:
   at Microsoft.Exchange.OMA.ExchangeDataProvider.OmaWebRequest.GetRequestStream()
   at Microsoft.Exchange.OMA.ExchangeDataProvider.ExchangeServices.GetSpecialFolders()
   at Microsoft.Exchange.OMA.ExchangeDataProvider.ExchangeServices..ctor(UserInfo user)

Message: Exception has been thrown by the target of an invocation.
Source: mscorlib
Stack trace:
   at System.Reflection.RuntimeConstructorInfo.InternalInvoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean isBinderDefault)
   at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at Microsoft.Exchange.OMA.UserInterface.Global.Session_Start(Object sender, EventArgs e)

Message: Exception of type Microsoft.Exchange.OMA.DataProviderInterface.ProviderException was thrown.
UserMessage: A System error has occurred while processing your request. Please try again. If the problem persists, contact your administrator.
Source: Microsoft.Exchange.OMA.UserInterface
Stack trace:
   at Microsoft.Exchange.OMA.UserInterface.Global.Session_Start(Object sender, EventArgs e)
   at System.Web.SessionState.SessionStateModule.RaiseOnStart(EventArgs e)
   at System.Web.SessionState.SessionStateModule.CompleteAcquireState()
   at System.Web.SessionState.SessionStateModule.BeginAcquireState(Object source, EventArgs e, AsyncCallback cb, Object extraData)
   at System.Web.AsyncEventExecutionStep.System.Web.HttpApplication+IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

For more information, see Help and Support Center at

What a mess.  But I recognized that “(403) Forbidden” as a web server error (although not on the actual OMA directory).  Combining that with info from similar OMA issues, I checked the /exchange-oma virtual directory’s settings, and aha! it was denying access to all IP addresses except and one we don’t use.  It was not making an exception for the primary local address.  So I added that and all’s now good.

So when you’re having OMA problems, try the usual stuff (including checking the OMA virtual directory), then also check settings on the exchange-oma virtual directory.

Lesson learned.

Update 2008-11-07:
Ha!  I was troubleshooting for a customer, and found my own post (top of the google to ya, 3 years later!)  It wasn’t the same issue, but it was similar enough to set me on
the right track.