Re: [jsr-314-open-mirror] [jsr-314-open] outputStylesheet generates URLs that can't load url(...) in CSS
12:21 p.m.
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(a)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(a)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
1:05 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] outputStylesheet generates URLs that can't load url(...) in CSS
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(a)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
--
"There are two kinds of people in the world, those who believe there are two kinds of
people and those who don't."
— Robert Benchley
4:32 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] outputStylesheet generates URLs that can't load url(...) in CSS
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(a)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
>
>
1:49 a.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] outputStylesheet generates URLs that can't load url(...) in CSS
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(a)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(a)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(a)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
5217
days inactive
5218
days old
jsr-314-open-mirror@lists.jboss.org
3 comments
4 participants
participants (4)
-
Alexander Smirnov -
Cay Horstmann -
Ed Burns -
Ganesh