Hi, and thanks for CSS3PIE! It's working very well for implementing image borders and rounded corners.

A few notes. I'm including the htc in a JSF application running on IBM Websphere server.

First thing I had to do was configure my server to handle the htc mime-type. This is probably already documented, but just a tip.

The other, non-fatal error I was getting had to do with the htc itself. First of all, the component wasn't wrapped in an html tag with namespacing: (see example: http://www.w3.org/TR/NOTE-HTMLComponents#property - scroll down a bit). I added those and got rid of one parsing error about the PUBLIC namespace (not bound). Secondly, I was still getting parsing errors on the script block without enclosing in CDATA tags - in my case, I added commented tags for XHTML validation:



I don't know whether these additions would break the htc in other environments, but if not, maybe they'd be applied in an update. In any case, maybe these tips will help someone else using CSS3PIE.

Thanks again.

I don't understand, is your JSF app trying to parse the HTC file for some reason? I've never heard of anybody needing to do that. It should just be a statically served resource, like an image.

Evidently JSF DOES attempt to parse the htc file, probably because it doesn't natively know how to handle a file that's script wrapped in XML with namespaced tags, which is what JSF natively parses. It never killed my application, but my server console was throwing errors every time I loaded a page in IE (every page uses PIE). As I also said, at first, my server didn't know what to do with an htc file, because the mime-type wasn't defined, and with JSF apps, you can do this at the configuration level within the app or on the server itself. The parsing errors cropped up after that configuration was in place.

As a follow-up to my first post, though, two questions:

Within the htc file, is there a reason NOT to:

1) wrap the outer PUBLIC tags in a set of html tags with namespacing -


2) enclose the script in CDATA tags?

I honestly don't know the answer to these questions, but the dual work-around did seem to solve parsing errors in my application.

I honestly don't know if those things would have any side effects. I suspect not, but I have no basis for that other than the experience you've related. I don't think I've ever come across another htc file that did those things, but that doesn't mean much.

Well, I was really just putting this out there for anyone else with a similar experience. I don't have other experience with htc files in other deployment environments, but it did strike me that the w3c page for HTML Components shows every example wrapped in an HTML tagset with xml namespacing for PUBLIC - that seems to be a default recommendation. As for using CDATA tags, the need really depends on how you're serving your pages, so it might be note to end-users, but not something to include by default. Thanks.

Now in a JSF2 environment, and HTC files simply don't work with my stack in anything prior to IE9, no matter what I do. Oh, well.