The spec - http://www.w3.org/TR/CSS21/syndata.html#value-def-uri -
seems clear that url() is required (though quotes are not required).
I'd favor an option #3:
- Convert url(); anything other than than this syntax gets dropped
and logged with a warning
But we should talk about the manner of URL conversion here; IMO,
the rules should be:
- URLs beginning with a slash get prefixed with the context root
(like other such URLs in JSF)
- URLs beginning with two slashes get trimmed to a single slash
(special Trinidad URL rule, already used in Trinidad components)
- Relative URLs get interpreted as relative to the original .css file,
and converted so that they are still valid references to the
desired file.
- Other URLs (e.g., URLs with server names) are left alone.
So, if the context path is MyApp, and the skin is
at MyApp/skins/mySkin/skin.css
url('http://foo/my.gif') -> http://foo/my.gif
url('/my.gif') -> /MyApp/my.gif
url('//images/my.gif') -> /images/my.gif
url('images/my.gif') -> /MyApp/skins/mySkin/images/my.gif
url('../../images/my.gif') -> /MyApp/images/my.gif
-- Adam
On 8/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Hello all,
I provided a patch for ADFFACES-121. However, I'm not totally satisfied
with it.
Before the patch, the code was only converting the urls of
background-image property when placed inside url( ). My patch converts all
values inside url( ) as well as background-image property value when not
placed inside url( ). For instance:
Skin:
background: url('images/myGif.gif');
background: images/myGif.gif;
background-image: url('images/myGif.gif');
background-image: images/myGif.gif;
Result with "MyApp" context root:
background: url('/MyApp/skins/mySkin/images/myGif.gif');
background: images/myGif.gif;
background-image: url('/MyApp/skins/mySkin/images/myGif.gif');
background-image: /MyApp/skins/mySkin/images/myGif.gif;
It's a kind of inconsistency that could mix the user I think. I therefore
see two possibilities:
1. Convert only but all values specified inside url( ), leaving others
unchanged.
2. Make sure the hard coded list of property names allowing property
values is exhaustive and document it accordingly.
Which one would be better? My vote goes to 1. since it will be easier to
document and maintain.
Regards,
Simon Lessard
Fujitsu Consulting
