I've been working on somewhat unrelated IE polyfill work, and have come across a technique y'all might find interesting. I want to run it by the community first to get a sanity check before investing any time submitting patches for CSS3PIE.
(1) Have a second HTC file whose sole purpose is to scan the browser's stylesheets for unsupported properties or idioms. This behavior would be bound to body (for example).

(2) Rewrite the rules that use :hover to .pie_hover for IE6. Similar for :active. Bind mouseover events to the body as a delegate so that only one event handler must be bound (instead of per-element).

(3) Rewrite the rules that have "display:inline-block" to be "display:inline;zoom:1" for IE6/7.

(4) Rewrite the rules so that "opacity=x" are converted to "filter:alpha(opacity=x)" for IE6/7/8.

(5) Rewrite the color property (or -pie-color) so that rgba, hsl, and hsla values are supported. Obviously, discovering the background color would be needed for any alpha values.

(6) Add a -pie-ignore property so that individual polyfills can be skipped, e.g., box-shadow, opacity, etc.

--

So far, this will have taken (a limited amount of time) for stylesheet/rule scans and other initialization, but no appreciable runtime cost except for opacity.

The next is where the greatest cost would come from.

(7) Add the standard CSS3PIE behavior to each appropriate element, so that you don't have to specify each and every rule to use CSS3PIE.

(8) Add form validation for HTML5 attributes such as @placeholder, @type=email, etc. via behavior.

Edit: Forgot one.

(9) Add support for position:fixed to IE6.

The goal? Make IE6/7/8 less of a separate code path in future projects and reducing the need for most of the common CSS preprocessors. I have most of these items working and have only recently noticed some of the overlap of my work with CSS3PIE, such as with hover events. What do you all think? Worth using or off my rocker?

Oops, misread the code. You're already doing this.

Hi, thanks for your post!



Actually I don't think we are. I'd be very interested in trying this though -- currently we attach listeners to the individual elements but we use IE's mouseenter/mouseleave events rather than mouseover/mouseout, which prevents us from having to walk the DOM ancestry manually on every event. I'd love to see a performance comparison between the two approaches.

Back to your original post...



There has been at least one attempt by another user to do something like this, but it was done using a normal .js script rather than a .htc. I'm not certain of what benefits if any using a htc for this would bring, what are your thoughts on that?



For my knowledge, what's the benefit here? PIE does add zoom:1 to its own target elements FWIW.



A fine idea for non-PIE'd elements, but keep in mind that PIE doesn't honor opacity or the alpha filter in its own rendering: https://github.com/lojjic/PIE/issues/46 -- and it's not as simple as just giving PIE's rendering element the alpha filter as well, since giving two overlapping siblings the same opacity is not the same as giving a common parent that opacity, as they're composited separately rather than as a single unit.



PIE doesn't handle foreground color in any way currently, are you proposing to add support?



This can already be done, since PIE recognizes and gives preference to -pie- prefixed versions of all the properties it supports. So to prevent box-shadow rendering you'd just add -pie-box-shadow:none.



I agree that this is the point of greatest cost. I'm not sure I agree that the prior steps have a negligible cost, though I'm happy to be surprised by numbers

What are your thoughts on how adding the behavior in a stylesheet rewrite step will affect apparent performance versus attaching the behavior statically? One of the great benefits of behaviors is that they run when the *element* is ready and thus don't have to wait for the whole document to be parsed, essentially eliminating the dreaded FOUC (at least when the cache is primed). The longer the behavior attachment is delayed the greater the possibility of FOUC, I would think.



Not really something I want to bring into PIE, but there are other polyfills for these HTML5 form features that perhaps you could utilize and/or integrate with.



Reasonable.

Thanks for the quick reply!



The benefit is that you can just add to your stylesheet to globally enable and disable. Since these are styling polyfills, it seems to me that it makes more sense to have the control for them within the CSS itself rather than dealing with JS/CSS synchronization.



I wasn't talking about just existing PIE behavior elements. After rewriting the stylesheet rules, there is no more runtime cost -- no event handlers, binding/unbinding, etc. It means just works.



How different are they? "Perfect is the enemy of good."



Yes, I've got this working via stylesheet rule rewrite. If it knows background-color, it can do the required mixing so IE8- gets the same color as modern browsers even though it doesn't actually support alpha values. Once again, not perfect, but better than existing.



Good to know. I was thinking along the lines of , , and/or both for brevity and to speed stylesheet scanning. (The fastest behavior binding is the one you don't have to make.)



That's a concern of mine as well. Scanning time increases the older the browser too because of more to do. For example, IE7/8 don't need a fix for "fixed" position, only IE6 needs help with ":hover", etc.



So far on my copy of IE6 on my circa 2007 Dell laptop, the FOUC mostly comes into play with my "position:fixed" solution and input placeholder. PIE performance seems good. That said, my test stylesheets aren't that big, and currently parsing doesn't begin until the head tag is closed. That's the biggest delay, I think. It may be possible to watch stylesheets as they get loaded and do this incrementally, but that's a more complicated solution. Lends validity to the JS instead of HTC approach though.



You're right about the validation types. Placeholder, I've found, is a more visual solution than functional. Also, it would need to watch the associated input field for styling changes. I guess that's why I'm leaning toward it. Even if it doesn't get integrated into PIE proper, I think you'd like my placeholder implementation: no editing of the "value" property (so no conflicts with form submission and checking for "value === placeholder") and styling matches what Firefox and Chrome do wrt fonts and colors. I'll see if I can post a public example.

[/quote]

I implemented it via CSS expressions (transparent to the user, they only specify "fixed"). Yes, I know CSS expressions are performance killers, but the choice boils down to having it work pretty well and having it not work at all. I tried with onscroll events, but not only did it not look as good, it also interacted badly with the user grabbing the scroll bar.

The real difficulty though came from having to check for PIE background elements and watching scroll elements. It seems to me a common refactor where PIE was aware of this possibility could simplify this greatly.

Oh! Almost forgot.

The stylesheet scanning behavior would have to be a separate HTC file. This means that the functionality would be inherently optional. Either make the explicit CSS additions yourself or have it done automatically knowing that there may be a tradeoff in speed.

So I'm curious: do you get tired being right all the time?

Yeah, the scanning behavior only loaded after the body tag was fully loaded. Bah. Separate JS file it is.

Hello

@ttfkam, I am very interested in every project trying to fix IE bugs, so I salute your work.

Have you already seen "IE7.js" and "Webshims Lib" ? Those libs fix a lot of IE bugs you mention, and many many more.

If you do a CSS preprocessor-and-fixer, there's a feature I'd love to have in it:

add a -pie-background CSS rule for every "background: linear-gradient" or "background: rgba", so we don't have to write them manually!

I asked Lea Verou to add this feature in her lib "prefixfree" but she's not interested, (normal, that's out-of-scope)

and I tried to write a IE7.js add-on for this but it doesn't work and I can't get any help.



@jason,



I didn't know that! It's great, and should be documented! (or is it?)


@everyone



I started a topic on this forum to work on this feature, with another approach (using PIE.js)
Since then, I simplified my code a lot.
Now, to enable PIE on every element with CSS3 properties, you can write this at the end of your HTML page:



This PIE enabler (css3()) has very good performances and is library independant. Maybe it could be mentioned in the PIE.js documentation?
What about including it in PIE.js?

@xem Nice but the main problem is about performance when using pie.js is not really important from my point of view how is applied And other problem to apply pie.js on elements when dom was modified
However your work looks fine