[jsr-314-open-mirror] [jsr-314-open] outputStylesheet generates URLs that can't load url(...) in CSS

[Alexander Smirnov]

I've already mentioned this problem before. It's not only limited to the
CSS; some JavaScript libraries that loads additional resources 'on the
fly' are also affected  (for example, that is the case for rich editors
like TinyMCE), so using it in JSF component requires a huge effort to
rewrite resource loading code and maintenance of forked branch. I guess
that there would be some other cases like XSL stylesheet or associated
RDF link that require relative urls.
 Also, the highly popular http proxy server Squid turns off caching for
url's with parameters by default.

On 09/14/2010 11:05 AM, Ganesh wrote:
> For stability as well as performance reasons I prefer Cay's proposal. To
> start css parsing and try to replace urls would produce slow and error
> prone algorithms even if the resource is entirely static.
> 
> Best regards,
> Ganesh
> 
> Ed Burns schrieb:
>> EB> I have already specified this in 2.1
>>
>> Just checked.  I hadn't committed it.  Now I have. [1]
>>
>> EB> The solution is to note that #{} el expressions are evaluated on
>> the way
>> EB> out when a CSS stylesheet is served up.
>>
>> EB> Therefore, in the url() syntax you can say something like this:
>> EB> EB> @import url(#{resource['this:layout.css']});
>> EB> @import url(#{resource['this:typography.css']});
>> EB> @import url(#{resource['this:colorAndMedia.css']});
>> EB> EB> Where "this" is a special keyword that means "the current
>> library".
>>
>>
>>>>>>> On Tue, 14 Sep 2010 08:44:55 +0700, Cay Horstmann
>>>>>>> <cay.horstmann at gmail.com> said:
>>
>> CH> Ed, the hardship with your proposed solution is that the CSS has
>> to be
>> CH> edited. That's not something that people will always want to do.
>> CH> Like I said, when the tag is called h:outputStylesheet, there is a
>> CH> reasonable expectation that you can serve up a style sheet.
>>
>> CH> In my current project, for example, the style sheet is automagically
>> CH> generated by some theme engine whatsit, and I don't want to touch it
>> CH> because I don't begin to understand it :-)
>>
>> CH> My remedy was to use
>>
>> CH> <link type="text/css" rel="stylesheet"
>> CH> href="#{request.contextPath}/skins/cupertino/skin.css"/>
>>
>> CH> It works for me because I can include that in a template, and
>> there is
>> CH> no relocation problem. But it's not going to work for everyone--after
>> CH> all, that's why h:outputStylesheet was invented in the first place.
>>
>> CH> I think this deserves a more serious solution, either by changing the
>> CH> URLs for resource retrieval, or by rewriting url(,,,) when serving up
>> CH> the CSS.
>>
>> I think we can specify that url expressions in CSS files whose value is
>> *not* an EL expression are automatically rewritten to be equivalent to
>> using the "this" syntax.
>>
>> For example the url() expression here
>>
>> CH> .ui-icon { width: 16px; height: 16px; background-image:
>> url(myicon.png); }
>>
>> would be served up as if it were written like:
>>
>> .ui-icon { width: 16px; height: 16px; background-image:
>> url(#{resource['this:myicon.png']}); }
>>
>> Is that ok?  If so, Cay, can you *please* file an issue in the
>> spec-public issue tracker?  JavaOne is consuming all my time and that
>> would really help.
>>
>> CH> NB. There is also the unpleasant issue of the resource localization
>> CH> that I keep kvetching about. Is a fix for that in the works?
>>
>> That's [2], and I had planned it for 2.1, but I don't have enough time.
>> If someone wants to help, I'd welcome it.
>>
>> Ed
>>
>> [1]
>> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=444
>>
>>
>> [2]
>> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=548
>>
>>
>