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

[Cay Horstmann]

1) I looked at https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=444
and the RI.

The RI rewrites only resources with MIME type text/css, and that is
just as well--grep found a few of my photos that happen to contain the
bytes for #{0} :-)

When the  ELEvaluatingInputStream.read method sees a #{([^}]*)} and
the EL can evaluate \1, then it gets replaced. I suppose that's safe
in the context of a CSS file. From the grammar at
http://www.w3.org/TR/CSS2/grammar.html, it appears that #{ can not
appear in a CSS file outside comments.

So, since the RI is already rewriting CSS files, it could rewrite
url(...) arguments as well. But frankly, I would feel better about
that if rewriting was a user-selectable option in the
h:outputStylesheet tag.

2) I still think that it would be better to add the library path to
the URL. Right now, the ?ln=xxx seems a vestige of an earlier time
when the version and resource prefix were also specified as request
parameters (see
http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature). That was
apparently not such a good idea and it must have gotten dropped.

So, the sensible thing to do would be to change
Resource.getRequestPath to include the library name before the
resource name. I realize that it is not backwards compatible, but now
is just about the last time this fix can be made. And it's hard to
imagine that someone actually relied on this behavior.

3) I tried to figure out how to deal with issues 548 and 740 in a way
that doesn't break too many things that aren't already broken. One
problem is that the way things are, versioning and localization
interact poorly.

Can you please look at at
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1423.
Apparently, versioning doesn't work inside a JAR. Ok, fine--versioning
in a JAR makes no sense anyway. Why JAR up obsolete stuff? But I do
not understand the resolution "This requirement could not be portably
implemented.  Given this, the next version of the specification has
been amended to remove this requirement."

Does that mean that you have given up on versioning altogether? Or
just in a JAR file?

Thanks,

Cay


On Wed, Sep 15, 2010 at 12:21 AM, Ed Burns <edward.burns at oracle.com> wrote:
> 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
>
> --
> | edward.burns at oracle.com | office: +1 407 458 0017
> | homepage:               | http://ridingthecrest.com/
> |  4 work days until handoff of JSF 2.1 change log to jcp
> |  3 work days until JavaOne 2010
> | 38 work days until DOAG 2010
> | 42 work days until JSF 2.1 Milestone 6
>