W3C home > Mailing lists > Public > www-style@w3.org > November 2015

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

From: Florian Rivoal <florian@rivoal.net>
Date: Thu, 26 Nov 2015 10:07:44 +0900
Cc: "www-style@w3.org" <www-style@w3.org>, "L. David Baron" <dbaron@dbaron.org>
Message-Id: <88B43360-5678-42D2-BDB5-A8B233156288@rivoal.net>
To: Simon Pieters <simonp@opera.com>

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

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

 - Florian
Received on Thursday, 26 November 2015 01:08:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:58 UTC