[blink-dev] Intent to Implement and Ship: Http cookie prefix

Contact emailsyoavwe...@chromium.org Explainer This will add the cookie name prefix `__Http-`. Cookies that would start with that prefix would only be able to be set using the `Set-Cookie` HTTP header and will have to have an `httpOnly` attribute. Adding that prefix to the cookie name will give s

[blink-dev] Intent to Implement and Ship: ReadableStreamBYOBReader Min Option

Contact emails snehagar...@microsoft.com, stev...@microsoft.com Explainer None Specification https://streams.spec.whatwg.org/#byob-reader-read Summary This feature introduces a min option to the existing ReadableStreamBYOBReader.

Re: [blink-dev] Intent to Implement and Ship: Integrity Policy for scripts

To close the loop, the feature is now enabled (and aiming for M138). I also have a SW usecounter CL going. On Friday, May 2, 2025 at 11:24:58 PM UTC+2 Chris H

Re: [blink-dev] Intent to Implement and Ship: Integrity Policy for scripts

If you want to skip support for workers in this intent, that sounds fine to me. On Wed, Apr 30, 2025 at 4:32 AM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote: > Thanks for the LGTMs!! > > The code for this didn't make the 137 branch, so I'm now aiming for M138. > > The PR discussions rais

Re: [blink-dev] Intent to Implement and Ship: Integrity Policy for scripts

Thanks for the LGTMs!! The code for this didn't make the 137 branch, so I'm now aiming for M138. The PR discussions raised one salient question regarding worker support . That ended up convincing me that for c

Re: [blink-dev] Intent to Implement and Ship: Integrity Policy for scripts

LGTM3 On Wednesday, April 23, 2025 at 8:34:55 AM UTC-7 Chris Harrelson wrote: > LGTM2, assuming the spec lands before the feature ships. > > On Wed, Apr 23, 2025 at 4:07 AM Mike Taylor wrote: > >> LGTM1 >> On 4/23/25 5:12 AM, Yoav Weiss (@Shopify) wrote: >> >> Contact emails yoav...@chromium.org

Re: [blink-dev] Intent to Implement and Ship: Integrity Policy for scripts

LGTM2, assuming the spec lands before the feature ships. On Wed, Apr 23, 2025 at 4:07 AM Mike Taylor wrote: > LGTM1 > On 4/23/25 5:12 AM, Yoav Weiss (@Shopify) wrote: > > Contact emails yoavwe...@chromium.org > > Explainer https://github.com/w3c/webappsec-subresource-integrity/pull/133 > > Speci

Re: [blink-dev] Intent to Implement and Ship: Integrity Policy for scripts

LGTM1 On 4/23/25 5:12 AM, Yoav Weiss (@Shopify) wrote: Contact emails yoavwe...@chromium.org Explainer https://github.com/w3c/webappsec-subresource-integrity/pull/133 Specification https://github.com/w3c/webappsec-subresource-integrity/pull/133 Summary

[blink-dev] Intent to Implement and Ship: Integrity Policy for scripts

Contact emailsyoavwe...@chromium.org Explainerhttps://github.com/w3c/webappsec-subresource-integrity/pull/133 Specificationhttps://github.com/w3c/webappsec-subresource-integrity/pull/133 Summary Subresource-Integrity (SRI) enables developers to make sure the assets they intend to load are indee

[blink-dev] Intent to implement and ship: Support offset-path: shape()

Contact emailsnrosent...@chromium.org ExplainerNone Specificationhttps://drafts.csswg.org/css-shapes-2/#shape-function Summary The shape() function is already supported in clip-path, and allows responsive clipping. Enabling it also for offset-path will close a small gap where the same kind of s

Re: [blink-dev] Intent to Implement and Ship: PushMessageData::bytes()

LGTM3 /Daniel On 2024-10-22 04:02, Domenic Denicola wrote: LGTM2 On Tue, Oct 22, 2024 at 7:03 AM Alex Russell wrote: LGTM1 On Mon, Oct 21, 2024, 6:16 AM Peter Beverloo wrote: Contact emails pe...@chromium.org Explainer htt

Re: [blink-dev] Intent to Implement and Ship: PushMessageData::bytes()

LGTM2 On Tue, Oct 22, 2024 at 7:03 AM Alex Russell wrote: > LGTM1 > > On Mon, Oct 21, 2024, 6:16 AM Peter Beverloo wrote: > >> Contact emailspe...@chromium.org >> >> Explainerhttps://github.com/w3c/push-api/pull/370 >> >> Specificationhttps://www.w3.org/TR/push-api/#dom-pushmessagedata-bytes >>

Re: [blink-dev] Intent to Implement and Ship: PushMessageData::bytes()

LGTM1 On Mon, Oct 21, 2024, 6:16 AM Peter Beverloo wrote: > Contact emailspe...@chromium.org > > Explainerhttps://github.com/w3c/push-api/pull/370 > > Specificationhttps://www.w3.org/TR/push-api/#dom-pushmessagedata-bytes > > Summary > > The PushMessageData interface mimics the Body interface, w

[blink-dev] Intent to Implement and Ship: PushMessageData::bytes()

Contact emailspe...@chromium.org Explainerhttps://github.com/w3c/push-api/pull/370 Specificationhttps://www.w3.org/TR/push-api/#dom-pushmessagedata-bytes Summary The PushMessageData interface mimics the Body interface, which was amended earlier this year with a new bytes() method, following the

Re: [blink-dev] Intent to Implement and Ship: aria-rowindextext and aria-colindextext

LGTM3 On Tuesday, June 18, 2024 at 7:24:00 AM UTC-7 Yoav Weiss wrote: > LGTM2 > > On Mon, Jun 17, 2024 at 10:05 PM Vladimir Levin > wrote: > >> LGTM1, thanks >> >> On Wed, Jun 12, 2024 at 2:35 PM 'Daniel Clark' via blink-dev < >> blink-dev@chromium.org> wrote: >> >>> *Contact emails* >>> >>> da

Re: [blink-dev] Intent to Implement and Ship: aria-rowindextext and aria-colindextext

LGTM2 On Mon, Jun 17, 2024 at 10:05 PM Vladimir Levin wrote: > LGTM1, thanks > > On Wed, Jun 12, 2024 at 2:35 PM 'Daniel Clark' via blink-dev < > blink-dev@chromium.org> wrote: > >> *Contact emails* >> >> dan...@microsoft.com >> >> >> >> *Explainer* >> >> No formal explainer but https://github.c

Re: [blink-dev] Intent to Implement and Ship: aria-rowindextext and aria-colindextext

LGTM1, thanks On Wed, Jun 12, 2024 at 2:35 PM 'Daniel Clark' via blink-dev < blink-dev@chromium.org> wrote: > *Contact emails* > > dan...@microsoft.com > > > > *Explainer* > > No formal explainer but https://github.com/w3c/aria/issues/667 discusses > use cases and alternatives. > > > > *Specifica

[blink-dev] Intent to Implement and Ship: aria-rowindextext and aria-colindextext

Contact emails dan...@microsoft.com Explainer No formal explainer but https://github.com/w3c/aria/issues/667 discusses use cases and alternatives. Specification https://w3c.github.io/aria/#aria-colindextext, https://w3c.github.io/aria/#aria-rowindextext Su

Re: [blink-dev] Intent to Implement and Ship: Line-breakable ruby

I see, is it because the exact behavior of text-wrap:balance and text-wrap:pretty are up to implementations? Since this is likely to remain the case indefinitely I think calling the test tentative isn't quite right, I'm not sure if the spec say "may" or "optional", but in spirit I think optional

Re: [blink-dev] Intent to Implement and Ship: Line-breakable ruby

LGTM3. It might be worth manually testing popular Japanese sites that use ruby to make sure this doesn't cause issues. But, I think it would be hard for sites to depend on specific line breaking behavior in a way that could cause breakage. On Tue, Jun 4, 2024 at 3:53 PM Daniel Bratell wrote: >

Re: [blink-dev] Intent to Implement and Ship: Line-breakable ruby

LGTM2 /Daniel On 2024-06-04 04:16, TAMURA, Kent wrote: The test "text-wrap.tentative.html" is tentative because of text-wrap:balance and text-wrap:pretty.  I'll do: - File a spec issue for them, and - Make a non-tetative test for text-wrap:nowrap. On Mon, Jun 3, 2024 at 5:57 PM Philip Jägens

Re: [blink-dev] Intent to Implement and Ship: Line-breakable ruby

Sure. I'll make a DumpAccessibilityTreeTest with a line-broken . On Mon, Jun 3, 2024 at 11:00 PM Aaron Leventhal wrote: > We do some interesting reorganization of ruby content in the a11y tree. > Can we create some DumpAccessibilityTreeTest tests for this and I'll take > a look at the a11y tree

Re: [blink-dev] Intent to Implement and Ship: Line-breakable ruby

The test "text-wrap.tentative.html" is tentative because of text-wrap:balance and text-wrap:pretty. I'll do: - File a spec issue for them, and - Make a non-tetative test for text-wrap:nowrap. On Mon, Jun 3, 2024 at 5:57 PM Philip Jägenstedt wrote: > LGTM1 > > This is a change of default behavi

Re: [blink-dev] Intent to Implement and Ship: Line-breakable ruby

We do some interesting reorganization of ruby content in the a11y tree. Can we create some DumpAccessibilityTreeTest tests for this and I'll take a look at the a11y tree and make sure it's sensible. On Fri, May 31, 2024 at 4:49 AM TAMURA, Kent wrote: > Contact emailstk...@chromium.org > > Explai

Re: [blink-dev] Intent to Implement and Ship: Line-breakable ruby

LGTM1 This is a change of default behavior, but the previous behavior is likely very rare and it can be achieved using `text-wrap: nowrap`. Since the text-wrap part is important for adoption of this, can you check if text-wrap.tentative.html still needs to be tentative? The test has a comment abo

[blink-dev] Intent to Implement and Ship: Line-breakable ruby

Contact emailstk...@chromium.org Explainer https://docs.google.com/document/d/1hzvrwoE_0aw08X_CaU40zV5bXbMQjY2SHQHj3Np4sDo/edit?pli=1#heading=h.acpilydj9j1d Specificationhttps://drafts.csswg.org/css-ruby/#break-within Design docs https://docs.google.com/document/d/1hzvrwoE_0aw08X_CaU40zV5bXbMQjY

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

LGTM3 On Wed, May 15, 2024 at 6:02 PM Daniel Bratell wrote: > LGTM2 > > /Daniel > On 2024-05-15 07:13, Domenic Denicola wrote: > > LGTM1. > > I have a small non-blocking request: update your Chrome Status entry to > avoid using ClassName.staticMethod() syntax for what appears to be an > instance

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

LGTM2 /Daniel On 2024-05-15 07:13, Domenic Denicola wrote: LGTM1. I have a small non-blocking request: update your Chrome Status entry to avoid using ClassName.staticMethod() syntax for what appears to be an instance method. (See e.g. this related discussion

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

LGTM1. I have a small non-blocking request: update your Chrome Status entry to avoid using ClassName.staticMethod() syntax for what appears to be an instance method. (See e.g. this related discussion and this bug I filed on Chrome Status a year ago

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

By reading an MDN article that I'll update after the launch. Even now allocationSize() is supposed to be called before copyTo() anyway, to figure out the size of the buffer for the output. (see example 1, example2

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

Ergonomics-wise, it does not seem intuitive to use a method called allocationSize() to feature detect copyTo support, even if the semantics are the same. Besides a very careful reading of the spec, how do we expect developers to know about it? On 5/14/24 4:32 PM, Eugene Zemtsov wrote: In that

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

In that discussion Marcos Cáceres asked for a synchronous way to detect if format conversion is supported. We have a synchronous call allocationSize() that throws an unsupported error in cases where format conversion is not supported.

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

I see that WebKit raised an API concern around detectability . In your reply, you said "we should consider...". Has that consideration happened, perhaps as follow-up work? :) On 5/8/24 4:05 PM, Eugene Zemtsov wro

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

This feature has Privacy, Security, Enterprise, and Debuggability approvals. Webkit gave a positive signal. Any objections or questions from the API owners? On Wed, May 1, 2024 at 4:26 PM Eugene Zemtsov wrote: > I've filed issues for TAG review and firefox and webkit positions. > > > Have yo

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

I've filed issues for TAG review and firefox and webkit positions. > Have you looked into other platform APIs that could benefit from being able to explicitly specify intermediate format hinting and/or transformation? I don't think this kind of review can be done for all web APIs by one person. I

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

+1. Would you mind also filing gecko and webkit positions? I expect them to be positive, given the informal signals you have in the spec PRs already - but this also lets them know we're moving ahead with shipping. Thanks - Mike On 5/1/24 11:51 AM, Alex Russell wrote: hey Eugene, This is an e

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

hey Eugene, This is an exciting an useful addition! Have you looked into other platform APIs that could benefit from being able to explicitly specify intermediate format hinting and/or transformation? It's a place where (had the TAG been consulted) I would have expected to see a larger chain of

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

> Can you please request reviews for privacy, security, enterprise, etc in the chromestatus entry? Done On Mon, Apr 29, 2024 at 7:44 AM Mike Taylor wrote: > Can you please request reviews for privacy, security, enterprise, etc in > the chromestatus entry? > On 4/25/24 6:19 PM, 'Eugene Zemtsov'

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

Can you please request reviews for privacy, security, enterprise, etc in the chromestatus entry? On 4/25/24 6:19 PM, 'Eugene Zemtsov' via blink-dev wrote: Contact emails ezemt...@google.com Explainer https://gist.github.com/Djuffin/9e2f98025ead49998524510cfeed8d33

[blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

Contact emailsezemt...@google.com Explainerhttps://gist.github.com/Djuffin/9e2f98025ead49998524510cfeed8d33 Specificationhttps://www.w3.org/TR/webcodecs/#dom-videoframe-copyto Summary VideoFrame.copyTo() can convert pixel data to RGB pixel format Converting YUV video frames to RGB is often requ

[blink-dev] Intent to Implement and Ship: OpusEncoderConfig `signal` and `application` parameters

Contact emailstguilb...@chromium.org ExplainerNone Specification https://w3c.github.io/webcodecs/opus_codec_registration.html#dom-opusencoderconfig-signal Summary `OpusEncoderConfig.signal` and `OpusEncoderConfig.application` were recently added to the WebCodecs spec [1]. Both parameters are ma

Re: [blink-dev] Intent to implement and ship: WebAuthn WebDriver backup flags settings

LGTM3 On Tue, Feb 20, 2024 at 1:03 PM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote: > LGTM2 > > On Tue, Feb 20, 2024 at 8:50 PM Rick Byers wrote: > >> Looks pretty straightforward to me and has some good support from other >> engines. LGTM1 >> >> /cc @Mathias Bynens in case he has any

Re: [blink-dev] Intent to implement and ship: WebAuthn WebDriver backup flags settings

LGTM2 On Tue, Feb 20, 2024 at 8:50 PM Rick Byers wrote: > Looks pretty straightforward to me and has some good support from other > engines. LGTM1 > > /cc @Mathias Bynens in case he has any thoughts from a > WebDriver perspective > > > On Wed, Feb 14, 2024 at 6:21 PM Nina Satragno > wrote: > >

Re: [blink-dev] Intent to implement and ship: WebAuthn WebDriver backup flags settings

Looks pretty straightforward to me and has some good support from other engines. LGTM1 /cc @Mathias Bynens in case he has any thoughts from a WebDriver perspective On Wed, Feb 14, 2024 at 6:21 PM Nina Satragno wrote: > Contact emails > > nsatra...@chromium.org, chrome-webau...@google.com > >

[blink-dev] Intent to implement and ship: WebAuthn WebDriver backup flags settings

Contact emails nsatra...@chromium.org, chrome-webau...@google.com Specification https://w3c.github.io/webauthn/#sctn-automation, look for backupState and backupEligibility Or, if you prefer, see the merged PR . Summary A set of new attributes for We

Re: [blink-dev] Intent to implement and ship: blocking=render on inline scripts

On 2024-01-10 18:27, Noam Rosenthal wrote: On Wed, Jan 10, 2024 at 5:25 PM Michal Mocny wrote: On Wed, Jan 10, 2024 at 10:55 AM Noam Rosenthal wrote: Great, perhaps the best way forward is with a flag that's starting as "stable" from the get go and we can later r

Re: [blink-dev] Intent to implement and ship: blocking=render on inline scripts

On Wed, Jan 10, 2024 at 5:25 PM Michal Mocny wrote: > > > On Wed, Jan 10, 2024 at 10:55 AM Noam Rosenthal > wrote: > >> >> >> On Wed, Jan 10, 2024 at 3:47 PM Rick Byers wrote: >> >>> Thanks Noam, LGTM2 >>> >>> Q: Since this is a trivial fix, does it need to be behind a flag? Either way is

Re: [blink-dev] Intent to implement and ship: blocking=render on inline scripts

On Wed, Jan 10, 2024 at 10:55 AM Noam Rosenthal wrote: > > > On Wed, Jan 10, 2024 at 3:47 PM Rick Byers wrote: > >> Thanks Noam, LGTM2 >> >> Q: Since this is a trivial fix, does it need to be behind a flag? Either >>> way is fine with me. The current CL has it behind a new flag. >> >> >> I guess

Re: [blink-dev] Intent to implement and ship: Allow elements with CSS display:contents to be focusable

I think such a console error sounds like a reasonable idea, but I'd need to dig in to see how hard it would be to do. -David On Tue, Jan 9, 2024 at 2:59 PM Aaron Leventhal wrote: > WDYT about a console error in developer tools when there is no focus rule > applied? > > On Tue, Jan 9, 2024 at 2:

Re: [blink-dev] Intent to implement and ship: blocking=render on inline scripts

LGTM3 On Wednesday, January 10, 2024 at 4:47:46 PM UTC+1 Rick Byers wrote: > Thanks Noam, LGTM2 > > Q: Since this is a trivial fix, does it need to be behind a flag? Either >> way is fine with me. The current CL has it behind a new flag. > > > I guess technically it's a new platform API so our g

Re: [blink-dev] Intent to implement and ship: blocking=render on inline scripts

On Wed, Jan 10, 2024 at 3:47 PM Rick Byers wrote: > Thanks Noam, LGTM2 > > Q: Since this is a trivial fix, does it need to be behind a flag? Either >> way is fine with me. The current CL has it behind a new flag. > > > I guess technically it's a new platform API so our guidelines >

Re: [blink-dev] Intent to implement and ship: blocking=render on inline scripts

Thanks Noam, LGTM2 Q: Since this is a trivial fix, does it need to be behind a flag? Either > way is fine with me. The current CL has it behind a new flag. I guess technically it's a new platform API so our guidelines

Re: [blink-dev] Intent to implement and ship: blocking=render on inline scripts

LGTM1 - I agree that this is small enough to just proceed. /Daniel On 2024-01-10 16:40, Noam Rosenthal wrote: On Wed, Jan 10, 2024 at 3:32 PM Rick Byers wrote: Hi Noam, This seems pretty trivial to me. The spec change is trivial and presumably any review feedback will only be ed

Re: [blink-dev] Intent to implement and ship: blocking=render on inline scripts

Q: Since this is a trivial fix, does it need to be behind a flag? Either way is fine with me. The current CL has it behind a new flag. On Wed, Jan 10, 2024 at 3:40 PM Noam Rosenthal wrote: > > > On Wed, Jan 10, 2024 at 3:32 PM Rick Byers wrote: > >> Hi Noam, >> This seems pretty trivial to me.

Re: [blink-dev] Intent to implement and ship: blocking=render on inline scripts

On Wed, Jan 10, 2024 at 3:32 PM Rick Byers wrote: > Hi Noam, > This seems pretty trivial to me. The spec change is trivial and presumably > any review feedback will only be editorial (not functional), so I'm OK not > blocking approval on the spec PR landing. But could you get a WPTs > implemented

Re: [blink-dev] Intent to implement and ship: blocking=render on inline scripts

Hi Noam, This seems pretty trivial to me. The spec change is trivial and presumably any review feedback will only be editorial (not functional), so I'm OK not blocking approval on the spec PR landing. But could you get a WPTs implemented and at least ready to land (eg. along with the implementation

Re: [blink-dev] Intent to implement and ship: Allow elements with CSS display:contents to be focusable

WDYT about a console error in developer tools when there is no focus rule applied? On Tue, Jan 9, 2024 at 2:56 PM David Baron wrote: > I think in theory it might make sense for focus outlines to use something > like an aggregation of child bounds. (The specifications even allow focus > outlines

Re: [blink-dev] Intent to implement and ship: Allow elements with CSS display:contents to be focusable

I think in theory it might make sense for focus outlines to use something like an aggregation of child bounds. (The specifications even allow focus outlines on regular elements to expand to contain the bounds of children.) However, in the case of display:contents, it would be hard to implement in

Re: [blink-dev] Intent to implement and ship: Allow elements with CSS display:contents to be focusable

Would an option for focus outlines to be to use the same idea we're discussing for AT bounding boxes? Namely, to use an aggregation of child outlines? On Tue, Jan 9, 2024 at 12:33 PM David Baron wrote: > I think accumulating the rectangles of children seems like a good option > if we need to rep

Re: [blink-dev] Intent to implement and ship: Allow elements with CSS display:contents to be focusable

I think accumulating the rectangles of children seems like a good option if we need to report a bounding box. It sounds like that's something else where I need to test, and possibly change, our current behavior for elements with display:contents. Regarding focus outlines: these elements won't dr

Re: [blink-dev] Intent to implement and ship: Allow elements with CSS display:contents to be focusable

And (duh to myself), we need to compute a bounding box for our own focus outline. Apologies if this is answered elsewhere. On Tue, Jan 9, 2024 at 11:45 AM Aaron Leventhal wrote: > Interesting. How will the bounding box be reported via a11y APIs? > > Examples of where this is used: > 1. ATs for

Re: [blink-dev] Intent to implement and ship: Allow elements with CSS display:contents to be focusable

Interesting. How will the bounding box be reported via a11y APIs? Examples of where this is used: 1. ATs for low vision users that draw a box around the focus and/or move the focus onscreen (especially for a magnifier that is only showing part of the actual screen's contents in a virtual viewport)

[blink-dev] Intent to implement and ship: blocking=render on inline scripts

Contact emailsnrosent...@chromium.org ExplainerNone (this is a small change to an existing feature) Specificationhttps://github.com/whatwg/html/pull/10035 Summary Currently

Re: [blink-dev] Intent to Implement and Ship: VideoEncoderConfig.contentHint

LGTM3 On 11/27/23 10:50 PM, Yoav Weiss wrote: LGTM2 On Tue, Nov 28, 2023 at 7:50 AM Rick Byers wrote: All the other gates are now approved. I see there's a larger TAG review open which includes this feature, but it sounds like

Re: [blink-dev] Intent to Implement and Ship: VideoEncoderConfig.contentHint

LGTM2 On Tue, Nov 28, 2023 at 7:50 AM Rick Byers wrote: > All the other gates are now approved. I see there's a larger TAG review > open which includes > this feature, but it sounds like this generic (not codec-specific) feature > is the dire

Re: [blink-dev] Intent to Implement and Ship: VideoEncoderConfig.contentHint

All the other gates are now approved. I see there's a larger TAG review open which includes this feature, but it sounds like this generic (not codec-specific) feature is the direction TAG is encouraging. I don't think we need to block this littl

[blink-dev] Intent to Implement and Ship: Async Clipboard API: Allow empty ClipboardItem during read

Contact emails sni...@microsoft.com, est...@chromium.org, sa...@microsoft.com, jsb...@google.com Explainer https://docs.google.com/document/d/1OLVOESy3zecxY_6jMKdKVxeIGS2Q6mDmzc85rUNrRIE/edit?usp=sharing Specification https://w3c.github.io/clipboard-apis/#dom-clipboard-read Design docs https

Re: [blink-dev] Intent to Implement and Ship: VideoEncoderConfig.contentHint

They seem to be in state "preparing" which is the stage before they are actually requested. The system is a bit new so maybe there is some confusing UI or bug, but they are not yet requested. jrobbins, do you know what might have gone awry? /Daniel On 2023-11-08 05:04, 'Eugene Zemtsov' via bl

Re: [blink-dev] Intent to Implement and Ship: VideoEncoderConfig.contentHint

Done for Privacy, Security, Enterprise, Debuggability and Testing. On Mon, Nov 6, 2023 at 7:19 AM Mike Taylor wrote: > Hi Eugene, > > Could you please request reviews for all the other review gates in your > chromestatus entry? > > thanks, > Mike > On 11/1/23 6:32 PM, 'Eugene Zemtsov' via blink

Re: [blink-dev] Intent to Implement and Ship: VideoEncoderConfig.contentHint

Hi Eugene, Could you please request reviews for all the other review gates in your chromestatus entry? thanks, Mike On 11/1/23 6:32 PM, 'Eugene Zemtsov' via blink-dev wrote: Contact emails ezemt...@google.com Specification https://www.w3.org/TR/webcodecs/#dom-videoencod

[blink-dev] Intent to Implement and Ship: VideoEncoderConfig.contentHint

Contact emailsezemt...@google.com Specification https://www.w3.org/TR/webcodecs/#dom-videoencoderconfig-contenthint Explainerhttps://gist.github.com/Djuffin/c3742404b7c53ada227849c8b2b76b4c Summary Adding a contentHint field to VideoEncoderConfig Content hint takes values that are already used

Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature detection for supported clipboard formats

; -Anupam >>> >>> -- >>> *From:* Anupam Snigdha >>> *Sent:* Thursday, October 5, 2023 4:41 PM >>> *To:* Yoav Weiss ; blink-dev < >>> blink-dev@chromium.org> >>> *Cc:* Sangwhan Moon ; Sanket Joshi (EDGE) < &g

Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature detection for supported clipboard formats

eiss ; blink-dev < >> blink-dev@chromium.org> >> *Cc:* Sangwhan Moon ; Sanket Joshi (EDGE) < >> sa...@microsoft.com>; Evan Stade ; jsb...@google.com >> ; Chris Harrelson >> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: >&

Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature detection for supported clipboard formats

ink-dev@chromium.org> > *Cc:* Sangwhan Moon ; Sanket Joshi (EDGE) < > sa...@microsoft.com>; Evan Stade ; jsb...@google.com > ; Chris Harrelson > *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: > Feature detection for supported clipboard formats > >

Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature detection for supported clipboard formats

Anupam From: Anupam Snigdha Sent: Thursday, October 5, 2023 4:41 PM To: Yoav Weiss ; blink-dev Cc: Sangwhan Moon ; Sanket Joshi (EDGE) ; Evan Stade ; jsb...@google.com ; Chris Harrelson Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature detection for sup

Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature detection for supported clipboard formats

: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature detection for supported clipboard formats Thanks for working on this! This seems like a welcome addition, and the example code of the current status quo is definitely something we need to solve! On Wednesday, September 20, 2023

[blink-dev] Intent to Implement and Ship: Async Clipboard API: Read unsanitized HTML and write well-formed HTML format.

Contact emails sni...@microsoft.com, sa...@microsoft.com, est...@chromium.org, jsb...@chromium.org, asu...@chromium.org, ansol...@microsoft.com

Re: [blink-dev] Intent to implement and ship: Media query support for video elements

LGTM3 On Thursday, October 5, 2023 at 1:36:25 PM UTC-7 Scott Jehl wrote: > Thanks!! > > On Thursday, 5 October 2023 at 16:14:19 UTC-4 Dale Curtis wrote: > >> Thanks! >> > >> On Thu, Oct 5, 2023 at 12:53 PM Yoav Weiss wrote: >> > LGTM1 >>> >>> Thanks for correcting this historical mistake! >>> >>

Re: [blink-dev] Intent to implement and ship: Media query support for video elements

Thanks!! On Thursday, 5 October 2023 at 16:14:19 UTC-4 Dale Curtis wrote: > Thanks! > > On Thu, Oct 5, 2023 at 12:53 PM Yoav Weiss wrote: > >> LGTM1 >> >> Thanks for correcting this historical mistake! >> >> On Thu, Oct 5, 2023, 21:11 Dale Curtis wrote: >> >>> Contact emailsdalec...@chromium.or

Re: [blink-dev] Intent to implement and ship: Media query support for video elements

Thanks! On Thu, Oct 5, 2023 at 12:53 PM Yoav Weiss wrote: > LGTM1 > > Thanks for correcting this historical mistake! > > On Thu, Oct 5, 2023, 21:11 Dale Curtis wrote: > >> Contact emailsdalecur...@chromium.org >> >> ExplainerNone >> > > We could almost use MDN as the explainer, other than my co

Re: [blink-dev] Intent to implement and ship: Media query support for video elements

LGTM2 On Thu, Oct 5, 2023 at 12:53 PM Yoav Weiss wrote: > LGTM1 > > Thanks for correcting this historical mistake! > > On Thu, Oct 5, 2023, 21:11 Dale Curtis wrote: > >> Contact emailsdalecur...@chromium.org >> >> ExplainerNone >> > > We could almost use MDN as the explainer, other than my comm

Re: [blink-dev] Intent to implement and ship: Media query support for video elements

LGTM1 Thanks for correcting this historical mistake! On Thu, Oct 5, 2023, 21:11 Dale Curtis wrote: > Contact emailsdalecur...@chromium.org > > ExplainerNone > We could almost use MDN as the explainer, other than my comment below. > > Specification > https://html.spec.whatwg.org/multipage/med

[blink-dev] Intent to implement and ship: Media query support for video elements

Contact emailsdalecur...@chromium.org ExplainerNone Specification https://html.spec.whatwg.org/multipage/media.html#loading-the-media-resource Design docs https://developer.mozilla.org/en-US/docs/Web/HTML/Element/source#media Summary Adds support for CSS media queries to elements used with e

Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature detection for supported clipboard formats

tainly do it if it's required. Please let me know. -Anupam -- *From:* Sangwhan Moon *Sent:* Monday, September 18, 2023 11:10 PM *To:* Anupam Snigdha *Cc:* blink-dev@chromium.org ; Sanket Joshi (EDGE) < sa...@microsoft.com>; Evan Stade ; jsb...@google.com < jsb...@goog

Re: [blink-dev] Intent to Implement and Ship: CaptureStartFocusBehavior enum value "focus-capturing-application"

LGTM3 We also briefly reviewed the other review categories (privacy, security, etc) and deemed them unlikely to create an issue in this case. On Wed, Sep 27, 2023 at 7:58 AM Daniel Bratell wrote: > LGTM2 > > /Daniel > On 2023-09-26 11:28, 'François Beaufort' via blink-dev wrote: > > I'm happy t

Re: [blink-dev] Intent to Implement and Ship: CaptureStartFocusBehavior enum value "focus-capturing-application"

LGTM2 /Daniel On 2023-09-26 11:28, 'François Beaufort' via blink-dev wrote: I'm happy to answer the remaining questions if any. On Wed, Sep 20, 2023 at 7:13 PM Yoav Weiss wrote: LGTM1 On Wed, Sep 20, 2023 at 5:45 PM François Beaufort wrote: On Wed, Sep 20, 2023 at 5:

Re: [blink-dev] Intent to Implement and Ship: CaptureStartFocusBehavior enum value "focus-capturing-application"

I'm happy to answer the remaining questions if any. On Wed, Sep 20, 2023 at 7:13 PM Yoav Weiss wrote: > LGTM1 > > On Wed, Sep 20, 2023 at 5:45 PM François Beaufort > wrote: > >> >> >> On Wed, Sep 20, 2023 at 5:26 PM Yoav Weiss >> wrote: >> >>> >>> >>> On Tue, Sep 19, 2023 at 12:49 PM 'François

Re: [blink-dev] Intent to Implement and Ship: CaptureStartFocusBehavior enum value "focus-capturing-application"

LGTM1 On Wed, Sep 20, 2023 at 5:45 PM François Beaufort wrote: > > > On Wed, Sep 20, 2023 at 5:26 PM Yoav Weiss wrote: > >> >> >> On Tue, Sep 19, 2023 at 12:49 PM 'François Beaufort' via blink-dev < >> blink-dev@chromium.org> wrote: >> >>> Contact emails >>> >>> fbeauf...@google.com >>> >>> ela

Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature detection for supported clipboard formats

From: Chris Harrelson Sent: Wednesday, September 20, 2023 8:58 AM To: Anupam Snigdha Cc: Sangwhan Moon ; blink-dev@chromium.org ; Sanket Joshi (EDGE) ; Evan Stade ; jsb...@google.com Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature

Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature detection for supported clipboard formats

--- > *From:* Sangwhan Moon > *Sent:* Monday, September 18, 2023 11:10 PM > *To:* Anupam Snigdha > *Cc:* blink-dev@chromium.org ; Sanket Joshi > (EDGE) ; Evan Stade ; > jsb...@google.com > *Subject:* [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: &g

Re: [blink-dev] Intent to Implement and Ship: CaptureStartFocusBehavior enum value "focus-capturing-application"

On Wed, Sep 20, 2023 at 5:26 PM Yoav Weiss wrote: > > > On Tue, Sep 19, 2023 at 12:49 PM 'François Beaufort' via blink-dev < > blink-dev@chromium.org> wrote: > >> Contact emails >> >> fbeauf...@google.com >> >> elada...@google.com >> >> Explainer >> >> https://github.com/WICG/conditional-focus/bl

Re: [blink-dev] Intent to Implement and Ship: CaptureStartFocusBehavior enum value "focus-capturing-application"

On Tue, Sep 19, 2023 at 12:49 PM 'François Beaufort' via blink-dev < blink-dev@chromium.org> wrote: > Contact emails > > fbeauf...@google.com > > elada...@google.com > > Explainer > > https://github.com/WICG/conditional-focus/blob/main/README.md > > Specification > > > https://www.w3.org/TR/screen

Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature detection for supported clipboard formats

; Sanket Joshi (EDGE) ; Evan Stade ; jsb...@google.com Subject: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature detection for supported clipboard formats You don't often get email from s...@chromium.org. Learn why this is important<https://aka.ms/LearnAboutSenderIdenti

[blink-dev] Intent to Implement and Ship: CaptureStartFocusBehavior enum value "focus-capturing-application"

Contact emails fbeauf...@google.com elada...@google.com Explainer https://github.com/WICG/conditional-focus/blob/main/README.md Specification https://www.w3.org/TR/screen-capture/#idl-def-CaptureStartFocusBehavior.focus-capturing-application Summary The Screen Capture API lets the user sele

Re: [blink-dev] Intent to Implement and Ship: Feature detection for supported clipboard formats

Interesting problem, never thought about this ergonomic problem.On Sep 19, 2023, at 2:12, 'Anupam Snigdha' via blink-dev wrote: Contact emails sni...@microsoft.com, sa...@microsoft.com, est...@chromium.org, jsb...@chromium.org, asu...@chromium.org Explainer https://github.com/w3c/clipboa

[blink-dev] Intent to Implement and Ship: Feature detection for supported clipboard formats

Contact emails sni...@microsoft.com, sa...@microsoft.com, est...@chromium.org, jsb...@chromium.org, asu...@chromium.org Explainer https://github.com/w3c/

Re: [blink-dev] Intent to Implement and Ship: Per-frame quantizer in VideoEncoder

For the WEBRTC/MEDIA WG joint meeting at TPAC, Eugene has put together some slides and a demo of QP-based rate control: https://docs.google.com/presentation/d/1FpCAlxvRuC0e52JrthMkx-ILklB5eHszbk8D3FIuSZ0/edit#slide=id.g2397bc70323_0_17 As noted in the graph, "actual" rate remains close to the "d

[blink-dev] Intent to Implement and Ship: DisplayMediaStreamOptions monitorTypeSurfaces

Contact emails fbeauf...@google.com elada...@google.com Explainer https://github.com/eladalon1983/screen-share-explainers/blob/main/monitorTypeSurfaces_Explainer.md Specification https://w3c.github.io/mediacapture-screen-share/#dom-displaymediastreamoptions-monitortypesurfaces Summary When

Re: [blink-dev] Intent to Implement and Ship: SVGImageElement.crossOrigin attribute.

Thanks! Yes it has a base::Feature toggle; one is automatically included: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/runtime_enabled_features.json5;l=120;drc=86659902320c9a6ff1083688c928109df3d84f25 https://source.chromium.org/chromium/chromium/src

Re: [blink-dev] Intent to Implement and Ship: SVGImageElement.crossOrigin attribute.

LGTM3 On Wed, Aug 30, 2023 at 8:23 AM Daniel Bratell wrote: > LGTM2 > > /Daniel > On 2023-08-30 16:24, Yoav Weiss wrote: > > LGTM1 to ship, with a base flag to ensure we can rollback if needed. > > On Mon, Aug 28, 2023 at 6:16 PM Dale Curtis > wrote: > >> On Mon, Aug 21, 2023 at 9:41 AM Dale Cu

  1   2   3   4   >