Re: [css-variables][css-conditional] passing lone surrogates to CSS.supports()

On Mon, Aug 26, 2013 at 7:04 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> The definition of the two argument version of CSS.supports() says:
>
>   When the supports() method is invoked with two arguments property and
>   value, it must return true if property is a literal match for the
>   name of a CSS property that the UA supports, and value would be
>   successfully parsed as a supported value for that property. (Literal
>   match means that no CSS escape processing is performed, and leading
>   and trailing whitespace are not stripped, so any leading whitespace,
>   trailing whitespace, or CSS escapes equivalent to the name of a
>   property would cause the method to return false.)
>
> What is the set of custom property names that the UA supports?  Is it all
> property names that begin with "var-" and are at least 5 characters long?
> And are these Unicode characters, or UTF-16 code units?
>
> I am wondering about:
>
>   CSS.supports("var-\ud800", "a")
>
> If we are thinking of property names as being sequences of UTF-16 code
> units, then there is no way of writing that property name, since `var-\d800`
> will be interpreted the same as `var-\fffd`.  And if that's the case, should
> "var-\ud800" be considered to be the name of a supported (custom) property?

Given Javascript string escaping rules, the literal string you're
testing for is "var-" followed by u+d800, right?

In that case, yeah, you can't actually write that property name in CSS.  But...

> If we are thinking of property names as being sequences of Unicode
> characters, then we need to specify how the first argument string is
> interpreted.  If we used
> http://dev.w3.org/2006/webapi/WebIDL/#dfn-obtain-unicode then that string
> would get converted to the sequence of characters <'v', 'a', 'r', '-',
> U+FFFD>, and then we do have the name of a supported (custom) property.

Yes, I think we should do this.

> A related case is:
>
>   CSS.supports("var-\0", "a")
>
> Again, in CSS syntax `var-\0` would be treated the same as `var-\fffd`, but
> if we're doing a literal match of the property name, then there is no way we
> could ever have a custom property named with a NUL in its name.

This successfully returns a U+0000 as the fifth character using
WebIDL's algo, right? In that case, yeah, I guess this shouldn't be a
supported property name.

~TJ

Received on Tuesday, 27 August 2013 02:49:30 UTC