Has @apply Shipped In Chrome 51?

[PhistucK]

The latest Chromium beta blog post as well as https://www.chromestatus.com/features/5753701012602880 note that CSS @apply has shipped in Chrome 51.

That seems wrong, as I only saw an intent to implement thread and the canary does not have it on by default (also, the Developer Tools feature does not show @applied CSS properties, which significantly hurts debuggability and may indicate a serious bug).

Relatedly -

- The pipe notation ("KeyboardEvent |key|") is not so familiar externally, I would just use a point ("KeyboardEvent.key") or nothing at all ("KeyboardEvent key").

- It is not canvas.filters (the attribute is not on <canvas>, it is on its context), if anything, it is CanvasRenderingContext2D.filters (or replace the point with a space, like the above point).

- In order to be consistent with the rest of the post, a point should be used.

- "onbeforeunload()" is weird (the developer never calls this function, it only assigns a function to this attribute), either "beforeunload event" or "onbeforeunload" make sense.

Thank you for keeping everything up to date and as accurate as possible, these blog posts are very helpful!

☆PhistucK

[Domenic Denicola]

From: blin...@chromium.org [mailto:blin...@chromium.org] On Behalf Of PhistucK

> - The pipe notation ("KeyboardEvent |key|") is not so familiar externally, I would just use a point ("KeyboardEvent.key") or nothing at all ("KeyboardEvent key").

Please don't use KeyboardEvent.key. KeyboardEvent.key is undefined. You may instead be talking about KeyboardEvent.prototype.key.

> - It is not canvas.filters (the attribute is not on <canvas>, it is on its context), if anything, it is CanvasRenderingContext2D.filters (or replace the point with a space, like the above point).

Similarly, CanvasRenderingContext2D.filters is undefined.

[PhistucK]

While I agree it is much more accurate, developers are more familiar with x.y rather than x.prototype.y and it is not as confusing as it seems to both of us.

Anyway, the rest of the post (and all of the previous posts) omits .prototype, so this goes way back and should be fixed everywhere, if this is decided.

☆PhistucK

[Ali Juma]

On Fri, Apr 29, 2016 at 2:57 PM PhistucK <phis...@gmail.com> wrote:

The latest Chromium beta blog post as well as https://www.chromestatus.com/features/5753701012602880 note that CSS @apply has shipped in Chrome 51.

That seems wrong, as I only saw an intent to implement thread and the canary does not have it on by default (also, the Developer Tools feature does not show @applied CSS properties, which significantly hurts debuggability and may indicate a serious bug).

Relatedly -

- The pipe notation ("KeyboardEvent |key|") is not so familiar externally, I would just use a point ("KeyboardEvent.key") or nothing at all ("KeyboardEvent key").

- It is not canvas.filters (the attribute is not on <canvas>, it is on its context), if anything, it is CanvasRenderingContext2D.filters (or replace the point with a space, like the above point).

Also, canvas filters are not shipping in 51, they're behind a flag in 51 (the Chrome Status entry is correct). 

[PhistucK]

Oops, looks like the Chrome Status entry for @apply is also correct (I could have sworn I saw something different, but http://platformstatustracker.azurewebsites.net/ would have caught it if it were so, I would guess).

So it would be great if you went over all of the features once more in order to make sure that none of them are behind a flag.

It would probably make it easier if ChromeStatus.com had an icon next to features that are not enabled by default (without opening every feature) as this can be confusing to web developers as well. I filed an issue.

☆PhistucK

[Samuel Li]

On Fri, 29 Apr 2016 at 14:11 PhistucK <phis...@gmail.com> wrote:

Oops, looks like the Chrome Status entry for @apply is also correct (I could have sworn I saw something different, but http://platformstatustracker.azurewebsites.net/ would have caught it if it were so, I would guess).

So it would be great if you went over all of the features once more in order to make sure that none of them are behind a flag.

It would probably make it easier if ChromeStatus.com had an icon next to features that are not enabled by default (without opening every feature) as this can be confusing to web developers as well. I filed an issue.

It does.

[PhistucK]

Oops. Right. Then the blog post should just be fixed...

☆PhistucK

[Ryan Schoen]

We've deleted the bullets around @apply and canvas filters, and removed the parentheses from onbeforeunload. Thanks for pointing these out! 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.