Re: [css-conditional][quirks] Quirks mode and @supports/CSS.supports

On Thu, 26 Nov 2015 02:07:44 +0100, Florian Rivoal <florian@rivoal.net>  
wrote:

>
>> On 26 Nov 2015, at 03:19, Simon Pieters <simonp@opera.com> wrote:
>>
>> What is the interaction between
>>
>> https://drafts.csswg.org/css-conditional/#at-supports
>> https://drafts.csswg.org/css-conditional/#the-css-interface
>>
>> ...and...
>>
>> https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk
>> https://quirks.spec.whatwg.org/#the-unitless-length-quirk
>>
>> Testing in  
>> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3765 it  
>> appears that in Blink/WebKit/Gecko apply the quirks in @supports, but  
>> not in CSS.supports(). Presto doesn't apply the quirks to @supports and  
>> doesn't have CSS.supports(). I haven't checked IE/Edge. I suggest we  
>> specify what Blink/WebKit/Gecko do.
>
> I did the implementation in Presto, and not applying the quirks was not  
> intentional. There was no rationale for it, only oversight. I agree that  
> @supports should match what the browser actually consumes, and if it  
> supports quirky things, then @supports should reflect that.

We could also say that the quirks don't apply in that context, like they  
don't apply in calc(). Quirks don't have to make sense, just be  
Web-compatible enough. But I don't see that supporting the quirks in  
@supports is a problem, so I don't mind taking the shortest path to  
interop here.

> Btw, why not do the same in CSS.supports()? Any particular reason there,  
> or are you just proposing aligning with implementations?

The latter. I don't know if it was deliberate in implementations. I  
stumbled over this at https://codereview.chromium.org/1475903002

-- 
Simon Pieters
Opera Software

Received on Thursday, 26 November 2015 08:57:31 UTC