Kang-Hao (Kenny) Lu
2012-04-08 10:28:39 UTC
(I am sorry but I typed public-iri in the Cc: line wrong.)
(edge cases)
CSS 2.1 has this sentence
# User agents may vary in how they handle invalid URIs or URIs that
# designate unavailable or inapplicable resources.
which was removed in CSS3 V&U last August[1]. I can't find discussions
about this, in particular anything about invalid URIs, in the archive,
but I'll provide some data out of testing at the end of this mail, which
may or may not support this removal. Note that, the spec now says
# When a <url> appears in the computed value of a property, it is
# resolved to an absolute URL, as described in the preceding
# paragraph.
and it doesn't say what to do when this is not doable, and RFC 3986,
which is referenced, has plenty of these.
(By the way, the spec says
# RFC 3986, section 3, defines the normative algorithm for this
# process.
but RFC 3986 is listed as informative reference, which seems contradictory.)
A. reference the new URL spec[2] instead of RFC 3986.
B. reference both RFC 3986 and the new URL spec and also add
| It is undefined what UAs should do if URL resolving fails.
|
| Note: URI resolving doesn't fail for UAs implementing [URL].
where [URL] refers to the new URL spec. They should both be referenced
informatively is there's concern about the stability of the new URL spec.
I think I prefer A. since I doubt there's easy way to tell implementers
of new UAs which spec they should consult and the new URL spec is
probably more browser-matching.
Another URI-related question is the 'url' type parameter in attr(). The
spec says
# The default is a UA-dependent URI defined to point to a
# non-existent document with a generic error condition. (i.e. it
# shouldn't be an FTP URI that causes a DNS error, or an HTTP URI
# that results in a 404, it should be a nondescript error condition.)
Can we use something UA-independent, say, "about:blank" or something
else in the 'about' scheme? (Cced public-irc for this purpose)
== Data (out of testing) ==
=== Firefox11 ===
URI as a base and a random relative URL like the following
data:text/html,<style>div { background-image: url(x), none;
}</style><div></div><script>alert(window.getComputedStyle(document.querySelector('div')).backgroundImage)</script>
'background-image' (creatively?) follows CSS 2.1 which has
# Computed value: absolute URI or none
and gives 'none, none' for the above case, although this is (arguably)
no longer conforming in CSS3 B&B which has
# Computed value: as specified, but with URIs made absolute
'cursor' removes unresolvable URIs in the list. (e.g.
"url(http://www.example.com/), url(x), auto" ->
"url(http://www.example.com/), auto")
'content' changes unresolvable URIs to url(invalid-url:). (e.g.
"url(http://www.example.com/) url(x)" -> "url(http://www.example.com/)
url(invalid-url:)")
=== IE9 ===
url("%") is unresolvable. (I think this is probably just a buggy edge
case, and I doubt other cases exist...)
'background-image' is like Firefox
'cursor' gives "%", so this is clearly a bug. (e.g.
"url(http://www.example.com/), url(x), auto" -> "%")
'content' gives "none".
=== Chromium18 ===
=== Opera12alpha ===
No strange behavior observed. Every URI seems resolvable and only fails
at the network layer.
(Please tell me if you find unresolvable URIs for these browsers or a
systematic way to try out IE.)
[1] https://dvcs.w3.org/hg/csswg/file/324c6ef7c447/css3-values/Overview.html
[2] http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html
Cheers,
Kenny
CSS 2.1 has this sentence
# User agents may vary in how they handle invalid URIs or URIs that
# designate unavailable or inapplicable resources.
which was removed in CSS3 V&U last August[1]. I can't find discussions
about this, in particular anything about invalid URIs, in the archive,
but I'll provide some data out of testing at the end of this mail, which
may or may not support this removal. Note that, the spec now says
# When a <url> appears in the computed value of a property, it is
# resolved to an absolute URL, as described in the preceding
# paragraph.
and it doesn't say what to do when this is not doable, and RFC 3986,
which is referenced, has plenty of these.
(By the way, the spec says
# RFC 3986, section 3, defines the normative algorithm for this
# process.
but RFC 3986 is listed as informative reference, which seems contradictory.)
A. reference the new URL spec[2] instead of RFC 3986.
B. reference both RFC 3986 and the new URL spec and also add
| It is undefined what UAs should do if URL resolving fails.
|
| Note: URI resolving doesn't fail for UAs implementing [URL].
where [URL] refers to the new URL spec. They should both be referenced
informatively is there's concern about the stability of the new URL spec.
I think I prefer A. since I doubt there's easy way to tell implementers
of new UAs which spec they should consult and the new URL spec is
probably more browser-matching.
Another URI-related question is the 'url' type parameter in attr(). The
spec says
# The default is a UA-dependent URI defined to point to a
# non-existent document with a generic error condition. (i.e. it
# shouldn't be an FTP URI that causes a DNS error, or an HTTP URI
# that results in a 404, it should be a nondescript error condition.)
Can we use something UA-independent, say, "about:blank" or something
else in the 'about' scheme? (Cced public-irc for this purpose)
== Data (out of testing) ==
=== Firefox11 ===
URI as a base and a random relative URL like the following
data:text/html,<style>div { background-image: url(x), none;
}</style><div></div><script>alert(window.getComputedStyle(document.querySelector('div')).backgroundImage)</script>
'background-image' (creatively?) follows CSS 2.1 which has
# Computed value: absolute URI or none
and gives 'none, none' for the above case, although this is (arguably)
no longer conforming in CSS3 B&B which has
# Computed value: as specified, but with URIs made absolute
'cursor' removes unresolvable URIs in the list. (e.g.
"url(http://www.example.com/), url(x), auto" ->
"url(http://www.example.com/), auto")
'content' changes unresolvable URIs to url(invalid-url:). (e.g.
"url(http://www.example.com/) url(x)" -> "url(http://www.example.com/)
url(invalid-url:)")
=== IE9 ===
url("%") is unresolvable. (I think this is probably just a buggy edge
case, and I doubt other cases exist...)
'background-image' is like Firefox
'cursor' gives "%", so this is clearly a bug. (e.g.
"url(http://www.example.com/), url(x), auto" -> "%")
'content' gives "none".
=== Chromium18 ===
=== Opera12alpha ===
No strange behavior observed. Every URI seems resolvable and only fails
at the network layer.
(Please tell me if you find unresolvable URIs for these browsers or a
systematic way to try out IE.)
[1] https://dvcs.w3.org/hg/csswg/file/324c6ef7c447/css3-values/Overview.html
[2] http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html
Cheers,
Kenny