Hi,

I'm a big fan of PIE since, like, a year, and admire all the efforts made to push old IEs beyond their limits.

Speaking of limits, I think you explained in your blog why background images paths couldn't be relative to the CSS file, but relative to the HTML file, because of the HTC behavior not related to the css file path.

Okay, but would it be possible to fix that in PIE.js?

Can we dream of a PIE.js allowing -pie-background: url(./images/some_image.png); which path would be relative to the css file, and would work on any html page, whereever it's placed?

Thanks for your thoughts on that.

Thanks for the kind words!

I do have some thoughts around this... unfortunately none of them are perfect. The PIE.js version suffers from the same limitation of the behavior version: the script has no visibility into what stylesheet a particular style was declared in. So all the script sees is the string "url(./images/some_image.png)", and it doesn't know what stylesheet that was declared in, so (for now) it just makes a blanket assumption that it's relative to the HTML file. I know, it sucks.

My thoughts are as follows:

1) If there is only a *single* stylesheet linked from the HTML page, or multiple stylesheets that are all *in the same external directory*, then we can safely assume what the base path should be for any relative paths declared therein. This would of course fail as soon as there are multiple stylesheets in different directories, which is very often the case.

2) It would be trivial to add a way for users to specify a custom base URL to be used instead of the HTML file path. Something like -pie-base:url(/my/base/css/directory); -- this adds a little bit of flexibility but unfortunately would be global across all stylesheets, so you couldn't set a different base URL for each stylesheet.

3) I've purposely steered well clear of anything that would require actually parsing stylesheets, as that takes a huge performance hit that I feel is unacceptable in most cases. But I might be open to adding something that would parse the stylesheets and resolve/rewrite relative URLs that it finds, as long as it would be controlled by an opt-in flag (e.g. -pie-resolve-relative-urls:true;) that is disabled by default. It might even be a separate .js script, that way it could resolve behavior urls properly too.

Anyone else have thoughts on this?

Thanks for the answer!

I'm not a JS expert, but I'm almost sure JS can know which CSS file a CSS rule comes from. I've seen that in Firebug Lite. (The JS light adaptation of the famous Firefox add-on Firebug)

Here's the official page: http://getfirebug.com/firebuglite (it's great because we can install it as a smart bookmark that launches the JS app on any page and on any browser)

Here's a screenshot showing that it can know in which CSS file each rule is written: http://www.techzene.com/wp-content/uplo ... g-Lite.png

Firebug lite is open source.

But you're making me doubt indeed, maybe Firebug lite just reads the content of each CSS file to know all that... maybe not. But I used it and I noticed that even with heavy CSS files, Firebug lite has never caused browser speed issues on my computer. So maybe PIE could do the same without all the problems you thought that would cause?

I also agree to the idea of introducing a conf var with a user-defined path.


PS: if PIE could actually read the content of the CSS files, that would also allow it to "understand" background instead of -pie-background, no? Anyway, if that "-pie-resolve-urls = true" could exist, i'd totally buy that! (oh waitasec, it's free...).

Thanks again for all that you do.

Right, I never said it was impossible, only that it requires parsing/walking stylesheets and that does not perform well. Firebug Lite, for instance, works ok on small pages but on complex pages I've seen it grind IE to a halt. That said, I don't know how much of that time is taken reading the stylesheets versus other tasks Firebug Lite performs; I'm open to getting exact numbers on that.