[blink-dev] Intent to Ship: CSS Paint API

[Xida Chen]

Contact emails

ikilp...@chromium.org, xida...@chromium.org, fla...@chromium.org

Spec

https://drafts.css-houdini.org/css-paint-api/

TAG review: https://github.com/w3ctag/design-reviews/issues/140

Summary

The CSS Paint API defines a new way for developers to draw content into a CSS <image> during the paint phase of the rendering engine.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/A4PZz_mXOTg

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

https://github.com/GoogleChrome/houdini-samples/tree/master/paint-worklet

Interoperability and Compatibility Risk

Compatibility Risk: None, adding a new primitive to the web platform.

Interoperability Risk: None. By informing the specification we hope that this will allow us to ship a version of this API which is interoperable with other browsers. Our implementation might inform a change in the specification, which might result in a change in our implementation.

Edge: No public signal

Firefox: In development

Safari: No public signal

Web developers: Positive

Reference: https://ishoudinireadyyet.com/

Is this feature fully tested by web-platform-tests?

Yes.

https://github.com/w3c/web-platform-tests/tree/master/css-paint-api

OWP launch tracking bug

https://crbug.com/578252

Entry on the feature dashboard

https://www.chromestatus.com/feature/5685444318593024

[PhistucK]

The interoperability risk is pretty high - Blink is the first to ship this and Edge as well as Safari have no signals, which may mean they will never ship this.

The fact that Firefox is developing this (do you have a reference for this?) is encouraging, but it does not mean it is not risky.

Does the Blink interoperate with Gecko using their apparently in-development implementation?

It is a bit funny to have all of the browsers except Chrome (without any flag, I reckon) pass this test without even implementing the paint API themselves -

http://wpt.fyi/css-paint-api/invalid-image-constructor-error.html

Perhaps the test is wrong?

Same for a few others -

http://wpt.fyi/css-paint-api

☆PhistucK

--
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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALRxhAue66tgCPaG%3DKXF3QB54xHJ1%3Didho3b4TZbaa34K%2B0%3DoQ%40mail.gmail.com.

[Xida Chen]

Thanks for the feedback.

On Mon, Sep 11, 2017 at 9:00 AM PhistucK <phis...@gmail.com> wrote:

The interoperability risk is pretty high - Blink is the first to ship this and Edge as well as Safari have no signals, which may mean they will never ship this.

The fact that Firefox is developing this (do you have a reference for this?) is encouraging, 

but it does not mean it is not risky.

Yes, I quickly searched "PaintWorklet" in mozilla's code search and here are the links:

 https://dxr.mozilla.org/mozilla-central/source/dom/webidl/PaintWorkletGlobalScope.webidl

https://dxr.mozilla.org/mozilla-central/source/dom/worklet/PaintWorkletGlobalScope.h

https://dxr.mozilla.org/mozilla-central/source/dom/worklet/PaintWorkletGlobalScope.cpp

So I believe Firefox is developing this feature, unfortunately I don't know their progress on it.

 

Does the Blink interoperate with Gecko using their apparently in-development implementation?

Sorry that I don't fully understand this question, could you be a bit more specific?

If you are asking whether Blink and Gecko's implementation are following the same spec, then the answer is yes.

If you are asking whether their implementation is the same, then no.

 

It is a bit funny to have all of the browsers except Chrome (without any flag, I reckon) pass this test without even implementing the paint API themselves -

http://wpt.fyi/css-paint-api/invalid-image-constructor-error.html

Perhaps the test is wrong?

Same for a few others -

http://wpt.fyi/css-paint-api

Thanks for pointing this out. I do notice this issue: https://github.com/w3c/wptdashboard/issues/113 on wpt. My guess is that wpt is running chrome without any experimental flag, and that's why it is failing. But that doesn't explain why the other browsers pass some of the tests. I will investigate more. 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Emilio Cobos Álvarez]

FWIW, the bug tracking it in Gecko is:

https://bugzilla.mozilla.org/show_bug.cgi?id=1302328

That and dependent bugs don't seem very active though, and there doesn't
seem to be a real implementation yet, only IDL stubs. So I'm not sure
that count as "in development" in practice.

-- Emilio

> ☆*PhistucK*

>
> On Mon, Sep 11, 2017 at 3:22 PM, Xida Chen <xida...@chromium.org

> <mailto:xida...@chromium.org>> wrote:
>
> Contact emails
>
> ikilp...@chromium.org <mailto:ikilp...@chromium.org>,
> xida...@chromium.org <mailto:xida...@chromium.org>,
> fla...@chromium.org <mailto:fla...@chromium.org>
>
>
> Spec
>
> https://drafts.css-houdini.org/css-paint-api/
> <https://www.google.com/url?q=https%3A%2F%2Fdrafts.css-houdini.org%2Fcss-paint-api%2F&sa=D&sntz=1&usg=AFQjCNFvrHMk1YDaZK_mMfbjF9jVimg9Nw>

> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?

>
> Yes.
>
> https://github.com/w3c/web-platform-tests/tree/master/css-paint-api
>
>
> OWP launch tracking bug
>
> https://crbug.com/578252
>
>

> Entry on the feature dashboard <http://www.chromestatus.com/>

>
> https://www.chromestatus.com/feature/5685444318593024
>
> --
> 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

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALRxhAue66tgCPaG%3DKXF3QB54xHJ1%3Didho3b4TZbaa34K%2B0%3DoQ%40mail.gmail.com

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALRxhAue66tgCPaG%3DKXF3QB54xHJ1%3Didho3b4TZbaa34K%2B0%3DoQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

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

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALRxhAs91Hs9bekK5KKA8FwUQLiYZqUKE0qxGSTeH%3D_oJF%2BQaw%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALRxhAs91Hs9bekK5KKA8FwUQLiYZqUKE0qxGSTeH%3D_oJF%2BQaw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[PhistucK]

> If you are asking whether their implementation is the same, then no.

I am asking whether the same code that uses the CSS Paint API would currently work the same for Chrome and Firefox, assuming it only uses features that were implemented in both of the browsers.

However, according to the reply of Emilio, the answer is quite clearly - no, Chrome and Firefox do not interoperate.

And like Emilio stated, "In development" might be a bit too eager for the current state of the world.

Looks like they are prototyping, though -

https://bugzilla.mozilla.org/show_bug.cgi?id=1290021

☆PhistucK

Thanks for the feedback.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Emilio Cobos Álvarez]

Yeah, I guess the "Intent to experiment"[1] does count as a positive
signal though :)

-- Emilio

[1]:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/uI5bHZil2KU

On 09/11/2017 03:52 PM, PhistucK wrote:
>> If you are asking whether their implementation is the same, then no.
> I am asking whether the same code that uses the CSS Paint API would
> currently work the same for Chrome and Firefox, assuming it only uses
> features that were implemented in both of the browsers.
>
> However, according to the reply of Emilio, the answer is quite clearly -
> no, Chrome and Firefox do not interoperate.
> And like Emilio stated, "In development" might be a bit too eager for
> the current state of the world.
>
> Looks like they are prototyping, though -
> https://bugzilla.mozilla.org/show_bug.cgi?id=1290021
>
>

> ☆*PhistucK*

>
> On Mon, Sep 11, 2017 at 4:38 PM, Xida Chen <xida...@chromium.org
> <mailto:xida...@chromium.org>> wrote:
>
> Thanks for the feedback.
>
> On Mon, Sep 11, 2017 at 9:00 AM PhistucK <phis...@gmail.com
> <mailto:phis...@gmail.com>> wrote:
>
> The interoperability risk is pretty high - Blink is the first to
> ship this and Edge as well as Safari have no signals, which may
> mean they will never ship this.
> The fact that Firefox is developing this (do you have a
> reference for this?) is encouraging, 
>
> but it does not mean it is not risky.
>
> Yes, I quickly searched "PaintWorklet" in mozilla's code search and
> here are the links:
>  https://dxr.mozilla.org/mozilla-central/source/dom/webidl/PaintWorkletGlobalScope.webidl

> <https://dxr.mozilla.org/mozilla-central/source/dom/webidl/PaintWorkletGlobalScope.webidl>
> https://dxr.mozilla.org/mozilla-central/source/dom/worklet/PaintWorkletGlobalScope.h
> <https://dxr.mozilla.org/mozilla-central/source/dom/worklet/PaintWorkletGlobalScope.h>
> https://dxr.mozilla.org/mozilla-central/source/dom/worklet/PaintWorkletGlobalScope.cpp

> <https://dxr.mozilla.org/mozilla-central/source/dom/worklet/PaintWorkletGlobalScope.cpp>
> So I believe Firefox is developing this feature, unfortunately I
> don't know their progress on it.
>  
>
> Does the Blink interoperate with Gecko using their apparently
> in-development implementation?
>
> Sorry that I don't fully understand this question, could you be a
> bit more specific?
> If you are asking whether Blink and Gecko's implementation are
> following the same spec, then the answer is yes.
> If you are asking whether their implementation is the same, then no.
>  
>
>
> It is a bit funny to have all of the browsers except Chrome
> (without any flag, I reckon) pass this test without even
> implementing the paint API themselves -

> http://wpt.fyi/css-paint-api/invalid-image-constructor-error.html <http://wpt.fyi/css-paint-api/invalid-image-constructor-error.html>

> Perhaps the test is wrong?
> Same for a few others -
> http://wpt.fyi/css-paint-api
>
> Thanks for pointing this out. I do notice this
> issue: https://github.com/w3c/wptdashboard/issues/113
> <https://github.com/w3c/wptdashboard/issues/113> on wpt. My guess is
> that wpt is running chrome without any experimental flag, and that's
> why it is failing. But that doesn't explain why the other browsers
> pass some of the tests. I will investigate more. 
>
>
>
>

> ☆*PhistucK*

>
> On Mon, Sep 11, 2017 at 3:22 PM, Xida Chen

> <xida...@chromium.org <mailto:xida...@chromium.org>> wrote:
>
> Contact emails
>
> ikilp...@chromium.org <mailto:ikilp...@chromium.org>,
> xida...@chromium.org <mailto:xida...@chromium.org>,
> fla...@chromium.org <mailto:fla...@chromium.org>
>
>
> Spec
>
> https://drafts.css-houdini.org/css-paint-api/
> <https://www.google.com/url?q=https%3A%2F%2Fdrafts.css-houdini.org%2Fcss-paint-api%2F&sa=D&sntz=1&usg=AFQjCNFvrHMk1YDaZK_mMfbjF9jVimg9Nw>
>
> TAG
> review: https://github.com/w3ctag/design-reviews/issues/140

> Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
>
> Yes.
>
> https://github.com/w3c/web-platform-tests/tree/master/css-paint-api

> <https://github.com/w3c/web-platform-tests/tree/master/css-paint-api>
>
>
> OWP launch tracking bug
>
> https://crbug.com/578252
>
>

> Entry on the feature dashboard <http://www.chromestatus.com/>
>
> https://www.chromestatus.com/feature/5685444318593024

> <https://www.chromestatus.com/feature/5685444318593024>
>
> --
> 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
> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALRxhAue66tgCPaG%3DKXF3QB54xHJ1%3Didho3b4TZbaa34K%2B0%3DoQ%40mail.gmail.com

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALRxhAue66tgCPaG%3DKXF3QB54xHJ1%3Didho3b4TZbaa34K%2B0%3DoQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
>
> --
> 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
> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_KY55Nna3%3DoFW3XD2wSF0%3Dk7ho5K7EsoRVVFkhzGEskog%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_KY55Nna3%3DoFW3XD2wSF0%3Dk7ho5K7EsoRVVFkhzGEskog%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Dimitri Glazkov]

I agree with folks here that the risks section needs to be reworked. 

Modulo that, LGTM1.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9f22b438-8724-32d3-5816-51d65661e407%40crisal.io.

[Xida Chen]

Hey all,

Thank you for your comments. I believe I have overlooked the risks. As the first movers to this feature, we understand that there is a risk associated with it.

I believe the interop risk is moderate given that: Firefox and other browsers have made significant inputs to the specification and currently there is no disagreement on it, so we believe that will reduce the interop risk when they do implement this feature.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOtFfx4bb%3DGjFQxgGhBPn0ze_xX2Xfb6z6L0KwKFiBSbqEOXcQ%40mail.gmail.com.

[Anne van Kesteren]

On Tue, Sep 12, 2017 at 7:15 PM, Xida Chen <xida...@chromium.org> wrote:
> I believe the interop risk is moderate given that: Firefox and other
> browsers have made significant inputs to the specification and currently
> there is no disagreement on it, so we believe that will reduce the interop
> risk when they do implement this feature.

FWIW, it does seem there's still quite a few issues with worklets that
have gone unaddressed for quite a while (not necessarily exhaustive):

https://github.com/whatwg/fetch/pull/527#pullrequestreview-60270088
https://github.com/w3c/css-houdini-drafts/pull/379#discussion_r134282891
https://github.com/w3c/css-houdini-drafts/issues/224
https://github.com/w3c/css-houdini-drafts/issues/237
https://github.com/w3c/css-houdini-drafts/issues/380

So there's definitely room for disagreement pending on how the above
are handled.


--
https://annevankesteren.nl/

[Boris Zbarsky]

On 9/11/17 9:58 AM, Emilio Cobos Álvarez wrote:
> Yeah, I guess the "Intent to experiment"[1] does count as a positive

> signal though :)...
> [1]:
> https://groups.google.com/forum/#!topic/mozilla.dev.platform/uI5bHZil2KU

I should note that the "Risks" section of that is very real, and I have
seen no evidence that the risks have been addressed.

As far as I can tell, the current state of this in Gecko is:

1) We're evaluating whether the idea makes sense at all, but the
evaluation has stalled because it got deprioritized relative to other
things.

2) We're not clear on whether it's a _good_ idea even if it does make
sense as something one could do.

That's just on the basic concept. I haven't been following the spec
situation enough to tell you whether there are problems on that end.

-Boris

[Rick Byers]

I'm excited to see this ship.  The design being discussed in great detail with the other major vendors in the Houdini group definitely reduces the interop risk.  There's still risk to going first with a powerful new primitive of course, but I think it's a risk worth taking in this case.

Will this be the first shipping use of worklets?  Or is shipping worklets covered by a separate intent?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c580d3a3-d9d2-1882-b974-33ac706c0837%40mit.edu.

[Ian Kilpatrick]

On Mon, Sep 18, 2017 at 5:03 PM, Rick Byers <rby...@google.com> wrote:

I'm excited to see this ship.  The design being discussed in great detail with the other major vendors in the Houdini group definitely reduces the interop risk.  There's still risk to going first with a powerful new primitive of course, but I think it's a risk worth taking in this case.

Will this be the first shipping use of worklets?  Or is shipping worklets covered by a separate intent?

I think that we can consider this as both the Intent-to-Ship for both CSS Paint API and Worklets. I don' t think that having a separate Intent-to-Ship makes sense as it wouldn't be developer visible. E.g. no worklets would be available by developers.

One thing that was pointed out specifically on:

https://github.com/w3c/css-houdini-drafts/pull/379#discussion_r134282891

...which annevk mentioned was the concerns around secure contexts.

The minutes from the last time the HoudiniTF discussed this is here:

https://lists.w3.org/Archives/Public/www-style/2017Mar/0023.html

This is a difficult decision for this API. On the one hand its a new capability, which we typically try to ship for secure contexts only to aid in secure context adoption.

On the other hand the discussion with the HoudiniTF brings up some issues, specifically:

 - No ability to detect having a secure context within CSS. E.g. a CSS framework using this feature can't detect if its within a secure context. 

 - This subsets the rendering engine with feature policy - which we haven't done before, e.g. css grid wasn't shipped only to secure contexts.

The discussion with the HoudiniTF (and TAG members who were in the room) didn't come to a concrete conclusion.

We can add [SecureContext] to the Worklet interface and CSS.paintWorklet attribute initially, and then relax, but would like to hear additional thoughts.

However the above would be strange as there would be a difference between:

.no-paint-api {

  background: /* fallback */;

  background: paint(foo);

}

.paint-api-on-non-secure-context {

  background: /* fallback */;

  background: paint(foo); /* valid - but nothing displayed */

}

.paint-api-on-secure-context {

  background: /* fallback */;

  background: paint(foo); /* valid - paint api displayed */

}

(The above is typically how a developer performs CSS fallback.)

[Robert Flack]

I agree with not wanting to restrict this to secure contexts. I'm concerned about the framework or multi-environment use cases. Frameworks would never be able to remove fallback logic which would cause friction with adoption as the fallback for paint may be non trivial / hacky (have to create complex combinations of divs). As Ian already mentioned we can of course restrict this to start and continue discussions on this point without risk.

I think changes in generic Worklets should not have a developer visible effect on paintWorklet as the CSS Paint API should only allow for relatively simple use cases with well defined communication / execution and is intentionally flexible about specific execution context details.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJL3UpR68bc8E8zqETudryw-gDo4i2S1Y0MycUOsyNnU%3D4mnEQ%40mail.gmail.com.

[Mike West]

Thanks for calling this out, Ian!

On Tue, Sep 19, 2017 at 9:56 AM, Ian Kilpatrick <ikilp...@chromium.org> wrote:

One thing that was pointed out specifically on:

https://github.com/w3c/css-houdini-drafts/pull/379#discussion_r134282891

...which annevk mentioned was the concerns around secure contexts.

The minutes from the last time the HoudiniTF discussed this is here:

https://lists.w3.org/Archives/Public/www-style/2017Mar/0023.html

This is a difficult decision for this API. On the one hand its a new capability, which we typically try to ship for secure contexts only to aid in secure context adoption.

On the other hand the discussion with the HoudiniTF brings up some issues, specifically:

 - No ability to detect having a secure context within CSS. E.g. a CSS framework using this feature can't detect if its within a secure context. 

This seems like an argument for feature detection inside CSS rather than rejection of a constraint that would require feature detection. It seems that you'll need feature detection one way or the other, since the behavior specified by the `paint(...)` CSS value depends on support from the JavaScript side, right?

 

 - This subsets the rendering engine with feature policy - which we haven't done before, e.g. css grid wasn't shipped only to secure contexts.

I'd suggest that we need to start somewhere. The fact that this feature bridges across CSS (where we apparently don't have good feature-detection mechanisms) and JavaScript (where we do) makes it a pretty reasonable starting point, in my opinion.

The discussion with the HoudiniTF (and TAG members who were in the room) didn't come to a concrete conclusion.

We can add [SecureContext] to the Worklet interface and CSS.paintWorklet attribute initially, and then relax, but would like to hear additional thoughts.

However the above would be strange as there would be a difference between:

.no-paint-api {

  background: /* fallback */;

  background: paint(foo);

}

.paint-api-on-non-secure-context {

  background: /* fallback */;

  background: paint(foo); /* valid - but nothing displayed */

}

Why would this be valid? It would seem to make sense to treat this as `.no-paint-api` above which falls back to the workable definition. This is the approach we've taken in IDL by specifying `[SecureContext]` on a given interface/attribute/method, which removes it from the global object entirely if it's not a secure context.

 

.paint-api-on-secure-context {

  background: /* fallback */;

  background: paint(foo); /* valid - paint api displayed */

}

(The above is typically how a developer performs CSS fallback.)

On Thursday, September 14, 2017, Boris Zbarsky <bzba...@mit.edu> wrote:

On 9/11/17 9:58 AM, Emilio Cobos Álvarez wrote:

Yeah, I guess the "Intent to experiment"[1] does count as a positive
signal though :)...
[1]:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/uI5bHZil2KU

I should note that the "Risks" section of that is very real, and I have seen no evidence that the risks have been addressed.

As far as I can tell, the current state of this in Gecko is:

1) We're evaluating whether the idea makes sense at all, but the evaluation has stalled because it got deprioritized relative to other things.

2) We're not clear on whether it's a _good_ idea even if it does make sense as something one could do.

That's just on the basic concept.  I haven't been following the spec situation enough to tell you whether there are problems on that end.

-Boris

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c580d3a3-d9d2-1882-b974-33ac706c0837%40mit.edu.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJL3UpR68bc8E8zqETudryw-gDo4i2S1Y0MycUOsyNnU%3D4mnEQ%40mail.gmail.com.

[Jeremy Roman]

On Tue, Sep 19, 2017 at 5:53 PM, Mike West <mk...@chromium.org> wrote:

Thanks for calling this out, Ian!

On Tue, Sep 19, 2017 at 9:56 AM, Ian Kilpatrick <ikilp...@chromium.org> wrote:

One thing that was pointed out specifically on:

https://github.com/w3c/css-houdini-drafts/pull/379#discussion_r134282891

...which annevk mentioned was the concerns around secure contexts.

The minutes from the last time the HoudiniTF discussed this is here:

https://lists.w3.org/Archives/Public/www-style/2017Mar/0023.html

This is a difficult decision for this API. On the one hand its a new capability, which we typically try to ship for secure contexts only to aid in secure context adoption.

On the other hand the discussion with the HoudiniTF brings up some issues, specifically:

 - No ability to detect having a secure context within CSS. E.g. a CSS framework using this feature can't detect if its within a secure context. 

This seems like an argument for feature detection inside CSS rather than rejection of a constraint that would require feature detection. It seems that you'll need feature detection one way or the other, since the behavior specified by the `paint(...)` CSS value depends on support from the JavaScript side, right?

 

 - This subsets the rendering engine with feature policy - which we haven't done before, e.g. css grid wasn't shipped only to secure contexts.

I'd suggest that we need to start somewhere. The fact that this feature bridges across CSS (where we apparently don't have good feature-detection mechanisms) and JavaScript (where we do) makes it a pretty reasonable starting point, in my opinion.

(CSS non-expert question, sorry)

Can CSS @supports be used to detect this?

@supports (background: paint(foo)) { /* ... */ }

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DcimBE%2BC0d8-L2FC3y05XJC1uo6RfyFLR2g3t54gxpZ2w%40mail.gmail.com.

[Boris Zbarsky]

On 9/19/17 4:25 AM, Robert Flack wrote:
> I think changes in generic Worklets should not have a developer visible
> effect on paintWorklet as the CSS Paint API should only allow for
> relatively simple use cases with well defined communication / execution
> and is intentionally flexible about specific execution context details.

This last is actually a pretty serious compat concern, by the way.

What the spec defines is that a UA must have at least two paint worklets
and assign work to them somehow. The spec does not require randomness
of ordering of work assignment, randomness in which worklet is chosen,
or anything else.

This unfortunately makes it fairly easy to create worklets that depend
on specific assignment algorithms, and I expect pages to end up doing
just that if browsers do anything deterministic here. At which point
we'll end up having to specify those deterministic algorithms, and
whatever their limitations are (e.g. only two paint worklets, period).

I know this issue has been brought up before, and I know it's a hard
problem to solve. I'd just like to point out that it wasn't even
mentioned in the "interoperability risks" of this intent.

Sorry to keep harping on this, but I think the risks here are being
seriously misrepresented.

-Boris

[Ian Kilpatrick]

Thanks for pointing this out. We agree that this is a interop risk. You are correct that we should have pointed this out in the initial intent. We've tried to mitigate this by switching between two PaintWorkletGlobalScopes in our implementation.

We discussed this in person with the Servo folks at the last Houdini F2F. We discussed our plans for switching between the two paint worklet global scopes.

[Ashley Gullen]

Is OffscreenCanvas allowed to be posted to a paint worklet? I'm interested in using paint worklets as an alternative to the CSS element()-with-canvas approach. There seems to be some overlap between use cases here; is one going to be deprecated in favour of the other? The paint worklet approach sounds more flexible with element sizing, inputs and performance characteristics, but is it an explicit goal of the CSS paint API to supersede element()? Additionally given that there are some interesting interactions with OffscreenCanvas, which itself appears to still be in development, should that be considered as potentially increasing the interop risk?

Ashley

--
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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c580d3a3-d9d2-1882-b974-33ac706c0837%40mit.edu.

[Robert Flack]

No, you can't post messages to a paint worklet. The only information you get on the paint worklet is the styleMap with the css properties you have registered as inputs and the geometry. We may in the future instantiate and run paint worklets on a dedicated thread which could get similar performance benefits to drawing to an offscreen canvas on a worker but this is not controllable or observable by the developer short of noticing performance isolation.

For this reason, I believe PaintWorklet does not satisfy many of the use cases for OffscreenCanvas where you want to coordinate and communicate with the main thread, maintain state, and probably handle input events.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABs73hn9Emnw1bbkgmSMPNZrtBcY18z_WSZ3bDvLVHtdfk-rw%40mail.gmail.com.

[Ashley Gullen]

Our use case is dynamically generating a spritesheet of icons, which are drawn to a 2D canvas. Then we want to show sprites from that as a CSS background image. Currently we have to call toBlob() on the canvas and create a blob URL to the resulting image. It would be nice if we could directly use the canvas as a background image. OffscreenCanvas can't do this by itself. Paint worklets seem well-suited to this providing you can get the OffscreenCanvas to the paint worklet for a drawImage() call. Maybe this could be considered in future. As far as I can see, it would allow the canvas cases for CSS element() to be superseded by paint worklets.

[Jochen Eisinger]

On Tue, Sep 19, 2017 at 6:05 PM Jeremy Roman <jbr...@chromium.org> wrote:

On Tue, Sep 19, 2017 at 5:53 PM, Mike West <mk...@chromium.org> wrote:

Thanks for calling this out, Ian!

On Tue, Sep 19, 2017 at 9:56 AM, Ian Kilpatrick <ikilp...@chromium.org> wrote:

One thing that was pointed out specifically on:

https://github.com/w3c/css-houdini-drafts/pull/379#discussion_r134282891

...which annevk mentioned was the concerns around secure contexts.

The minutes from the last time the HoudiniTF discussed this is here:

https://lists.w3.org/Archives/Public/www-style/2017Mar/0023.html

This is a difficult decision for this API. On the one hand its a new capability, which we typically try to ship for secure contexts only to aid in secure context adoption.

On the other hand the discussion with the HoudiniTF brings up some issues, specifically:

 - No ability to detect having a secure context within CSS. E.g. a CSS framework using this feature can't detect if its within a secure context. 

This seems like an argument for feature detection inside CSS rather than rejection of a constraint that would require feature detection. It seems that you'll need feature detection one way or the other, since the behavior specified by the `paint(...)` CSS value depends on support from the JavaScript side, right?

 

 - This subsets the rendering engine with feature policy - which we haven't done before, e.g. css grid wasn't shipped only to secure contexts.

I'd suggest that we need to start somewhere. The fact that this feature bridges across CSS (where we apparently don't have good feature-detection mechanisms) and JavaScript (where we do) makes it a pretty reasonable starting point, in my opinion.

(CSS non-expert question, sorry)

Can CSS @supports be used to detect this?

@supports (background: paint(foo)) { /* ... */ }

 

The discussion with the HoudiniTF (and TAG members who were in the room) didn't come to a concrete conclusion.

We can add [SecureContext] to the Worklet interface and CSS.paintWorklet attribute initially, and then relax, but would like to hear additional thoughts.

I don't think that fragmentation is a valid argument. We already have the web fragmented in secure and insecure, and we should just stop adding stuff to the insecure fragment.

This is not about pushing something forward via unrelated features, it is just that the modern web only exists on secure contexts.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuR13eLrmYas2hpTtu%3D4vSKSFGdHw7m14uBtUtY9H%3D%3D2bEjJg%40mail.gmail.com.

[Rick Byers]

Please let's not let this intent degrade into another "all new features should require HTTPS" debate.  I've started a separate thread for that debate here, please chime in there if you're interested and we'll circle back here with a pointer to the updated policy if there is one.

For the interop risk of the worklet assignment that Boris is concerned about.  Ian, our implementation just cycles back and forth, right? Is there any reason we couldn't explicitly make the choice (or decision to switch) randomly? Obviously we couldn't reliably test this and so perhaps wouldn't have more than a note in the spec encouraging non-determinism.

But more broadly I don't think we've really discussed the larger question of interop risk for worklets.  I assume the WPT tests in css-paint are explicitly testing only the things defined by the custom paint spec. Should we also be writing some web-platform-tests for things defined in the worklets spec which are observable via paint worklets?

[Dimitri Glazkov]

Is there a spec bug where we could continue discussion on the determinism (or explicit lack thereof) of the worklet-picking algorithm? I scanned the https://github.com/w3c/css-houdini-drafts/issues/ but didn't see it right away.

:DG< 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8cv6kZeX2%2BTt1ei7q-RUQWHKkZvjL-9BqsYDKmh%2BBiUg%40mail.gmail.com.

[Xida Chen]

I re-opened this bug.

The current global scope switching logic was implemented in this CL. Basically we switch to another global scope every 120 frames. We were trying to avoid the overhead of switching too often.

[Anne van Kesteren]

I'm somewhat surprised I didn't get a reply thus far and everything
seems to be going ahead. Isn't figuring out which service worker to
use for worklet fetches considered important for interoperability?


--
https://annevankesteren.nl/

[Dimitri Glazkov]

+Ian Kilpatrick since he's the one driving the spec bits here.

:DG<

[Ian Kilpatrick]

The current specification text on the selection algorithm was purposefully left open to allow implementations like servo select scopes in a way to parallelize between threads. We won't be able to specify an algorithm on how to select a global scope.

I think Rick is right that we can only add a note to the paint spec that this should be picked non-deterministically.

I've created a pull request (https://github.com/w3c/css-houdini-drafts/pull/472) which adds this note the spec.

flackr, xidachen and I talked quickly the other day, we are going to implement a scheme which will:

 - Start each frame by randomly selecting a global scope.

 - After a random number of invocations within that frame, switch to the other global scope.

We think that this will have a reasonable tradeoff between performance and adding more non-determinism into the system.

+nhiroki Is there anything blocking us from upstreaming our worklet tests to WPT now? (We have crbug.com/724907 tracking this).

[Ian Kilpatrick]

Responses inline.

On Sun, Sep 24, 2017 at 8:21 PM, Anne van Kesteren <ann...@annevk.nl> wrote:

On Thu, Sep 14, 2017 at 2:21 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
> On Tue, Sep 12, 2017 at 7:15 PM, Xida Chen <xida...@chromium.org> wrote:
>> I believe the interop risk is moderate given that: Firefox and other
>> browsers have made significant inputs to the specification and currently
>> there is no disagreement on it, so we believe that will reduce the interop
>> risk when they do implement this feature.
>
> FWIW, it does seem there's still quite a few issues with worklets that
> have gone unaddressed for quite a while (not necessarily exhaustive):
>
>   https://github.com/whatwg/fetch/pull/527#pullrequestreview-60270088

That was an oversight on my behalf. I thought that this required additional feedback from @jakearchibald @jungkees.

I've updated the pull request such that worklets will reuse the document's serviceworker.

 

>   https://github.com/w3c/css-houdini-drafts/pull/379#discussion_r134282891

 Being discussed for Blink in https://groups.google.com/a/chromium.org/forum/#!msg/blink-api-owners-discuss/Gmxej1Ryj8c/djiqh8kMAAAJ

>   https://github.com/w3c/css-houdini-drafts/issues/224

 I accidentally left this open I think, there is now a concept of an owner document for each worklet global scope, the global scope is destroyed when the document goes away.

+nhiroki, is there a WPT that we can add for this?

  

>   https://github.com/w3c/css-houdini-drafts/issues/237

This was discussed at the last F2F, and I believe there is just editorial changes that need to be made to the spec. 

+tab will be able to shed more light.

>   https://github.com/w3c/css-houdini-drafts/issues/380

This won't have any risk for paint worklet as I understand it, as paint worklet doesn't have any way to invoke the structured clone machinery. 

>
> So there's definitely room for disagreement pending on how the above
> are handled.

I'm somewhat surprised I didn't get a reply thus far and everything
seems to be going ahead. Isn't figuring out which service worker to
use for worklet fetches considered important for interoperability?

--
https://annevankesteren.nl/

--
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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78iLhDh02CHp%3DgYDuLi3Tw8A%3DCTbxLeCzFD3z5OruhW6%2Bg%40mail.gmail.com.

[Jochen Eisinger]

On Mon, Sep 25, 2017 at 8:01 AM 'Ian Kilpatrick' via blink-dev <blin...@chromium.org> wrote:

Responses inline.

On Sun, Sep 24, 2017 at 8:21 PM, Anne van Kesteren <ann...@annevk.nl> wrote:

On Thu, Sep 14, 2017 at 2:21 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
> On Tue, Sep 12, 2017 at 7:15 PM, Xida Chen <xida...@chromium.org> wrote:
>> I believe the interop risk is moderate given that: Firefox and other
>> browsers have made significant inputs to the specification and currently
>> there is no disagreement on it, so we believe that will reduce the interop
>> risk when they do implement this feature.
>
> FWIW, it does seem there's still quite a few issues with worklets that
> have gone unaddressed for quite a while (not necessarily exhaustive):
>
>   https://github.com/whatwg/fetch/pull/527#pullrequestreview-60270088

That was an oversight on my behalf. I thought that this required additional feedback from @jakearchibald @jungkees.

I've updated the pull request such that worklets will reuse the document's serviceworker.

 

>   https://github.com/w3c/css-houdini-drafts/pull/379#discussion_r134282891

 Being discussed for Blink in https://groups.google.com/a/chromium.org/forum/#!msg/blink-api-owners-discuss/Gmxej1Ryj8c/djiqh8kMAAAJ

That's not quite correct. The linked thread is about the question whether all new APIs should be secure only by default.

It's true that if we require this for all new APIs, we'll also require it for the Paint API. However, the reverse is not true, so there's merit in continueing the Paint API specific discussion here.

 

>   https://github.com/w3c/css-houdini-drafts/issues/224

 I accidentally left this open I think, there is now a concept of an owner document for each worklet global scope, the global scope is destroyed when the document goes away.

+nhiroki, is there a WPT that we can add for this?

  

>   https://github.com/w3c/css-houdini-drafts/issues/237

This was discussed at the last F2F, and I believe there is just editorial changes that need to be made to the spec. 

+tab will be able to shed more light.

>   https://github.com/w3c/css-houdini-drafts/issues/380

This won't have any risk for paint worklet as I understand it, as paint worklet doesn't have any way to invoke the structured clone machinery. 

>
> So there's definitely room for disagreement pending on how the above
> are handled.

I'm somewhat surprised I didn't get a reply thus far and everything
seems to be going ahead. Isn't figuring out which service worker to
use for worklet fetches considered important for interoperability?

--
https://annevankesteren.nl/

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78iLhDh02CHp%3DgYDuLi3Tw8A%3DCTbxLeCzFD3z5OruhW6%2Bg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJL3UpRmozW%3DTpDLiHtSP0v9Pyd04aE4uSzjr20%3D5xVnWf_jYg%40mail.gmail.com.

[Anne van Kesteren]

Thanks Ian! Couple responses inline.

On Mon, Sep 25, 2017 at 8:01 AM, Ian Kilpatrick <ikilp...@google.com> wrote:
> On Sun, Sep 24, 2017 at 8:21 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
>> On Thu, Sep 14, 2017 at 2:21 PM, Anne van Kesteren <ann...@annevk.nl>
>> wrote:
>>> https://github.com/whatwg/fetch/pull/527#pullrequestreview-60270088
>
> That was an oversight on my behalf. I thought that this required additional
> feedback from @jakearchibald @jungkees.
> I've updated the pull request such that worklets will reuse the document's
> serviceworker.

I do think it would be good if either one of them signed off, but I
suspect this resolution is satisfactory. Even if it's waiting on them
though, the onus is on you to make sure it gets resolved.

>>> https://github.com/w3c/css-houdini-drafts/pull/379#discussion_r134282891
>
> Being discussed for Blink in
> https://groups.google.com/a/chromium.org/forum/#!msg/blink-api-owners-discuss/Gmxej1Ryj8c/djiqh8kMAAAJ

I think there's a fair chance Mozilla would object to not requiring
secure contexts.

>>> https://github.com/w3c/css-houdini-drafts/issues/237
>
> This was discussed at the last F2F, and I believe there is just editorial
> changes that need to be made to the spec.

Changing [Exposed] is not exactly editorial.


--
https://annevankesteren.nl/

[Philip Jägenstedt]

Xida, Ian, this is starting to be a long thread, can you summarize what the outstanding issues are, and what they are blocked on?

Given the complexity of implementation, I think it is even more important than usual to get a good idea about the intentions of other browser vendors. Have you just been unable to get public signals for Edge and Safari, or are there no signals at all? We could escalate to make sure that this hasn't gone under the radar for them, if that's at all plausible.

The amount of tests in http://wpt.fyi/css-paint-api is great and should be a help for a second implementer. Is there an issue tracking making those tests all fail when the API isn't implemented?

I left a comment on https://github.com/w3c/css-houdini-drafts/pull/472 about testing the non-deterministic bits.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78isA%3DTjqBpY_%3DohZtpLmqD3Mp8bMA5i647RwPD3RyLbJg%40mail.gmail.com.

[Ian Kilpatrick]

Responses inline.

On Mon, Sep 25, 2017 at 9:46 PM, Philip Jägenstedt <foo...@google.com> wrote:

Xida, Ian, this is starting to be a long thread, can you summarize what the outstanding issues are, and what they are blocked on?

The [SecureContext] discussion is something that we need consensus on, at least within Blink.

Blocked-on: For this I'd be good for the blink-api-owners to continue drive the discussion such that we can reach an consensus for the paint api.

There was the is concern about the non-determinism for the selection of the PWGS.

We are going to implement a scheme to try and address these concerns which will:

 - Start each frame by randomly selecting a global scope.

 - After a random number of invocations within that frame, switch to the other global scope.

Blocked-on: Implementation - we will cycle back to this thread once we've implemented this, and we can also block on adding the note to the spec about this.

There are few loose ends which we need to look at/fix for worklets before shipping:

 - Decide and implement which service-worker PWGS requests should go to.

 - We also need to check if our CSP implementation matches the CSP spec where there is an outstanding PR.

Blocked-on: Deciding where requests go for serivce-worker. The worker team is looking at the above issues, and we'll cycle back once we've fixed/checked our implementation.

There is also what is exposed to PWGS, but I don't believe that there is any disagreement to what is going to be exposed, and this just needs a spec change.

Xida is also currently fixing some implementation bugs related to how we handle browser zoom, these are bugs in our implementation and not the spec.

It would be good to continue the discussion and get consencus about SecureContext in parallel with the above work.

Given the complexity of implementation, I think it is even more important than usual to get a good idea about the intentions of other browser vendors. Have you just been unable to get public signals for Edge and Safari, or are there no signals at all? We could escalate to make sure that this hasn't gone under the radar for them, if that's at all plausible.

Unable to get public signals for Edge and Safari, neither implementor has committed to implementing and shipping these APIs, however we've tried to address any concerns that have been raised by them in meetings.

I don't believe that this has gone under the radar for them, last F2F meeting we said that we were planning to ship soon.

 

The amount of tests in http://wpt.fyi/css-paint-api is great and should be a help for a second implementer. Is there an issue tracking making those tests all fail when the API isn't implemented?

I just filed: crbug.com/768683

 

I left a comment on https://github.com/w3c/css-houdini-drafts/pull/472 about testing the non-deterministic bits.

Thanks.

[Hiroki Nakagawa]

2017-09-25 14:42 GMT+09:00 Ian Kilpatrick <ikilp...@chromium.org>:

+nhiroki Is there anything blocking us from upstreaming our worklet tests to WPT now? (We have crbug.com/724907 tracking this).

The blocker was already fixed and the CL to upstream the tests is now under review. 

[Hiroki Nakagawa]

2017-09-25 15:01 GMT+09:00 'Ian Kilpatrick' via blink-dev <blin...@chromium.org>:

>   https://github.com/w3c/css-houdini-drafts/issues/224

 I accidentally left this open I think, there is now a concept of an owner document for each worklet global scope, the global scope is destroyed when the document goes away.

+nhiroki, is there a WPT that we can add for this?

Our code is implemented in this way but we don't have layout / WPT tests for now because there is no standarized way to confirm whether the worklet global scope is destroyed after the owner document is gone.

[Philip Jägenstedt]

On Tue, Sep 26, 2017 at 5:01 AM Ian Kilpatrick <ikilp...@chromium.org> wrote:

Responses inline.

On Mon, Sep 25, 2017 at 9:46 PM, Philip Jägenstedt <foo...@google.com> wrote:

Xida, Ian, this is starting to be a long thread, can you summarize what the outstanding issues are, and what they are blocked on?

The [SecureContext] discussion is something that we need consensus on, at least within Blink.

Blocked-on: For this I'd be good for the blink-api-owners to continue drive the discussion such that we can reach an consensus for the paint api.

Ian, is there any concrete proposal for secure context feature detection in CSS that we could tie this to? Something like @secure { ... }?

For me, I think it'd be fine to have as a general rule that new CSS features will exist in all contexts, because it's easier to make it so, and because it doesn't change what pixels can end up in front of a user, only the ease of doing it.

Jochen, Mike, what information do you think we need to make a decision on this? Does the use of worklets change the picture?

 

Given the complexity of implementation, I think it is even more important than usual to get a good idea about the intentions of other browser vendors. Have you just been unable to get public signals for Edge and Safari, or are there no signals at all? We could escalate to make sure that this hasn't gone under the radar for them, if that's at all plausible.

Unable to get public signals for Edge and Safari, neither implementor has committed to implementing and shipping these APIs, however we've tried to address any concerns that have been raised by them in meetings.

I don't believe that this has gone under the radar for them, last F2F meeting we said that we were planning to ship soon.

Thanks, that will have to do, if they thought it was a terrible idea we would hopefully have heard.

[Jochen Eisinger]

On Wed, Sep 27, 2017 at 2:50 PM 'Philip Jägenstedt' via blink-dev <blin...@chromium.org> wrote:

On Tue, Sep 26, 2017 at 5:01 AM Ian Kilpatrick <ikilp...@chromium.org> wrote:

Responses inline.

On Mon, Sep 25, 2017 at 9:46 PM, Philip Jägenstedt <foo...@google.com> wrote:

Xida, Ian, this is starting to be a long thread, can you summarize what the outstanding issues are, and what they are blocked on?

The [SecureContext] discussion is something that we need consensus on, at least within Blink.

Blocked-on: For this I'd be good for the blink-api-owners to continue drive the discussion such that we can reach an consensus for the paint api.

Ian, is there any concrete proposal for secure context feature detection in CSS that we could tie this to? Something like @secure { ... }?

For me, I think it'd be fine to have as a general rule that new CSS features will exist in all contexts, because it's easier to make it so, and because it doesn't change what pixels can end up in front of a user, only the ease of doing it.

Jochen, Mike, what information do you think we need to make a decision on this? Does the use of worklets change the picture?

In the end, we'll need some way to feature-detect the presence of the paint API in CSS - otherwise, sites would have to fallback to UA sniffing, no?

 

 

Given the complexity of implementation, I think it is even more important than usual to get a good idea about the intentions of other browser vendors. Have you just been unable to get public signals for Edge and Safari, or are there no signals at all? We could escalate to make sure that this hasn't gone under the radar for them, if that's at all plausible.

Unable to get public signals for Edge and Safari, neither implementor has committed to implementing and shipping these APIs, however we've tried to address any concerns that have been raised by them in meetings.

I don't believe that this has gone under the radar for them, last F2F meeting we said that we were planning to ship soon.

Thanks, that will have to do, if they thought it was a terrible idea we would hopefully have heard.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfiD5mP%2B6Ta7Vbs6NmLWTGZUhstm92r8tPufMD7pDRCCw%40mail.gmail.com.

[Philip Jägenstedt]

On Wed, Sep 27, 2017 at 2:52 PM Jochen Eisinger <joc...@chromium.org> wrote:

On Wed, Sep 27, 2017 at 2:50 PM 'Philip Jägenstedt' via blink-dev <blin...@chromium.org> wrote:

On Tue, Sep 26, 2017 at 5:01 AM Ian Kilpatrick <ikilp...@chromium.org> wrote:

Responses inline.

On Mon, Sep 25, 2017 at 9:46 PM, Philip Jägenstedt <foo...@google.com> wrote:

Xida, Ian, this is starting to be a long thread, can you summarize what the outstanding issues are, and what they are blocked on?

The [SecureContext] discussion is something that we need consensus on, at least within Blink.

Blocked-on: For this I'd be good for the blink-api-owners to continue drive the discussion such that we can reach an consensus for the paint api.

Ian, is there any concrete proposal for secure context feature detection in CSS that we could tie this to? Something like @secure { ... }?

For me, I think it'd be fine to have as a general rule that new CSS features will exist in all contexts, because it's easier to make it so, and because it doesn't change what pixels can end up in front of a user, only the ease of doing it.

Jochen, Mike, what information do you think we need to make a decision on this? Does the use of worklets change the picture?

In the end, we'll need some way to feature-detect the presence of the paint API in CSS - otherwise, sites would have to fallback to UA sniffing, no?

Maybe? Ian, Xida, what was the thinking on this before the question of secure contexts came up? 

[PhistucK]

We do you think a new at-rule (@secure {}) is needed? Why is @supports not enough?

@supports (background: paint(foo)) {}

☆PhistucK

--

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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdP4TXpG4ZP3OniRFbm8rwcEFxie_pdTYVqNagB5eW51w%40mail.gmail.com.

[Philip Jägenstedt]

On Wed, Sep 27, 2017 at 6:39 PM PhistucK <phis...@gmail.com> wrote:

We do you think a new at-rule (@secure {}) is needed? Why is @supports not enough?

@supports (background: paint(foo)) {}

Huh, that makes sense :) Ian, Xida, could it be that simple?

[Robert Flack]

I think we could support this and standard CSS fallback by checking whether we're in a secure context before parsing the paint property here:

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/parser/CSSPropertyParserHelpers.cpp?dr=CSs&l=1436

However, this would be the first CSS property value to parse only in secure contexts. I'm guessing this would be fine, since quirks mode also affects parsing but it's worthy of consideration.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfsoHjYRCeHHF0A5ZiQGQdtyg3Lhmv3Bta7j7%3D8qGkacQ%40mail.gmail.com.

[Philip Jägenstedt]

So, I think that the deciding factor here is whether we should attempt to limit all worklets to secure contexts. Then this CSS property value would be limited to secure contexts as a side effect, not because we're going to limit all future CSS properties/values to secure contexts. Jochen, WDYT?

[Ian Kilpatrick]

On Wed, Sep 27, 2017 at 10:21 AM, Robert Flack <fla...@chromium.org> wrote:

I think we could support this and standard CSS fallback by checking whether we're in a secure context before parsing the paint property here:

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/parser/CSSPropertyParserHelpers.cpp?dr=CSs&l=1436

However, this would be the first CSS property value to parse only in secure contexts. I'm guessing this would be fine, since quirks mode also affects parsing but it's worthy of consideration.

Right - so if we had just relied on the [SecureContext] infrastructure, then we'd be in the weird state that we wouldn't have different parsing behaviour. Failing at parse time is better and correct, but we start to create a separate "mode" for the web like quirks mode. 

 

On Wed, Sep 27, 2017 at 12:43 PM, 'Philip Jägenstedt' via blink-dev <blin...@chromium.org> wrote:

On Wed, Sep 27, 2017 at 6:39 PM PhistucK <phis...@gmail.com> wrote:

We do you think a new at-rule (@secure {}) is needed? Why is @supports not enough?

@supports (background: paint(foo)) {}

Huh, that makes sense :) Ian, Xida, could it be that simple?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfsoHjYRCeHHF0A5ZiQGQdtyg3Lhmv3Bta7j7%3D8qGkacQ%40mail.gmail.com.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TPZR8fAuxuAwAuWbb%3DE%3D3H-o4Kd%2Bcayb9XCtMcsCDz4aQ%40mail.gmail.com.

[Ian Kilpatrick]

On Wed, Sep 27, 2017 at 10:28 AM, Philip Jägenstedt <foo...@google.com> wrote:

So, I think that the deciding factor here is whether we should attempt to limit all worklets to secure contexts. Then this CSS property value would be limited to secure contexts as a side effect, not because we're going to limit all future CSS properties/values to secure contexts. Jochen, WDYT?

So its little difficult phrasing it this way - as its not how developers would think about this feature. (Part of why this is so hard is that worklets by themselves don't add any usable web api, only apis which use them do). Without worklets in the API it becomes similar to limiting grid, or conic-gradient to secure contexts. 

As a mental experiment, would we make the CSS Paint API secure context only - if it used the standard worker infrastructure instead?  

[Jochen Eisinger]

On Wed, Sep 27, 2017 at 10:11 PM Ian Kilpatrick <ikilp...@chromium.org> wrote:

On Wed, Sep 27, 2017 at 10:28 AM, Philip Jägenstedt <foo...@google.com> wrote:

So, I think that the deciding factor here is whether we should attempt to limit all worklets to secure contexts. Then this CSS property value would be limited to secure contexts as a side effect, not because we're going to limit all future CSS properties/values to secure contexts. Jochen, WDYT?

So its little difficult phrasing it this way - as its not how developers would think about this feature. (Part of why this is so hard is that worklets by themselves don't add any usable web api, only apis which use them do). Without worklets in the API it becomes similar to limiting grid, or conic-gradient to secure contexts. 

I'm not sure I follow. Websites will have to do this anyways in order to not break if the site runs in an older version of chrome / different web browser that doesn't yet implement this.

 

As a mental experiment, would we make the CSS Paint API secure context only - if it used the standard worker infrastructure instead?  

I would :) 

[Anne van Kesteren]

On Wed, Sep 27, 2017 at 10:00 PM, 'Ian Kilpatrick' via blink-dev
<blin...@chromium.org> wrote:
> Right - so if we had just relied on the [SecureContext] infrastructure, then
> we'd be in the weird state that we wouldn't have different parsing
> behaviour. Failing at parse time is better and correct, but we start to
> create a separate "mode" for the web like quirks mode.

That is very much what secure contexts are about (though fortunately
with a bit more solid rationale than quirks mode). Note also that the
APIs are not exposed, so it would make sense that CSS features are not
either.


--
https://annevankesteren.nl/

[Ian Kilpatrick]

I guess I somewhat worry about this as I've seen web developers get stuck with modes like this. [SecureContext] is great on the JS level as it fails fast, and can easily be explained.

On the other hand with CSS I've spent 2+ hours debugging a what ended up being a quirks mode + html parser issue with a google team.

They had spent 2-3 engineers debugging this issue for a week until they reached out to the chrome team to fix this release blocker.

Adding deep switches in the stack with non-obvious side-effects without fast-fails is part of my worry. 

--
https://annevankesteren.nl/

[PhistucK]

That can be alleviated by emitting a console warning whenever secure context prevents a CSS feature from working, right?

(If the same is possible with JavaScript based features, that could be nice as well, but I suspect it has significant performance overhead because those features are simply not in the context at all, while the CSS parsing/resolution situation is probably extremely different and perhaps more welcoming to such notions)

Is that feasible?

☆PhistucK

[Robert Flack]

Logging a warning for legitimate CSS feature detection also seems like it wouldn't be ideal.

[PhistucK]

Perhaps an information rather than a warning and only for secure-context-required features and only once per feature per page load.

Or a debug message, or using the same level as violations, whichever it is.

Perhaps the Developer Tools can show some sort of an information bar whenever you debug HTTP pages that try to use those CSS features, "this page tried to detect a CSS feature that is only enabled in secure contexts, click here for details" which would reveal the appropriate logging levels for showing the actual feature-detected/unconditionally-used features.

There are ways to be smart about it, perhaps logging a warning is not great, but something can be done to help in those situations rather than not requiring secure contexts for those features.

☆PhistucK

[Anne van Kesteren]

On Thu, Sep 28, 2017 at 5:12 PM, Ian Kilpatrick <ikilp...@google.com> wrote:
> I guess I somewhat worry about this as I've seen web developers get stuck
> with modes like this. [SecureContext] is great on the JS level as it fails
> fast, and can easily be explained.
>
> On the other hand with CSS I've spent 2+ hours debugging a what ended up
> being a quirks mode + html parser issue with a google team.
> They had spent 2-3 engineers debugging this issue for a week until they
> reached out to the chrome team to fix this release blocker.
>
> Adding deep switches in the stack with non-obvious side-effects without
> fast-fails is part of my worry.

It might make sense to make it clear in the developer tools somehow
you're in quirks mode or limited-quirks mode. Failing to use secure
contexts will become ever more clear and is already user visible.
There is going to be some transition pain, but the more features adopt
the way of the future, the less debugging pain there will be. Quirks
mode is fairly limited in what it affects and is therefore easy to
overlook. Without secure contexts there's dozens and soon hundreds of
features that'll end up failing.


--
https://annevankesteren.nl/

[Ian Kilpatrick]

Right if its a lot - then you're right, this is much less of a concern. I don't see the wider browser community there yet however. E.g. we shipped ES6 modules without this discussion, should the upcoming javascript module import() be shipped in secure contexts only?

(I still think that there are other valid reasons discussed in api owners thread).

--
https://annevankesteren.nl/

[Anne van Kesteren]

On Thu, Sep 28, 2017 at 8:33 PM, 'Ian Kilpatrick' via blink-dev
<blin...@chromium.org> wrote:
> Right if its a lot - then you're right, this is much less of a concern. I
> don't see the wider browser community there yet however. E.g. we shipped ES6
> modules without this discussion, should the upcoming javascript module
> import() be shipped in secure contexts only?

I'd like that. We really need to get to the point where you need to
have strong justification to not do it.

> (I still think that there are other valid reasons discussed in api owners
> thread).

I think if we commit to doing it quite a few of those reasons will end
up disappearing due to ripple effects. And if we really turn out to be
wrong somehow it's easy enough to remove the restriction. Adding the
restriction after-the-fact is much harder.


--
https://annevankesteren.nl/

[Chris Harrelson]

The API owners met today to discuss this intent, and also the issue of requiring secure contexts. We decided the following:

1. Ship CSS Paint in secure contexts only, and also block future types of worklets (e.g. audio worklet) on secure contexts.

2. Don't change policy regarding secure contexts for other features at this time.

Other than that, I think this intent LGTM1. There are a couple of last-minute details I've brought up on other threads, but will work on them in parallel with this.

--
https://annevankesteren.nl/

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78geuRc9XPS4uECS8RkAKwaLxz-WNssQPssT8YKHiuh20A%40mail.gmail.com.

[Philip Jägenstedt]

LGTM2

On Thu, Oct 26, 2017 at 8:10 PM Chris Harrelson <chri...@chromium.org> wrote:

The API owners met today to discuss this intent, and also the issue of requiring secure contexts. We decided the following:

1. Ship CSS Paint in secure contexts only, and also block future types of worklets (e.g. audio worklet) on secure contexts.

2. Don't change policy regarding secure contexts for other features at this time.

Other than that, I think this intent LGTM1. There are a couple of last-minute details I've brought up on other threads, but will work on them in parallel with this.

On Fri, Sep 29, 2017 at 2:06 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

On Thu, Sep 28, 2017 at 8:33 PM, 'Ian Kilpatrick' via blink-dev
<blin...@chromium.org> wrote:
> Right if its a lot - then you're right, this is much less of a concern. I
> don't see the wider browser community there yet however. E.g. we shipped ES6
> modules without this discussion, should the upcoming javascript module
> import() be shipped in secure contexts only?

I'd like that. We really need to get to the point where you need to
have strong justification to not do it.


> (I still think that there are other valid reasons discussed in api owners
> thread).

I think if we commit to doing it quite a few of those reasons will end
up disappearing due to ripple effects. And if we really turn out to be
wrong somehow it's easy enough to remove the restriction. Adding the
restriction after-the-fact is much harder.

--
https://annevankesteren.nl/

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

[Dimitri Glazkov]

LGTM3.

[Hiroki Nakagawa]

Created a crbug for the secure context restriction.

LGTM3.

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78geuRc9XPS4uECS8RkAKwaLxz-WNssQPssT8YKHiuh20A%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOtFfx79JmvOjtDeC8_dKuxqu%2B0D6%2B2gSFPes313_XSdcbf6Jg%40mail.gmail.com.

[Jochen Eisinger]

I promised to post a summary of how we arrived at the decision to ship CSS Paint on secure contexts only.

In the past, we used "powerful" as a test for identifying features that we want to remove from insecure contexts. Clearly, we shouldn't add new powerful features to insecure contexts, however, for new features this definition doesn't seem satisfying. In fact, some of us (including me) felt that this API might be a good fit for secure context only despite not being a classical powerful feature.

We tried for a while to come up with a better policy, but failed to do so. We considered "all new features", and while we eventually want to arrive at that point, it seemed premature to require this just yet. So part of our decision is to come up with a better policy for requiring secure context in a timely manner.

While not having a new policy yet, we independently looked at the CSS Paint API. It felt wrong to block this API until we have a new policy. A number of arguments for and against requiring secure contexts were presented. In the end, we decided to require a secure context since the CSS Paint API introduces a new processing model to the web (worklets), and “new processing model” was also part of the argument to require secure contexts for ServiceWorker (which, however, was a more clear cut case, as it also fitted the “powerful” description). Any site or library that plans to use this API will have to provide a polyfill or other fallback content, and it would be possible to extend @supports to also cover availability on secure contexts. This is also inline with the plan for Mozilla as stated by Anne.

In order to not create uncertainty for feature developers until we have a new policy, we generalized this to tentatively require secure contexts for new worklet based features.

I hope that helped to shed some light on how we arrived at this decision!

With that, I’m excited to get CSS Paint, and lgtm4 fwiw.

LGTM3.

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78geuRc9XPS4uECS8RkAKwaLxz-WNssQPssT8YKHiuh20A%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.