- From: Simon Pieters <simonp@opera.com>
- Date: Thu, 26 Nov 2015 09:56:55 +0100
- To: "Florian Rivoal" <florian@rivoal.net>
- Cc: "www-style@w3.org" <www-style@w3.org>, "L. David Baron" <dbaron@dbaron.org>
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