[csswg-drafts] [css-syntax] Error-correcting unclosed empty url() (#3598)

tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-syntax] Error-correcting unclosed empty url() ==
(migrated from the mailing list)

**Tab Atkins said:**

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

----------------

**Greg Whitworth said:**

> > 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.
> 
> FWIW: IE renders the same as well

------------------

**Tab Atkins said:**

> Do you mean it treats them the same, like Firefox?

--------------------

**Greg Whitworth said:**

> Yes, here is a screenshot: http://imgur.com/CiVRgnW
> 
> Here is the fiddle: http://jsfiddle.net/3pu104rb/

------------------

**Simon Pieters said:**

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

----------------

**Tab Atkins said:**

> That's sensible behavior, and matching HTML and IE is a big plus. I'll propose this tomorrow.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3598 using your GitHub account

Received on Saturday, 2 February 2019 00:29:01 UTC