Re: [css3-values] unresolvable URIs

(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.

This was defined in some other random section of CSS2.1:
   http://www.w3.org/TR/CSS21/cascade.html#computed-value
   # The computed value of URIs that the UA cannot resolve to absolute
   # URIs is the specified value.

I've now copied this over into css3-values. Let me know if this
addresses your comment.

> (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.)

Fixed.

> 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.

IIRC, the advice we received was to continue referencing RFC3986 for now.
So that's what we're doing.

> 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)

We've registered 'about:invalid' for this purpose and included it in
the spec.

Let me know if these responses are satisfactory.

~fantasai

Received on Monday, 16 July 2012 19:19:04 UTC