Re: [css-syntax] Error-correcting unclosed empty url()

On Tue, 07 Oct 2014 23:47:11 +0200, Tab Atkins Jr. <jackalmage@gmail.com>  
wrote:

> Right now, the Syntax spec defines url() to be handled the same way as
> anything else when you hit of EOF while it's unclosed - it gets closed
> and is valid.
>
> That is, the following two examples are equivalent per spec, assuming
> the file ends after the last character:
>
>     foo { background-image: url(foo
>
>     foo { background-image: url(foo)}
>
> This behavior is inconsistent across browsers - Firefox agrees with
> the spec and treats these as equivalent, but Chrome refuses to
> recognize a url() as valid until it sees the close parenthesis.
>
>
> Browsers currently agree in behavior when the url() is completely empty,  
> like:
>
>     foo { background-image: url(
>
> They all treat this as invalid and throw out the declaration.

Gecko treats it as url("").
IE11 treats it as none.
Other browsers throw out the declaration.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3244

> But
> they all consider this valid:
>
>     foo { background-image: url()
>
> So the error-handling is inconsistent with how other functions work.
>
>
> How should we proceed?  I suggest keeping the current spec behavior.
> When there's some content in the url(), this matches at least one
> browser.  When it's empty, it matches no browser I've tested, but it's
> consistent with the rest of the platform, and I doubt content is
> relying on this behavior.

Yeah, I agree the syntax spec is OK as is.

IE's behavior for url( is the same as what it does for url(""). HTML  
generally also has this behavior for resources that are embedded, like  
<img src=""> doesn't fetch anything (but <a href=""> is allowed).

Maybe we should make CSS special-case the empty string URL, like IE and  
HTML?

-- 
Simon Pieters
Opera Software

Received on Wednesday, 8 October 2014 07:46:43 UTC