Re: [css3-values] unresolvable URIs

(I am sorry but I typed public-iri in the Cc: line wrong.)

(12/04/08 18:19), Kang-Hao (Kenny) Lu wrote:
> (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.)
> 
> I think we should either:
> 
> 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 ===
> 
> You can construct a case of unresolvable/invalid URI by using a data:
> 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>
> 
> Results:
> 
> '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
> 
>

Received on Sunday, 8 April 2012 10:29:08 UTC