- From: Florian Rivoal <florian@rivoal.net>
- Date: Mon, 23 Mar 2015 09:17:32 +0100
- To: fantasai <fantasai.lists@inkedblade.net>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
> On 23 Mar 2015, at 01:43, fantasai <fantasai.lists@inkedblade.net> wrote:
>
> On 03/20/2015 01:44 PM, Florian Rivoal wrote:
>>
>>> On 20 Mar 2015, at 18:52, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>>
>>> On Fri, Mar 20, 2015 at 4:34 AM, Florian Rivoal <florian@rivoal.net> wrote:
>>>> One of the downside of this is that it requires double parentheses in simple cases:
>>>>
>>>> @import "http://example.com/foo.css" supports((display:flex));
>>>>
>>>> It made sense to mandate the parentheses in the @support rule, but they seem overkill here, and is probably surprising for authors. We could do:
>>>>
>>>> @import <url> [ supports(<supports-condition> | <declaration>) ]? <media-query-list>? ;
>>>>
>>>> which would let you write:
>>>>
>>>> @import "http://example.com/foo.css" supports(display:flex);
>>>
>>> I think fantasai brought this up as well. I can go either way, though
>>> I'll note that we explicitly rejected this for CSS.supports().
>>
>>
>> I forgot about that CSS.supports() is a little bit different though:
>>
>> CSS.supports("(display: flex)")
>>
>> The language boundary introduced by the quotes makes it a little bit less silly
>> in my mind to have to keep the parens.
>>
>> But I agree the difference isn't that strong.
>
> I think they're all silly and would prefer that we allowed dropping the
> unnecessary parens in all such cases.
I think they're both silly, and would agree with allowing dropping the unnecessary parens in both cases, but the lack of a language barrier in the case of @imports <url> supports(<supports-condition>); makes it more silly/surprising, so I care more about this one than the other.
- Florian
Received on Monday, 23 March 2015 08:17:57 UTC