Intent to Ship: Delegated Ink Trails

Mario Bianucci

unread,

Jun 14, 2021, 7:27:53 PM6/14/21

to blink-dev, gerc...@microsoft.com

Contact emails

mab...@microsoft.com, gerc...@microsoft.com

Explainer

https://github.com/WICG/ink-enhancement/blob/main/README.md

Specification

https://wicg.github.io/ink-enhancement/

API spec

Yes

Summary

Due to the pipelined nature of rendering web pages followed by the similarly pipelined nature of OS composition, there can be a significant amount of latency from the time the user interacts with something to when the screen displays the result. The goal of this feature is to enable web applications to describe the last rendered input point with sufficient detail so that the browser or operating system can present segments of the ink trail for input that has been delivered, but not yet rendered (the pointer trail). This will result in a large portion of the rendering pipeline being skipped, allowing for lower latency between page interaction and displayed results. 

Blink component

Blink>Input

Search tags

ink, wet, dry, pointer, stroke, delegated, trail, low, latency

TAG review

https://github.com/w3ctag/design-reviews/issues/473

TAG review status

Issues Addressed

Risks

Compatibility: This API will only effect web content when it is actively being used, so no current web content should break because of this API.

Interoperability: Other browsers haven’t indicated an interest in developing this feature yet. On websites that do take advantage of the API, users on a browser without it will simply get the same experience as today in terms of latency, no change at all. The site will still be fully usable.

Gecko: No signal

WebKit: Neutral

Web developers: Positive

Inking frameworks that would benefit from the API:

https://github.com/Wacom-Developer/sdk-for-ink-web

https://github.com/pwa-builder/pwa-inking

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

Yes, to the extent that it can be.

Flag name

DelegatedInkTrails

Tracking bug

https://crbug.com/1052145

Link to entry on the Chrome Platform Status

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

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/JeGBzAfR_Bw

Thanks,

Mario Bianucci

unread,

Jun 17, 2021, 9:51:05 AM6/17/21

to blink-dev, Mario Bianucci, gerc...@microsoft.com

Friendly ping here.

Yoav Weiss

unread,

Jun 17, 2021, 10:14:06 AM6/17/21

to Mario Bianucci, blink-dev, Olga Gerchikov

On Tue, Jun 15, 2021 at 1:27 AM 'Mario Bianucci' via blink-dev <blin...@chromium.org> wrote:

Contact emails
mab...@microsoft.com, gerc...@microsoft.com

Explainer
https://github.com/WICG/ink-enhancement/blob/main/README.md

TBH, I could've used a video or a demo site to show what "inking on the web" is along with the explainer. I *think* I know what y'all are talking about, but visual aids would've helped, for someone like me who's not super familiar with this area.

Specification
https://wicg.github.io/ink-enhancement/

API spec
Yes

Summary
Due to the pipelined nature of rendering web pages followed by the similarly pipelined nature of OS composition, there can be a significant amount of latency from the time the user interacts with something to when the screen displays the result. The goal of this feature is to enable web applications to describe the last rendered input point with sufficient detail so that the browser or operating system can present segments of the ink trail for input that has been delivered, but not yet rendered (the pointer trail). This will result in a large portion of the rendering pipeline being skipped, allowing for lower latency between page interaction and displayed results. 

Blink component
Blink>Input

Search tags
ink, wet, dry, pointer, stroke, delegated, trail, low, latency

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

This seems to be an early design review, and the final note is asking y'all to work out the issues. I'm assuming this happened. Is that a correct assumption?

TAG review status
Issues Addressed

Risks
Compatibility: This API will only effect web content when it is actively being used, so no current web content should break because of this API.
Interoperability: Other browsers haven’t indicated an interest in developing this feature yet. On websites that do take advantage of the API, users on a browser without it will simply get the same experience as today in terms of latency, no change at all. The site will still be fully usable.

Gecko: No signal

WebKit: Neutral

Web developers: Positive
https://twitter.com/_scottlow/status/1397261056020389889
https://bugs.chromium.org/p/chromium/issues/detail?id=1052145

That's not a super strong signal, but I'm guessing that this capability is targeting a niche market, which makes it hard to rally up lots of folks.

Inking frameworks that would benefit from the API:
https://github.com/Wacom-Developer/sdk-for-ink-web
https://github.com/pwa-builder/pwa-inking

Have y'all talked to those folks? Would you predict they would use this capability once shipped?

Is this feature fully tested by web-platform-tests?
Yes, to the extent that it can be.

Flag name
DelegatedInkTrails

Tracking bug
https://crbug.com/1052145

Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/5961434129235968

Links to previous Intent discussions
Intent to Prototype: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/JeGBzAfR_Bw
Related prototype discussion: https://groups.google.com/u/1/a/chromium.org/g/graphics-dev/c/cErEIr4NECg

Thanks,
Mario Bianucci

--
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/6243e1e4-146e-4bca-826d-7d1910ed836fn%40chromium.org.

Olli Pettay

unread,

Jun 17, 2021, 11:46:46 AM6/17/21

to Yoav Weiss, Mario Bianucci, blink-dev, Olga Gerchikov

On 6/17/21 5:13 PM, Yoav Weiss wrote:
>
>
> On Tue, Jun 15, 2021 at 1:27 AM 'Mario Bianucci' via blink-dev <blin...@chromium.org <mailto:blin...@chromium.org>> wrote:
>
> Contact emails
>
> mab...@microsoft.com <mailto:mab...@microsoft.com>, gerc...@microsoft.com <mailto:gerc...@microsoft.com>
>
>
> Explainer
>
> https://github.com/WICG/ink-enhancement/blob/main/README.md <https://github.com/WICG/ink-enhancement/blob/main/README.md>

>
> TBH, I could've used a video or a demo site to show what "inking on the web" is along with the explainer. I *think* I know what y'all are talking
> about, but visual aids would've helped, for someone like me who's not super familiar with this area.
>
>
> Specification
>

> https://wicg.github.io/ink-enhancement/ <https://wicg.github.io/ink-enhancement/>

>
>
> API spec
>
> Yes
>
> Summary
>
> Due to the pipelined nature of rendering web pages followed by the similarly pipelined nature of OS composition, there can be a significant amount
> of latency from the time the user interacts with something to when the screen displays the result. The goal of this feature is to enable web
> applications to describe the last rendered input point with sufficient detail so that the browser or operating system can present segments of the
> ink trail for input that has been delivered, but not yet rendered (the pointer trail). This will result in a large portion of the rendering
> pipeline being skipped, allowing for lower latency between page interaction and displayed results. 
>
> Blink component
>
> Blink>Input

> y'all to work out the issues. I'm assuming this happened. Is that a correct assumption?
>
>
> TAG review status
>
> Issues Addressed
>
> Risks
>
> Compatibility: This API will only effect web content when it is actively being used, so no current web content should break because of this API.
>
> Interoperability: Other browsers haven’t indicated an interest in developing this feature yet. On websites that do take advantage of the API,
> users on a browser without it will simply get the same experience as today in terms of latency, no change at all. The site will still be fully usable.
>
> Gecko: No signal
>

FWIW,
the proposal is still rather hand wavy, so creating two interoperable implementations based on the spec proposal isn't really possible.
I wouldn't be surprised if the API needed some changes.

-Olli

> <https://github.com/mozilla/standards-positions/issues/518>WebKit: Neutral
>
> <https://lists.webkit.org/pipermail/webkit-dev/2021-May/031858.html>Web developers: Positive
>
> *
>
> https://twitter.com/_scottlow/status/1397261056020389889 <https://twitter.com/_scottlow/status/1397261056020389889>
>
> *
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1052145 <https://bugs.chromium.org/p/chromium/issues/detail?id=1052145>

>
>
> That's not a super strong signal, but I'm guessing that this capability is targeting a niche market, which makes it hard to rally up lots of folks.
>
> Inking frameworks that would benefit from the API:
>

> *
> *
> * <https://github.com/Wacom-Developer/sdk-for-ink-web>
> * https://github.com/Wacom-Developer/sdk-for-ink-web <https://github.com/Wacom-Developer/sdk-for-ink-web>
>
> <https://github.com/Wacom-Developer/sdk-for-ink-web><https://github.com/Wacom-Developer/sdk-for-ink-web>
>
> *
>
> https://github.com/pwa-builder/pwa-inking <https://github.com/pwa-builder/pwa-inking>

>
> Have y'all talked to those folks? Would you predict they would use this capability once shipped?
>

> Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?

>
> Yes, to the extent that it can be.

> <https://github.com/web-platform-tests/wpt/tree/master/delegated-ink>

>
> Flag name
>
> DelegatedInkTrails
>
> Tracking bug
>
> https://crbug.com/1052145
> <https://crbug.com/1052145>
>
> Link to entry on the Chrome Platform Status
>

> https://www.chromestatus.com/feature/5961434129235968 <https://www.chromestatus.com/feature/5961434129235968>

>
>
> Links to previous Intent discussions
>
> Intent to Prototype: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/JeGBzAfR_Bw
> <https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/JeGBzAfR_Bw>
>
> Related prototype discussion: https://groups.google.com/u/1/a/chromium.org/g/graphics-dev/c/cErEIr4NECg
> <https://groups.google.com/u/1/a/chromium.org/g/graphics-dev/c/cErEIr4NECg>
>
> Thanks,
>
> Mario Bianucci
>
> --
> 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/6243e1e4-146e-4bca-826d-7d1910ed836fn%40chromium.org

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6243e1e4-146e-4bca-826d-7d1910ed836fn%40chromium.org?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/CAL5BFfWw--PTD%2BPF3P0sKgkwe29_WcQ5Xyi6jakoZn0EeDx0XQ%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWw--PTD%2BPF3P0sKgkwe29_WcQ5Xyi6jakoZn0EeDx0XQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

Yoav Weiss

unread,

Jun 17, 2021, 11:52:26 AM6/17/21

to Olli Pettay, Mario Bianucci, blink-dev, Olga Gerchikov

Hey Olli!

I think more concrete feedback can be useful for the folks working on this. Do you think you'd be able to review the proposal and file issues that you consider blockers for interop?

Yoav Weiss

unread,

Jun 17, 2021, 12:18:56 PM6/17/21

to Olli Pettay, Mario Bianucci, blink-dev, Olga Gerchikov

On Thu, Jun 17, 2021 at 6:06 PM Olli Pettay <ol...@pettay.fi> wrote:

On 6/17/21 6:51 PM, Yoav Weiss wrote:

>
>
> On Thu, Jun 17, 2021 at 4:36 PM Olli Pettay <ol...@pettay.fi <mailto:ol...@pettay.fi>> wrote:
>
> On 6/17/21 5:13 PM, Yoav Weiss wrote:
> >
> >
> > On Tue, Jun 15, 2021 at 1:27 AM 'Mario Bianucci' via blink-dev <blin...@chromium.org <mailto:blin...@chromium.org>

> <mailto:blin...@chromium.org <mailto:blin...@chromium.org>>> wrote:
> >
> > Contact emails
> >

> > mab...@microsoft.com <mailto:mab...@microsoft.com> <mailto:mab...@microsoft.com <mailto:mab...@microsoft.com>>, gerc...@microsoft.com
> <mailto:gerc...@microsoft.com> <mailto:gerc...@microsoft.com <mailto:gerc...@microsoft.com>>

> >
> >
> > Explainer
> >
> > https://github.com/WICG/ink-enhancement/blob/main/README.md <https://github.com/WICG/ink-enhancement/blob/main/README.md>
> <https://github.com/WICG/ink-enhancement/blob/main/README.md <https://github.com/WICG/ink-enhancement/blob/main/README.md>>
> >
> > TBH, I could've used a video or a demo site to show what "inking on the web" is along with the explainer. I *think* I know what y'all are talking
> > about, but visual aids would've helped, for someone like me who's not super familiar with this area.
> >
> >
> > Specification
> >

> > https://wicg.github.io/ink-enhancement/ <https://wicg.github.io/ink-enhancement/> <https://wicg.github.io/ink-enhancement/

> <https://wicg.github.io/ink-enhancement/>>
> >
> >
> > API spec
> >
> > Yes
> >
> > Summary
> >
> > Due to the pipelined nature of rendering web pages followed by the similarly pipelined nature of OS composition, there can be a significant
> amount
> > of latency from the time the user interacts with something to when the screen displays the result. The goal of this feature is to enable web
> > applications to describe the last rendered input point with sufficient detail so that the browser or operating system can present segments
> of the
> > ink trail for input that has been delivered, but not yet rendered (the pointer trail). This will result in a large portion of the rendering
> > pipeline being skipped, allowing for lower latency between page interaction and displayed results. 
> >
> > Blink component
> >
> > Blink>Input
> > <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3EInput
> <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3EInput>>
> >
> > Search tags
> >

> > ink <https://www.chromestatus.com/features#tags:ink <https://www.chromestatus.com/features#tags:ink>>, wet
> <https://www.chromestatus.com/features#tags:wet <https://www.chromestatus.com/features#tags:wet>>, dry
> > <https://www.chromestatus.com/features#tags:dry <https://www.chromestatus.com/features#tags:dry>>, pointer
> <https://www.chromestatus.com/features#tags:pointer <https://www.chromestatus.com/features#tags:pointer>>, stroke
> > <https://www.chromestatus.com/features#tags:stroke <https://www.chromestatus.com/features#tags:stroke>>, delegated
> <https://www.chromestatus.com/features#tags:delegated <https://www.chromestatus.com/features#tags:delegated>>, trail
> > <https://www.chromestatus.com/features#tags:trail <https://www.chromestatus.com/features#tags:trail>>, low
> <https://www.chromestatus.com/features#tags:low <https://www.chromestatus.com/features#tags:low>>, latency
> > <https://www.chromestatus.com/features#tags:latency <https://www.chromestatus.com/features#tags:latency>>

> >
> > TAG review
> >
> > https://github.com/w3ctag/design-reviews/issues/473 <https://github.com/w3ctag/design-reviews/issues/473>
> <https://github.com/w3ctag/design-reviews/issues/473 <https://github.com/w3ctag/design-reviews/issues/473>>
> >
> > This seems to be an early design review, and the final note < https://github.com/w3ctag/design-reviews/issues/473#issuecomment-617554709
> <https://github.com/w3ctag/design-reviews/issues/473#issuecomment-617554709>> is asking
> > y'all to work out the issues. I'm assuming this happened. Is that a correct assumption?
> >
> >
> > TAG review status
> >
> > Issues Addressed
> >
> > Risks
> >
> > Compatibility: This API will only effect web content when it is actively being used, so no current web content should break because of this
> API.
> >
> > Interoperability: Other browsers haven’t indicated an interest in developing this feature yet. On websites that do take advantage of the API,
> > users on a browser without it will simply get the same experience as today in terms of latency, no change at all. The site will still be
> fully usable.
> >
> > Gecko: No signal
> >
>
> FWIW,
> the proposal is still rather hand wavy, so creating two interoperable implementations based on the spec proposal isn't really possible.
> I wouldn't be surprised if the API needed some changes.
>
>
> Hey Olli!
>
> I think more concrete feedback can be useful for the folks working on this. Do you think you'd be able to review the proposal and file issues that you
> consider blockers for interop?

I noted about some of the issues in https://github.com/mozilla/standards-positions/issues/518.
I'll file spec issues in a moment.

Thank you so much!! :)

-Olli

>
>
>
>
> -Olli
>
>
> > <https://github.com/mozilla/standards-positions/issues/518 <https://github.com/mozilla/standards-positions/issues/518>>WebKit: Neutral

> >
> > <https://lists.webkit.org/pipermail/webkit-dev/2021-May/031858.html
> <https://lists.webkit.org/pipermail/webkit-dev/2021-May/031858.html>>Web developers: Positive
> >
> > *
> >
> > https://twitter.com/_scottlow/status/1397261056020389889 <https://twitter.com/_scottlow/status/1397261056020389889>
> <https://twitter.com/_scottlow/status/1397261056020389889 <https://twitter.com/_scottlow/status/1397261056020389889>>
> >
> > *
> >
> > https://bugs.chromium.org/p/chromium/issues/detail?id=1052145 <https://bugs.chromium.org/p/chromium/issues/detail?id=1052145>
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1052145 <https://bugs.chromium.org/p/chromium/issues/detail?id=1052145>>
> >
> >
> > That's not a super strong signal, but I'm guessing that this capability is targeting a niche market, which makes it hard to rally up lots of folks.
> >
> > Inking frameworks that would benefit from the API:
> >
> > *
> > *

> > * <https://github.com/Wacom-Developer/sdk-for-ink-web <https://github.com/Wacom-Developer/sdk-for-ink-web>>

> > * https://github.com/Wacom-Developer/sdk-for-ink-web <https://github.com/Wacom-Developer/sdk-for-ink-web>
> <https://github.com/Wacom-Developer/sdk-for-ink-web <https://github.com/Wacom-Developer/sdk-for-ink-web>>
> >
> > <https://github.com/Wacom-Developer/sdk-for-ink-web
> <https://github.com/Wacom-Developer/sdk-for-ink-web>><https://github.com/Wacom-Developer/sdk-for-ink-web
> <https://github.com/Wacom-Developer/sdk-for-ink-web>>
> >
> > *
> >

> > https://github.com/pwa-builder/pwa-inking <https://github.com/pwa-builder/pwa-inking> <https://github.com/pwa-builder/pwa-inking

> <https://github.com/pwa-builder/pwa-inking>>
> >
> > Have y'all talked to those folks? Would you predict they would use this capability once shipped?
> >
> > Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md
> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>>?
> >
> > Yes, to the extent that it can be.

> > <https://github.com/web-platform-tests/wpt/tree/master/delegated-ink <https://github.com/web-platform-tests/wpt/tree/master/delegated-ink>>

> >
> > Flag name
> >
> > DelegatedInkTrails
> >
> > Tracking bug
> >
> > https://crbug.com/1052145 <https://crbug.com/1052145>
> > <https://crbug.com/1052145 <https://crbug.com/1052145>>
> >
> > Link to entry on the Chrome Platform Status
> >
> > https://www.chromestatus.com/feature/5961434129235968 <https://www.chromestatus.com/feature/5961434129235968>
> <https://www.chromestatus.com/feature/5961434129235968 <https://www.chromestatus.com/feature/5961434129235968>>
> >
> >
> > Links to previous Intent discussions
> >
> > Intent to Prototype: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/JeGBzAfR_Bw
> <https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/JeGBzAfR_Bw>
> > <https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/JeGBzAfR_Bw
> <https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/JeGBzAfR_Bw>>
> >
> > Related prototype discussion: https://groups.google.com/u/1/a/chromium.org/g/graphics-dev/c/cErEIr4NECg
> <https://groups.google.com/u/1/a/chromium.org/g/graphics-dev/c/cErEIr4NECg>
> > <https://groups.google.com/u/1/a/chromium.org/g/graphics-dev/c/cErEIr4NECg
> <https://groups.google.com/u/1/a/chromium.org/g/graphics-dev/c/cErEIr4NECg>>
> >
> > Thanks,
> >
> > Mario Bianucci
> >
> > --
> > 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%2Bunsu...@chromium.org>
> > <mailto:blink-dev+...@chromium.org <mailto:blink-dev%2Bunsu...@chromium.org>>.

> > To view this discussion on the web visit
> > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6243e1e4-146e-4bca-826d-7d1910ed836fn%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6243e1e4-146e-4bca-826d-7d1910ed836fn%40chromium.org>
> >

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6243e1e4-146e-4bca-826d-7d1910ed836fn%40chromium.org?utm_medium=email&utm_source=footer <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6243e1e4-146e-4bca-826d-7d1910ed836fn%40chromium.org?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%2Bunsu...@chromium.org>
> > <mailto:blink-dev+...@chromium.org <mailto:blink-dev%2Bunsu...@chromium.org>>.

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

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

Olli Pettay

unread,

Jun 19, 2021, 8:20:01 PM6/19/21

to Yoav Weiss, Mario Bianucci, blink-dev, Olga Gerchikov

On 6/17/21 6:51 PM, Yoav Weiss wrote:

>
>
> On Thu, Jun 17, 2021 at 4:36 PM Olli Pettay <ol...@pettay.fi <mailto:ol...@pettay.fi>> wrote:
>
> On 6/17/21 5:13 PM, Yoav Weiss wrote:
> >
> >
> > On Tue, Jun 15, 2021 at 1:27 AM 'Mario Bianucci' via blink-dev <blin...@chromium.org <mailto:blin...@chromium.org>
> <mailto:blin...@chromium.org <mailto:blin...@chromium.org>>> wrote:
> >
> > Contact emails
> >

> > mab...@microsoft.com <mailto:mab...@microsoft.com> <mailto:mab...@microsoft.com <mailto:mab...@microsoft.com>>, gerc...@microsoft.com
> <mailto:gerc...@microsoft.com> <mailto:gerc...@microsoft.com <mailto:gerc...@microsoft.com>>

> >
> >
> > Explainer
> >
> > https://github.com/WICG/ink-enhancement/blob/main/README.md <https://github.com/WICG/ink-enhancement/blob/main/README.md>
> <https://github.com/WICG/ink-enhancement/blob/main/README.md <https://github.com/WICG/ink-enhancement/blob/main/README.md>>
> >
> > TBH, I could've used a video or a demo site to show what "inking on the web" is along with the explainer. I *think* I know what y'all are talking
> > about, but visual aids would've helped, for someone like me who's not super familiar with this area.
> >
> >
> > Specification
> >

> > https://wicg.github.io/ink-enhancement/ <https://wicg.github.io/ink-enhancement/> <https://wicg.github.io/ink-enhancement/

> <https://wicg.github.io/ink-enhancement/>>
> >
> >
> > API spec
> >
> > Yes
> >
> > Summary
> >
> > Due to the pipelined nature of rendering web pages followed by the similarly pipelined nature of OS composition, there can be a significant
> amount
> > of latency from the time the user interacts with something to when the screen displays the result. The goal of this feature is to enable web
> > applications to describe the last rendered input point with sufficient detail so that the browser or operating system can present segments
> of the
> > ink trail for input that has been delivered, but not yet rendered (the pointer trail). This will result in a large portion of the rendering
> > pipeline being skipped, allowing for lower latency between page interaction and displayed results. 
> >
> > Blink component
> >
> > Blink>Input
> > <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3EInput
> <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3EInput>>
> >
> > Search tags
> >

> >
> > TAG review
> >
> > https://github.com/w3ctag/design-reviews/issues/473 <https://github.com/w3ctag/design-reviews/issues/473>
> <https://github.com/w3ctag/design-reviews/issues/473 <https://github.com/w3ctag/design-reviews/issues/473>>
> >
> > This seems to be an early design review, and the final note < https://github.com/w3ctag/design-reviews/issues/473#issuecomment-617554709
> <https://github.com/w3ctag/design-reviews/issues/473#issuecomment-617554709>> is asking
> > y'all to work out the issues. I'm assuming this happened. Is that a correct assumption?
> >
> >
> > TAG review status
> >
> > Issues Addressed
> >
> > Risks
> >
> > Compatibility: This API will only effect web content when it is actively being used, so no current web content should break because of this
> API.
> >
> > Interoperability: Other browsers haven’t indicated an interest in developing this feature yet. On websites that do take advantage of the API,
> > users on a browser without it will simply get the same experience as today in terms of latency, no change at all. The site will still be
> fully usable.
> >
> > Gecko: No signal
> >
>
> FWIW,
> the proposal is still rather hand wavy, so creating two interoperable implementations based on the spec proposal isn't really possible.
> I wouldn't be surprised if the API needed some changes.
>
>
> Hey Olli!
>
> I think more concrete feedback can be useful for the folks working on this. Do you think you'd be able to review the proposal and file issues that you
> consider blockers for interop?

I noted about some of the issues in https://github.com/mozilla/standards-positions/issues/518.
I'll file spec issues in a moment.

-Olli

>
>
>
>
> -Olli
>
>
> > <https://github.com/mozilla/standards-positions/issues/518 <https://github.com/mozilla/standards-positions/issues/518>>WebKit: Neutral

> >
> > <https://lists.webkit.org/pipermail/webkit-dev/2021-May/031858.html
> <https://lists.webkit.org/pipermail/webkit-dev/2021-May/031858.html>>Web developers: Positive
> >
> > *
> >
> > https://twitter.com/_scottlow/status/1397261056020389889 <https://twitter.com/_scottlow/status/1397261056020389889>
> <https://twitter.com/_scottlow/status/1397261056020389889 <https://twitter.com/_scottlow/status/1397261056020389889>>
> >
> > *
> >
> > https://bugs.chromium.org/p/chromium/issues/detail?id=1052145 <https://bugs.chromium.org/p/chromium/issues/detail?id=1052145>
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1052145 <https://bugs.chromium.org/p/chromium/issues/detail?id=1052145>>
> >
> >
> > That's not a super strong signal, but I'm guessing that this capability is targeting a niche market, which makes it hard to rally up lots of folks.
> >
> > Inking frameworks that would benefit from the API:
> >
> > *
> > *

> > * <https://github.com/Wacom-Developer/sdk-for-ink-web <https://github.com/Wacom-Developer/sdk-for-ink-web>>

> > * https://github.com/Wacom-Developer/sdk-for-ink-web <https://github.com/Wacom-Developer/sdk-for-ink-web>
> <https://github.com/Wacom-Developer/sdk-for-ink-web <https://github.com/Wacom-Developer/sdk-for-ink-web>>
> >
> > <https://github.com/Wacom-Developer/sdk-for-ink-web
> <https://github.com/Wacom-Developer/sdk-for-ink-web>><https://github.com/Wacom-Developer/sdk-for-ink-web
> <https://github.com/Wacom-Developer/sdk-for-ink-web>>
> >
> > *
> >

> > https://github.com/pwa-builder/pwa-inking <https://github.com/pwa-builder/pwa-inking> <https://github.com/pwa-builder/pwa-inking

> <https://github.com/pwa-builder/pwa-inking>>
> >
> > Have y'all talked to those folks? Would you predict they would use this capability once shipped?
> >
> > Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md
> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>>?
> >
> > Yes, to the extent that it can be.

> > <https://github.com/web-platform-tests/wpt/tree/master/delegated-ink <https://github.com/web-platform-tests/wpt/tree/master/delegated-ink>>

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

> > To view this discussion on the web visit
> > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6243e1e4-146e-4bca-826d-7d1910ed836fn%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6243e1e4-146e-4bca-826d-7d1910ed836fn%40chromium.org>
> >

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6243e1e4-146e-4bca-826d-7d1910ed836fn%40chromium.org?utm_medium=email&utm_source=footer <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6243e1e4-146e-4bca-826d-7d1910ed836fn%40chromium.org?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%2Bunsu...@chromium.org>
> > <mailto:blink-dev+...@chromium.org <mailto:blink-dev%2Bunsu...@chromium.org>>.

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

Mario Bianucci

unread,

Jun 23, 2021, 12:16:38 PM6/23/21

to blink-dev, Olli Pettay, Mario Bianucci, blink-dev, Olga Gerchikov, yoav...@chromium.org

Thanks for the feedback! Olli, I'm going to follow up on the issues that you opened on the explainer directly. Once we're happy with a resolution, I'll get the spec updated. We aren't actively updating the explainer anymore, I'll make sure that gets updated to reflect its current status as well.

Yoav - replies are inline.

On Saturday, June 19, 2021 at 5:20:01 PM UTC-7 Olli Pettay wrote:

On 6/17/21 6:51 PM, Yoav Weiss wrote:
>
>
> On Thu, Jun 17, 2021 at 4:36 PM Olli Pettay <ol...@pettay.fi <mailto:ol...@pettay.fi>> wrote:
>
> On 6/17/21 5:13 PM, Yoav Weiss wrote:
> >
> >
> > On Tue, Jun 15, 2021 at 1:27 AM 'Mario Bianucci' via blink-dev <blin...@chromium.org <mailto:blin...@chromium.org>
> <mailto:blin...@chromium.org <mailto:blin...@chromium.org>>> wrote:
> >
> > Contact emails
> >
> > mab...@microsoft.com <mailto:mab...@microsoft.com> <mailto:mab...@microsoft.com <mailto:mab...@microsoft.com>>, gerc...@microsoft.com
> <mailto:gerc...@microsoft.com> <mailto:gerc...@microsoft.com <mailto:gerc...@microsoft.com>>
> >
> >
> > Explainer
> >
> > https://github.com/WICG/ink-enhancement/blob/main/README.md <https://github.com/WICG/ink-enhancement/blob/main/README.md>
> <https://github.com/WICG/ink-enhancement/blob/main/README.md <https://github.com/WICG/ink-enhancement/blob/main/README.md>>
> >
> > TBH, I could've used a video or a demo site to show what "inking on the web" is along with the explainer. I *think* I know what y'all are talking
> > about, but visual aids would've helped, for someone like me who's not super familiar with this area.

That's a great point, maybe we could also add in a link to a demo site as well, at least on the explainer. For the moment though, here is a demo web app for inking on the web: WebBoard (webboard-app.web.app)

(Source is here: pwa-builder/web-whiteboard (github.com) Another repo that I'm chatting with to pick up delegated ink trail usage 😊)

Yep! Issues were addressed, and we continue to work with and get feedback from developers and other implementers as we go.

Yes, I was having a tough time thinking of other ways to build up support around this. If you have ideas, I'm happy to give things a shot though!

> >
> > Inking frameworks that would benefit from the API:
> >
> > *
> > *
> > * <https://github.com/Wacom-Developer/sdk-for-ink-web <https://github.com/Wacom-Developer/sdk-for-ink-web>>
> > * https://github.com/Wacom-Developer/sdk-for-ink-web <https://github.com/Wacom-Developer/sdk-for-ink-web>
> <https://github.com/Wacom-Developer/sdk-for-ink-web <https://github.com/Wacom-Developer/sdk-for-ink-web>>
> >
> > <https://github.com/Wacom-Developer/sdk-for-ink-web
> <https://github.com/Wacom-Developer/sdk-for-ink-web>><https://github.com/Wacom-Developer/sdk-for-ink-web
> <https://github.com/Wacom-Developer/sdk-for-ink-web>>
> >
> > *
> >
> > https://github.com/pwa-builder/pwa-inking <https://github.com/pwa-builder/pwa-inking> <https://github.com/pwa-builder/pwa-inking
> <https://github.com/pwa-builder/pwa-inking>>
> >
> > Have y'all talked to those folks? Would you predict they would use this capability once shipped?

I have talked with the pwa-inking folks - they are excited about it, and think it would be a good fit for both this and the demo site I linked above, which was made by the same team.

Still working on getting a discussion started with Wacom on their SDK, but I can't see why they wouldn't be interested in using it since the SDK is explicitly for inking on the web.

Yoav Weiss

unread,

Jun 24, 2021, 3:03:01 PM6/24/21

to blink-dev, Mario Bianucci, Olli Pettay, blink-dev, Olga Gerchikov, Yoav Weiss

Hey Mario,

Thanks for the explanations. I saw that Olli filed 5 issues on the spec. Is it safe to assume y'all would address them?

No radical ideas, sorry!

Mario Bianucci

unread,

Jun 24, 2021, 3:23:59 PM6/24/21

to blink-dev, yoav...@chromium.org, Mario Bianucci, Olli Pettay, blink-dev, Olga Gerchikov

No problem! And yes, definitely planning on addressing them. I'm just working with some users that have been testing out the API to make sure how I plan to clarify the issues works for them. Once it all looks good from their perspective, I'll reply to Olli's issues on GitHub and we can make sure we come to an agreement and get things cleared up, then I'll update the spec accordingly.

Mario Bianucci

unread,

Jun 28, 2021, 12:04:56 PM6/28/21

to blink-dev, Mario Bianucci, yoav...@chromium.org, Olli Pettay, blink-dev, Olga Gerchikov

Friendly ping, since I've replied to Olli's issues and we'll hopefully get them resolved and the spec updated soon.

Alex Russell

unread,

Jul 1, 2021, 3:15:13 PM7/1/21

to blink-dev, Mario Bianucci, Yoav Weiss, Olli Pettay, blink-dev, Olga Gerchikov

LGTM1; thanks for responding to those issues.

Mike West

unread,

Jul 7, 2021, 2:19:45 AM7/7/21

to Alex Russell, blink-dev, Mario Bianucci, Yoav Weiss, Olli Pettay, Olga Gerchikov

LGTM2. I've skimmed through the issues raised, and none seem blocking to me (though they certainly point to legitimate areas that need to be clarified). If you can get the relevant updates into the spec, I'm comfortable with shipping this.

-mike

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/95e09311-b9b5-42ea-9a98-4b1e3160936bn%40chromium.org.

Yoav Weiss

unread,

Jul 7, 2021, 2:44:05 AM7/7/21

to Mike West, Alex Russell, blink-dev, Mario Bianucci, Olli Pettay, Olga Gerchikov

Going over the issues, #20 seems like one we want to settle before shipping. If `type` is currently a no-op, I agree it doesn't make sense to add it as a placeholder. Also, how would developers know in the future that it turned from a noop argument into a meaningful one?

Also also, for #22, if we're planning on a future behavior change, we should think about that change's compatibility implications.

Yoav Weiss

unread,

Jul 8, 2021, 3:50:19 AM7/8/21

to Mario Bianucci, blink-dev, sligh...@chromium.org, Mario Bianucci, Olli Pettay, Olga Gerchikov, mk...@chromium.org

On Wed, Jul 7, 2021 at 8:43 PM Mario Bianucci <bian...@gmail.com> wrote:

Thanks for the LGTMs so far!

Regarding issue #20, 'type' currently is a "no-op", but it is intended to enable extensibility in the future. While there isn't a firm proposal or explainer for anything right now, it is easy to imagine a scenario where it could be extended to support ink trails rendered via shaders, rather than just a solid color stroke. Then we could support something like 'shader-trail' alongside the 'delegated-ink-trail' type that this feature uses. This is actually something that an partner has asked about already.

Its possible that this is the wrong model for extensibility and I'm happy to revisit it if you think so, but I think have some plan for it to be easily extended is reasonable.

I think it's worthwhile to raise that specific question with the TAG and get their opinions on this.

Personally, I've seen the "initializer dictionary" pattern used for future extensibility (e.g. with PerformanceObserver), although that pattern suffers from lack of clear feature negotiation.

For #22, after a bit more thought, I don't anticipate that we would need to change how it works today. It seems like it would be very unusual for an author to need any of the Ink instance, presentationArea, or PointerEvent to be in different documents, I can't imagine what it would look like from a user perspective. And if we did decide to expand the spec to support that scenario, I don't expect that it would require too much of a change from the current form of the spec.

I've updated the spec to clarify the issues that Olli brought up other than #20 now. I'll update it again if necessary once we all agree on a resolution for the 'type' issue.

Yoav Weiss

unread,

Jul 8, 2021, 6:05:14 AM7/8/21

to Olli Pettay, Mario Bianucci, blink-dev, sligh...@chromium.org, Mario Bianucci, Olga Gerchikov, mk...@chromium.org

On Thu, Jul 8, 2021 at 11:52 AM Olli Pettay <ol...@pettay.fi> wrote:

On 7/8/21 10:49 AM, Yoav Weiss wrote:

>
>
> On Wed, Jul 7, 2021 at 8:43 PM Mario Bianucci <bian...@gmail.com <mailto:bian...@gmail.com>> wrote:
>
> Thanks for the LGTMs so far!
>
> Regarding issue #20, 'type' currently is a "no-op", but it is intended to enable extensibility in the future. While there isn't a firm proposal or
> explainer for anything right now, it is easy to imagine a scenario where it could be extended to support ink trails rendered via shaders, rather
> than just a solid color stroke. Then we could support something like 'shader-trail' alongside the 'delegated-ink-trail' type that this feature
> uses. This is actually something that an partner has asked about already.
>
> Its possible that this is the wrong model for extensibility and I'm happy to revisit it if you think so, but I think have some plan for it to be
> easily extended is reasonable.
>
>
> I think it's worthwhile to raise that specific question with the TAG and get their opinions on this.
> Personally, I've seen the "initializer dictionary" pattern used for future extensibility (e.g. with PerformanceObserver

> <https://w3c.github.io/performance-timeline/#dom-performanceobserverinit>), although that pattern suffers from lack of clear feature negotiation.

One can use throwing getters to do feature detection with dictionaries.
For example
new Event("", { get bubbles() { throw "if this is called, 'bubbles' is supported, but throwing from the getter prevents creating Event"; }})

Sure, but that's a somewhat complex pattern. See https://github.com/heycam/webidl/issues/107 which I'm sure you're familiar with.

>
>
> For #22, after a bit more thought, I don't anticipate that we would need to change how it works today. It seems like it would be very unusual for
> an author to need any of the Ink instance, presentationArea, or PointerEvent to be in different documents, I can't imagine what it would look like
> from a user perspective. And if we did decide to expand the spec to support that scenario, I don't expect that it would require too much of a
> change from the current form of the spec.
>
> I've updated the spec to clarify the issues that Olli brought up other than #20 now. I'll update it again if necessary once we all agree on a
> resolution for the 'type' issue.
>

> On Wednesday, July 7, 2021 at 2:44:05 AM UTC-4 yoav...@chromium.org <mailto:yoav...@chromium.org> wrote:
>
> Going over the issues, #20 <https://github.com/WICG/ink-enhancement/issues/20> seems like one we want to settle before shipping. If `type` is

> currently a no-op, I agree it doesn't make sense to add it as a placeholder. Also, how would developers know in the future that it turned from
> a noop argument into a meaningful one?

> Also also, for #22 <https://github.com/WICG/ink-enhancement/issues/22#issuecomment-868826593>, if we're planning on a future behavior change,

> we should think about that change's compatibility implications.
>
>
> On Wed, Jul 7, 2021 at 8:19 AM Mike West <mk...@chromium.org> wrote:
>
> LGTM2. I've skimmed through the issues raised, and none seem blocking to me (though they certainly point to legitimate areas that need to
> be clarified). If you can get the relevant updates into the spec, I'm comfortable with shipping this.
>
> -mike
>
>
> On Thu, Jul 1, 2021 at 9:15 PM Alex Russell <sligh...@chromium.org> wrote:
>
> LGTM1; thanks for responding to those issues.
>
> On Monday, June 28, 2021 at 9:04:56 AM UTC-7 Mario Bianucci wrote:
>
> Friendly ping, since I've replied to Olli's issues and we'll hopefully get them resolved and the spec updated soon.
>
> On Thursday, June 24, 2021 at 12:23:59 PM UTC-7 Mario Bianucci wrote:
>
> No problem! And yes, definitely planning on addressing them. I'm just working with some users that have been testing out the
> API to make sure how I plan to clarify the issues works for them. Once it all looks good from their perspective, I'll reply to
> Olli's issues on GitHub and we can make sure we come to an agreement and get things cleared up, then I'll update the spec
> accordingly.
>
> On Thursday, June 24, 2021 at 12:03:01 PM UTC-7 yoav...@chromium.org wrote:
>
> Hey Mario,
>

> Thanks for the explanations. I saw that Olli filed 5 issues <https://github.com/WICG/ink-enhancement/issues/> on the spec.

> <https://webboard-app.web.app/>
>
> (Source is here: pwa-builder/web-whiteboard (github.com) <https://github.com/pwa-builder/web-whiteboard> Another repo

> <https://github.com/mozilla/standards-positions/issues/518>.

> <https://github.com/Wacom-Developer/sdk-for-ink-web> <https://github.com/Wacom-Developer/sdk-for-ink-web

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6243e1e4-146e-4bca-826d-7d1910ed836fn%40chromium.org?utm_medium=email&utm_source=footer <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6243e1e4-146e-4bca-826d-7d1910ed836fn%40chromium.org?utm_medium=email&utm_source=footer> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6243e1e4-146e-4bca-826d-7d1910ed836fn%40chromium.org?utm_medium=email&utm_source=footer <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6243e1e4-146e-4bca-826d-7d1910ed836fn%40chromium.org?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%2Bunsu...@chromium.org>
> > > <mailto:blink-dev+...@chromium.org <mailto:blink-dev%2Bunsu...@chromium.org>>.
>
> > > To view this discussion on the web visit
> > >
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWw--PTD%2BPF3P0sKgkwe29_WcQ5Xyi6jakoZn0EeDx0XQ%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWw--PTD%2BPF3P0sKgkwe29_WcQ5Xyi6jakoZn0EeDx0XQ%40mail.gmail.com>
>
> >
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWw--PTD%2BPF3P0sKgkwe29_WcQ5Xyi6jakoZn0EeDx0XQ%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWw--PTD%2BPF3P0sKgkwe29_WcQ5Xyi6jakoZn0EeDx0XQ%40mail.gmail.com>>
>
> > >
> >
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWw--PTD%2BPF3P0sKgkwe29_WcQ5Xyi6jakoZn0EeDx0XQ%40mail.gmail.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWw--PTD%2BPF3P0sKgkwe29_WcQ5Xyi6jakoZn0EeDx0XQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>
> >
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWw--PTD%2BPF3P0sKgkwe29_WcQ5Xyi6jakoZn0EeDx0XQ%40mail.gmail.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWw--PTD%2BPF3P0sKgkwe29_WcQ5Xyi6jakoZn0EeDx0XQ%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.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/95e09311-b9b5-42ea-9a98-4b1e3160936bn%40chromium.org

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/95e09311-b9b5-42ea-9a98-4b1e3160936bn%40chromium.org?utm_medium=email&utm_source=footer>.
>

Olli Pettay

unread,

Jul 8, 2021, 11:59:57 AM7/8/21

to Yoav Weiss, Mario Bianucci, blink-dev, sligh...@chromium.org, Mario Bianucci, Olga Gerchikov, mk...@chromium.org

On 7/8/21 10:49 AM, Yoav Weiss wrote:
>
>

> On Wed, Jul 7, 2021 at 8:43 PM Mario Bianucci <bian...@gmail.com <mailto:bian...@gmail.com>> wrote:
>
> Thanks for the LGTMs so far!
>
> Regarding issue #20, 'type' currently is a "no-op", but it is intended to enable extensibility in the future. While there isn't a firm proposal or
> explainer for anything right now, it is easy to imagine a scenario where it could be extended to support ink trails rendered via shaders, rather
> than just a solid color stroke. Then we could support something like 'shader-trail' alongside the 'delegated-ink-trail' type that this feature
> uses. This is actually something that an partner has asked about already.
>
> Its possible that this is the wrong model for extensibility and I'm happy to revisit it if you think so, but I think have some plan for it to be
> easily extended is reasonable.
>
>
> I think it's worthwhile to raise that specific question with the TAG and get their opinions on this.
> Personally, I've seen the "initializer dictionary" pattern used for future extensibility (e.g. with PerformanceObserver

> <https://w3c.github.io/performance-timeline/#dom-performanceobserverinit>), although that pattern suffers from lack of clear feature negotiation.

One can use throwing getters to do feature detection with dictionaries.
For example
new Event("", { get bubbles() { throw "if this is called, 'bubbles' is supported, but throwing from the getter prevents creating Event"; }})

>
>

> For #22, after a bit more thought, I don't anticipate that we would need to change how it works today. It seems like it would be very unusual for
> an author to need any of the Ink instance, presentationArea, or PointerEvent to be in different documents, I can't imagine what it would look like
> from a user perspective. And if we did decide to expand the spec to support that scenario, I don't expect that it would require too much of a
> change from the current form of the spec.
>
> I've updated the spec to clarify the issues that Olli brought up other than #20 now. I'll update it again if necessary once we all agree on a
> resolution for the 'type' issue.
>

> On Wednesday, July 7, 2021 at 2:44:05 AM UTC-4 yoav...@chromium.org <mailto:yoav...@chromium.org> wrote:
>
> Going over the issues, #20 <https://github.com/WICG/ink-enhancement/issues/20> seems like one we want to settle before shipping. If `type` is

> currently a no-op, I agree it doesn't make sense to add it as a placeholder. Also, how would developers know in the future that it turned from
> a noop argument into a meaningful one?

> Also also, for #22 <https://github.com/WICG/ink-enhancement/issues/22#issuecomment-868826593>, if we're planning on a future behavior change,

> we should think about that change's compatibility implications.
>
>
> On Wed, Jul 7, 2021 at 8:19 AM Mike West <mk...@chromium.org> wrote:
>
> LGTM2. I've skimmed through the issues raised, and none seem blocking to me (though they certainly point to legitimate areas that need to
> be clarified). If you can get the relevant updates into the spec, I'm comfortable with shipping this.
>
> -mike
>
>
> On Thu, Jul 1, 2021 at 9:15 PM Alex Russell <sligh...@chromium.org> wrote:
>
> LGTM1; thanks for responding to those issues.
>
> On Monday, June 28, 2021 at 9:04:56 AM UTC-7 Mario Bianucci wrote:
>
> Friendly ping, since I've replied to Olli's issues and we'll hopefully get them resolved and the spec updated soon.
>
> On Thursday, June 24, 2021 at 12:23:59 PM UTC-7 Mario Bianucci wrote:
>
> No problem! And yes, definitely planning on addressing them. I'm just working with some users that have been testing out the
> API to make sure how I plan to clarify the issues works for them. Once it all looks good from their perspective, I'll reply to
> Olli's issues on GitHub and we can make sure we come to an agreement and get things cleared up, then I'll update the spec
> accordingly.
>
> On Thursday, June 24, 2021 at 12:03:01 PM UTC-7 yoav...@chromium.org wrote:
>
> Hey Mario,
>

> Thanks for the explanations. I saw that Olli filed 5 issues <https://github.com/WICG/ink-enhancement/issues/> on the spec.

> <https://webboard-app.web.app/>
>
> (Source is here: pwa-builder/web-whiteboard (github.com) <https://github.com/pwa-builder/web-whiteboard> Another repo

> <https://github.com/mozilla/standards-positions/issues/518>.

> <https://github.com/Wacom-Developer/sdk-for-ink-web> <https://github.com/Wacom-Developer/sdk-for-ink-web

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6243e1e4-146e-4bca-826d-7d1910ed836fn%40chromium.org?utm_medium=email&utm_source=footer <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6243e1e4-146e-4bca-826d-7d1910ed836fn%40chromium.org?utm_medium=email&utm_source=footer> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6243e1e4-146e-4bca-826d-7d1910ed836fn%40chromium.org?utm_medium=email&utm_source=footer <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6243e1e4-146e-4bca-826d-7d1910ed836fn%40chromium.org?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%2Bunsu...@chromium.org>
> > > <mailto:blink-dev+...@chromium.org <mailto:blink-dev%2Bunsu...@chromium.org>>.
>
> > > To view this discussion on the web visit
> > >
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWw--PTD%2BPF3P0sKgkwe29_WcQ5Xyi6jakoZn0EeDx0XQ%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWw--PTD%2BPF3P0sKgkwe29_WcQ5Xyi6jakoZn0EeDx0XQ%40mail.gmail.com>
>
> >
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWw--PTD%2BPF3P0sKgkwe29_WcQ5Xyi6jakoZn0EeDx0XQ%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWw--PTD%2BPF3P0sKgkwe29_WcQ5Xyi6jakoZn0EeDx0XQ%40mail.gmail.com>>
>
> > >
> >
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWw--PTD%2BPF3P0sKgkwe29_WcQ5Xyi6jakoZn0EeDx0XQ%40mail.gmail.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWw--PTD%2BPF3P0sKgkwe29_WcQ5Xyi6jakoZn0EeDx0XQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>
> >
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWw--PTD%2BPF3P0sKgkwe29_WcQ5Xyi6jakoZn0EeDx0XQ%40mail.gmail.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWw--PTD%2BPF3P0sKgkwe29_WcQ5Xyi6jakoZn0EeDx0XQ%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.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/95e09311-b9b5-42ea-9a98-4b1e3160936bn%40chromium.org

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/95e09311-b9b5-42ea-9a98-4b1e3160936bn%40chromium.org?utm_medium=email&utm_source=footer>.
>

Mario Bianucci

unread,

Jul 8, 2021, 12:00:23 PM7/8/21

to blink-dev, yoav...@chromium.org, sligh...@chromium.org, blink-dev, Mario Bianucci, Olli Pettay, Olga Gerchikov, mk...@chromium.org

Thanks for the LGTMs so far!

Regarding issue #20, 'type' currently is a "no-op", but it is intended to enable extensibility in the future. While there isn't a firm proposal or explainer for anything right now, it is easy to imagine a scenario where it could be extended to support ink trails rendered via shaders, rather than just a solid color stroke. Then we could support something like 'shader-trail' alongside the 'delegated-ink-trail' type that this feature uses. This is actually something that an partner has asked about already.

Its possible that this is the wrong model for extensibility and I'm happy to revisit it if you think so, but I think have some plan for it to be easily extended is reasonable.

For #22, after a bit more thought, I don't anticipate that we would need to change how it works today. It seems like it would be very unusual for an author to need any of the Ink instance, presentationArea, or PointerEvent to be in different documents, I can't imagine what it would look like from a user perspective. And if we did decide to expand the spec to support that scenario, I don't expect that it would require too much of a change from the current form of the spec.

I've updated the spec to clarify the issues that Olli brought up other than #20 now. I'll update it again if necessary once we all agree on a resolution for the 'type' issue.

Ken Russell

unread,

Jul 8, 2021, 8:54:34 PM7/8/21

to Mario Bianucci, blink-dev, yoav...@chromium.org, sligh...@chromium.org, Mario Bianucci, Olli Pettay, Olga Gerchikov, mk...@chromium.org

On Thu, Jul 8, 2021 at 9:00 AM Mario Bianucci <bian...@gmail.com> wrote:

Thanks for the LGTMs so far!

Regarding issue #20, 'type' currently is a "no-op", but it is intended to enable extensibility in the future. While there isn't a firm proposal or explainer for anything right now, it is easy to imagine a scenario where it could be extended to support ink trails rendered via shaders, rather than just a solid color stroke. Then we could support something like 'shader-trail' alongside the 'delegated-ink-trail' type that this feature uses. This is actually something that an partner has asked about already.

What's the current thought about how these shaders would be provided to the browser?

Would you aim to reuse one of the current GPU-accelerated web APIs' (WebGL, WebGPU) shading languages for this purpose?

Thanks,

-Ken

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/dacc3350-0240-4ee0-a708-154601f225acn%40chromium.org.

Mario Bianucci

unread,

Jul 14, 2021, 1:36:33 PM7/14/21

to blink-dev, Kenneth Russell, blink-dev, yoav...@chromium.org, sligh...@chromium.org, Mario Bianucci, Olli Pettay, Olga Gerchikov, mk...@chromium.org, Mario Bianucci

I asked for TAG's opinion on this and haven't heard anything yet. However, since it seems like the general consensus is that it should just be a dictionary param, I've updated the draft spec to reflect that and am now working on a CL to update the API in Chromium to match this new form.

On Thursday, July 8, 2021 at 8:54:34 PM UTC-4 Kenneth Russell wrote:

On Thu, Jul 8, 2021 at 9:00 AM Mario Bianucci <bian...@gmail.com> wrote:
Thanks for the LGTMs so far!

Regarding issue #20, 'type' currently is a "no-op", but it is intended to enable extensibility in the future. While there isn't a firm proposal or explainer for anything right now, it is easy to imagine a scenario where it could be extended to support ink trails rendered via shaders, rather than just a solid color stroke. Then we could support something like 'shader-trail' alongside the 'delegated-ink-trail' type that this feature uses. This is actually something that an partner has asked about already.

What's the current thought about how these shaders would be provided to the browser?

Would you aim to reuse one of the current GPU-accelerated web APIs' (WebGL, WebGPU) shading languages for this purpose?

Thanks,

-Ken

I haven't explored what exactly this potential extension would look like, but I think its likely that we would reuse existing languages to make it simpler for site authors.

Yoav Weiss

unread,

Jul 15, 2021, 4:41:15 AM7/15/21

to blink-dev, Mario Bianucci, Kenneth Russell, blink-dev, Yoav Weiss, Alex Russell, Olli Pettay, Olga Gerchikov, Mike West, Mario Bianucci

Thanks for addressing the feedback.

LGTM1

Mike West

unread,

Jul 15, 2021, 4:46:27 AM7/15/21

to Yoav Weiss, blink-dev, Mario Bianucci, Kenneth Russell, Alex Russell, Olli Pettay, Olga Gerchikov, Mario Bianucci

(LGTM3, I think?)

-mike

Yoav Weiss

unread,

Jul 15, 2021, 5:52:20 AM7/15/21

to Mike West, blink-dev, Mario Bianucci, Kenneth Russell, Alex Russell, Olli Pettay, Olga Gerchikov, Mario Bianucci

Definitely LGTM3. Apologies

Reply all

Reply to author

Forward