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.

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?

Thu Jun 28, 2012 6:08 pm

ttfkam

Joined: Thu Jun 28, 2012 5:44 pmPosts: 6

Re: An CSS3PIE Autoloader

ttfkam wrote:

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).

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

Thu Jun 28, 2012 6:21 pm

jason

Joined: Wed Jul 14, 2010 11:46 amPosts: 1452

Re: An CSS3PIE Autoloader

Hi, thanks for your post!

Quote:

Quote:

Bind mouseover events to the body as a delegate

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

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...

Quote:

(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).

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?

Quote:

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

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

Quote:

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

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.

Quote:

(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.

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

Quote:

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

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.

Quote:

(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.

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.

Quote:

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

Reasonable.

Thu Jun 28, 2012 7:40 pm

ttfkam

Joined: Thu Jun 28, 2012 5:44 pmPosts: 6

Re: An CSS3PIE Autoloader

jason wrote:

Hi, thanks for your post!

Thanks for the quick reply!

jason wrote:

Quote:

(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).

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?

The benefit is that you can just add

Code:

body { behavior:url('pieloader.htc'); }

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.

jason wrote:

Quote:

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

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

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

Code:

display:inline-block;

just works.

jason wrote:

Quote:

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

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.

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

jason wrote:

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

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.

jason wrote:

Quote:

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

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.

Good to know. I was thinking along the lines of

Code:

-pie-ignore: box-shadow, opacity;

,

Code:

-pie-ignore: all;

, and/or

Code:

-pie-ignore: all except box-shadow;

both for brevity and to speed stylesheet scanning. (The fastest behavior binding is the one you don't have to make.)

jason wrote:

Quote:

(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.

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

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.

jason wrote:

What are your thoughts on how adding the behavior in a stylesheet rewrite step will affect apparent performance versus attaching the behavior statically?

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.

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.

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.

jason wrote:

Quote:

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

Reasonable.

[/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.

Fri Jun 29, 2012 11:09 am

ttfkam

Joined: Thu Jun 28, 2012 5:44 pmPosts: 6

Re: An CSS3PIE Autoloader

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.

Fri Jun 29, 2012 11:15 am

ttfkam

Joined: Thu Jun 28, 2012 5:44 pmPosts: 6

Re: An CSS3PIE Autoloader

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.

Fri Jun 29, 2012 11:50 am

xem

Joined: Thu Apr 07, 2011 3:23 amPosts: 73

Re: An CSS3PIE Autoloader

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,

Quote:

So to prevent box-shadow rendering you'd just add -pie-box-shadow:none.

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

@everyone

Quote:

(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.

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?

Tue Jul 03, 2012 2:34 am

rulernature

Joined: Tue Nov 29, 2011 1:26 amPosts: 38

Re: An CSS3PIE Autoloader

@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

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum