url() and attr() not working nicely together




15 years ago
15 years ago


(Reporter: Roland, Unassigned)



Firefox Tracking Flags

(Not tracked)




15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030811 Mozilla Firebird/0.6.1+
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030811 Mozilla Firebird/0.6.1+

The url() function should accept more flexible input instead of just URI,
allowing combining plain text strings and attr() function output values.

I know that the W3C spec does not say a word about it (in fact where it
discusses the url() function it specificly says that url() function should treat
everything inside the parenthesis as a literal URI - except quotes).

If that would be possible, I could do for example something like that:

In a CSS:
  option:before {
    content: url("flags/tiny-" attr(value) "-flag.gif");

And in a HTML:
  <label>Select a language: </select>
  <select name="languages">
     <option value="en">English</select>
     <option value="et">Estonina</select>
     <option value="fi">Finish</option>
     <option value="ru">Russian</select>

Reproducible: Always

Steps to Reproduce:
1. Create an HTML with the single select box I described above.
2. Create style section in that HTML header and paste the CSS snipet from above.
3. Create flag images for the select box optin elements (one for each language)
4. Save all that stuff
5. Open in Mozilla based browser

Actual Results:  
Nothing special will happend - Yo'll just get the plain select box You always
get, because url() function does not recognize anything except literal URI as an

Expected Results:  
I should get nice flag before each option item, when trying to select an item
form select box.

Actually this should not be limited to generated content only - It could also
easily be used with list-style-image background-image property values or in fact
anywhere where URI is needed...
If we did this, we would have to call it -moz-url(), not url(), since it would
be a pretty blatant violation of the specification otherwise.

And as a matter of fact, parsing url() is already very difficult; parsing your
proposal would be even more so.  Perhaps there is some way to make the parsing
easier, but I don't see one offhand.

What I suggest you do is to bring this up in the proper forum: www-style@w3.org.
 Then it can be discussed and incorporated into the spec in a reasonable form if
people find such.  This sounds like a reasonable candidate for inclusion in
CSS3, if the parsing issues can be resolved.
Last Resolved: 15 years ago
Resolution: --- → WONTFIX

Comment 2

15 years ago
As I see it - this proposal is not so much in violation with the spec but rather
it strives to extend that spec since with the new functionality the standard way
will still be supported. But anyway - You are right about the forum thing - it
should definately be discussed as an addition to he css3 at w3c.

Parsing should really not be much more difficult than parsing value of "content"
property value with the only exception that the final product string should then
be evaluated as possible URI and acted upon accordingly.
Basically paraphrasing w3c spec the syntax should roughly look something like:
URI: uri( S* [<uri> | [<string> || <attr>]+] S* )

The main point is that these css functions should also act as functions not
merely as alternate ways to mark up mostly static values...
Actually, any extension of the CSS spec that does not use a vendor prefix is 
automatically a spec violation, since it breaks forward-compatible parsing.
You need to log in before you can comment on or make changes to this bug.