Re: [blink-dev] Intent to Ship: MathML

[Frédéric Wang]

Thanks Chris. I'm attaching a testcase for contenteditable MathML. 
Indeed, the formula is properly rendered. It can also be edited and this 
will likely lead to "invalid" MathML markup (e.g. fraction ending up 
with only one child) but Firefox and WebKit don't perform integrity 
check either. And I guess it's fine, probably someone should really rely 
on JS to extend the native editor.


Morten was actually only mentioning the case when table is within a 
multicol so probably that excludes the Wikipedia use case (I'm going to 
do more checks there).


Printing would still be an issue.

So yeah, I personally don't think that should block shipping MathML but 
there are remaining issues with legacy layout that we need to be aware of.


On 23/06/2022 17:54, Chris Harrelson wrote:
EditingNG has already shipped. Only table fragmentation and printing 
are still to ship, and hopefully they will both be done by the end of 
the year.


On Thu, Jun 23, 2022 at 4:39 AM Frédéric Wang  wrote:

Hi Morten,

Thanks for raising this issue, I forgot to mention it. We
experimented
this in the past and IIRC we found issues with:

- Printing: indeed printing pages with math is likely to happen!
- Multicol: Wikipedia uses that for the "References" section at the
bottom of articles and some pages actually do use math inside!
- SVG: definitely needed for math in graphics. This is no longer an
issue now that foreignObject was implemented in LayoutNG.
- Editing: I'm not sure what's the status of EditingNG but I
believe we
wanted to disable editability on MathML anyway due to complexity for
editing math, which will require some tree fixup. This is better
handled
by other tools.

I don't remember what was the recent status, but we definitely
need to
check again. I believe we have crash tests in WPT and another to
check
correct layout for math-in-svg.

On 23/06/2022 13:06, Morten Stenshorne wrote:
> Exciting times!
>
> Since the layout implementation of MathML is pure NG (i.e. it has no
> legacy engine counterpart), you should be aware that this is
somewhat
> uncharted territory. We *do* have mechanisms that kick in when
we need
> to fall back to legacy layout (e.g. when printing, or when there are
> tables inside multicol), and have NG-only content inside (such as
> MathML), but no pure NG features have shipped yet, so we don't
really
> know how well this works on the world wild web.
>
> That said, we're also about to ship container queries, which has the
> same problem - so you're not alone. I was hoping that we'd be
rid of the
> legacy engine completely before we started shipping pure NG
features,
> because of this risk. I'm not saying that we definitely need to
wait for
> the legacy engine to be completely gone, but you need to be
aware of the
> risk, at least. Maybe clusterfuzz will find something
interesting once
> this feature is switched to "stable". :)
>
> By the way, I just tested, and MathML inside legacy layout
doesn't seem
> to work. I filed
> https://bugs.chromium.org/p/chromium/issues/detail?id=1338882
>
> Frédéric Wang  writes:
>
>> Contact emails
>>
>> fw...@chromium.org, rb...@chromium.org, bkard...@igalia.com
>>
>> Explainer
>>
>>
https://github.com/mathml-refresh/mathml-core/blob/master/docs/explainer.md
>> https://people.igalia.com/fwang/explainer-font-family-math
>>
>> Specification
>>
>> https://mathml-refresh.github.io/mathml-core
>>
>> Design docs
>>
>> https://drafts.csswg.org/css-fonts-4/#valdef-font-family-math
>> https://w3c.github.io/mathml-aam
>>

https://docs.google.com/document/d/1biGEaWN8ThNTDtAbT1M5GIf6N5uQLWdxh2QhrG9uN5c
>>

https://docs.google.com/document/d/1bvY_Npe2zLW_705KXdmecsH6P9I9wBMpHRsZ9CxWNOI/edit#heading=h.u9hwm9tp8nuy
>>
>> Summary
>>
>> Adds native DOM/IDL, accessibility support and CSS-compatible
OpenType-based layout of mathematical formulas. The reference
>> specifications are MathML Core (which describes in extensive
details a fundamental subset of the MathML 3 recommendation),
MathML AAM
>> (which describes mapping to platform accessibility APIs). This
includes the "math" font-family as well as features included in
section "CSS
>> Extensions for Math Layout".
>>
>> Blink component
>>
>> Blink
>>
>> Search tags
>>
>> mathml
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/438
https://github.com/w3ctag/design-reviews/issues/313#issuecomment-460523527
>>
>> TAG review status
>>
>> Issues addressed
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> - This is not implementing the complete list of MathML3,
OpenType MA

[blink-dev] Intent to Experiment: LazyEmbeds

[Minoru Chikamune]

Contact emails

chikam...@chromium.org, sisidov...@chromium.org

Explainer:

   -

   https://github.com/nyaxt/lazyembeds


Specification: https://github.com/nyaxt/lazyembeds

Summary: LazyEmbeds aims to improve LCP and power consumption by delaying
the iframe loads outside the viewport when all of the following conditions
are met.


   -

   The loading=eager or loading=lazy are not specified in the iframe tag.


   -

   The iframe's src URL matches a pre-curated list of 3rd party embeds that
   have opted-in to the experiment.


   -

   The page is visible.
   -

   The iframe's src URL must be cross origin.


LazyEmbeds doesn't load the offscreen iframes until the viewport comes near
the iframe. So the iframes that are eligible for LazyEmbeds might not be
loaded at all. Site authors can specify loading=eager on frames to opt-out
LazyEmbeds.

The current LazyEmbeds implementations target a 1% stable channel for data
gathering purposes. We don't release these LazyEmbeds as-is.

Blink component: Blink>Loader


TAG review

None

TAG review status

Not applicable

RisksInteroperability and Compatibility

The goal of the experiment is to test if the idea actually improves page
load UX. Once that is proven, we would like to start pitching in the
standardization forum on having the new behavior part of the spec.

We have a rough sketch of how it would look like in terms of specification
changes at https://github.com/nyaxt/lazyembeds. LazyEmbeds applies a
different loading schedule to offscreen cross-origin s. Site
authors who believe offscreen content is a critical part of the
user-experience may find this breaks their expectations. To restore the
previous behavior, authors can specify loading=eager on those frames.

Ergonomics

Websites don’t have to do anything.

Activation

LazyEmbeds works without any developer activation.

Security and privacy

LazyEmbeds doesn't have any security and privacy concerns.

Goals for experimentation

We would like to judge if this is a good idea or not before we would like
to validate our hypothesis using the performance data (e.g. Core Web Vitals
and battery power consumption) collected through the experiment before we
proceed to the next steps (open-ended discussion with other vendors,
involved 3rd-parties).

Experimental timeline

We’d like to start an experimental 1% rollout in M104.

Any risks when the experiment finishes?

No.

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

Yes.

Is this feature fully tested by web-platform-tests

?

No, through the experiment phase, but if the idea proves to be useful
through the experiment and makes it to the spec, we will add WPTs to cover
them.

Tracking bug

https://crbug.com/1247131

Launch bug

https://crbug.com/1247130

Links to previous Intent discussions

N/A

Link to entry on the feature dashboard 

Not yet.

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEy%2BVD%2B4e%2BvU6aiP9bEmfWc0SD%2B7%2Be8ngNe_bn7vUGSWco4u0A%40mail.gmail.com.

[blink-dev] PSA: --ignore-testharness-expected-txt for run_web_tests.py

[Xianzhu Wang]

Hi,

We have more than 2000 WPT tests that actually partially fail but pass
under run_web_tests.py because they have -expected.txt containing failing
results. Now run_web_tests.py has a new option
--ignore-testharness-expected-text to show these failures by ignoring these
-expected.txt. For now this is for local usage (i.e. not on bots), e.g. for
an owner of a WPT subdirectory to know which tests are failing and need
fixing.

In the future we will have a better mechanism to suppress testharness test
failures with better bug tracking.

The flag also applies to non-WPT testharness tests.

Xianzhu

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADBxrifhOGwiUDkU-iLWmosznP4vhKNbdu%2BVMad3FrJunzk3qw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS :modal Pseudo Class

[Chris Harrelson]

The CSSWG just resolved yesterday that :modal should apply to fullscreen,
and that fullscreen should be modal. So I think this intent is unblocked.

On Wed, Jun 8, 2022 at 4:50 PM Jihwan Kim  wrote:

> Thanks for Chris Harrelson.
> Once "should fullscreen be modal?" is resolved, I'll keep progress this.
> thanks.
>
> 2022년 6월 9일 목요일 오전 3시 0분 58초 UTC+9에 Chris Harrelson님이 작성:
>
>> I've also added "should fullscreen be modal?" to the CSSWG agenda. Once
>> that is resolved this intent is ready to ship, in my view.
>>
>> On Wed, Jun 8, 2022 at 10:59 AM Chris Harrelson 
>> wrote:
>>
>>>
>>> On Tue, May 31, 2022 at 1:21 AM Arthur Sonzogni 
>>> wrote:
>>>
 Hello,
 It would be nice if there was some repository or documents were we
 could fill some security/privacy questions. I will do it here instead.
 How does this interacts with iframes? Do you know where it might be
 defined in the spec? I remember for the modal dialog, there was some
 "inertness" attribute propagated toward parent/iframes. It was shown it can
 be used to leak cross-site data, or it can be used to create new
 communication channel. It was found and fixed here:
 https://crbug.com/1293191. I guess the two features relies on the same
 mechanism and Chrome might immune as result. Anyway, could you please make
 sure the behavior is specified and show how it doesn't create a cross-site
 leak?
>>>
>>>
>>> You are correct that the same mechanism prevented cross-site information
>>> leaks for "both". In other words, thet modal dialog feature doesn't
>>> propagate, due to the fix for issue 1293191.
>>>
>>> :modal is a pseudoclass state that only changes style for a 
>>> element in the same document as the style sheet using :modal. Therefore a
>>> cross-origin iframe won't be able to change its document's state based on
>>> :modal. So I don't see a way that this feature will introduce new security
>>> or privacy issues. Let me know if this doesn't fully answer your questions.
>>>
>>>
 Filling the https://w3ctag.github.io/security-questionnaire/ is often
 helpful as well ;-)

 On Thursday, May 26, 2022 at 6:51:19 PM UTC+2 Mike Taylor wrote:

> On 5/26/22 9:35 AM, Mike Taylor wrote:
>
> On 5/26/22 2:42 AM, Jihwan Kim wrote:
>
>
> 4. Gecko vendor signal : I set gecko's signal to 'Shipped/Shipping' as
> the doc(bit.ly/blink-signals) defines 'Shipped/Shipping' as 'Link to
> public documentation or bug/issue'. I'm not sure which signal would be
> right if there is an open issue.
>
> Thank for this feedback - I can see how that is confusing. I updated
> the language to say "Link to public documentation or bug/issue that
> demonstrates the issue has shipped (i.e., an issue that links to patches
> that have been merged, or a comment that a previously disabled feature is
> not enabled by default)."
>
> (this should read "now enabled by default", rather than "not"). 🙈
>
 --
 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/f75f277a-11ca-4482-9af0-7764f1241eafn%40chromium.org
 
 .

>>> --
> 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+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/293471ff-f32c-4223-b2cd-994d5d018c59n%40chromium.org
> 
> .
>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8qFPbHfWCg%3DdK0sO2gzsbTskV8hu%2Bev%3DmKAw5i0htQaw%40mail.gmail.com.

[blink-dev] Re: introduce blink_wpt_tests

['Weizhong Xia' via blink-dev]

Hi Folks

Another update on this work. Today I landed the CL to run blink_wpt_tests
as a different step on swarming bots. We will need to find test results at
their respective steps.

Feel free to ping me if you have any questions.

thanks, Weizhong


On Tue, May 3, 2022 at 9:03 AM Weizhong Xia  wrote:

> Hi Folks
>
> A follow up of this announcement. I was finally able to land this change
> yesterday, with a small change. We later decided to keep the platform, to
> reduce the size of the CL. So now all the baselines are under
> *web_tests/platform*, and generic baselines are under
> *web_tests/platform/generic*.
>
> If you have any ongoing CL that changes baselines, pls make sure the
> baselines are at the correct place. Feel free to ping me if you have any
> questions.
>
> thanks, Weizhong
>
> On Mon, Apr 25, 2022 at 4:06 PM Weizhong Xia  wrote:
>
>> Dear blink devs
>>
>> As some of you may already know, I am working to split blink_web_tests
>> into two test suites: *blink_web_tests* for legacy tests and
>> *blink_wpt_tests* for wpt tests(crbug/1299834 ).
>> We now have reached the first point to move all baselines to a central
>> place (CL
>> ).
>> Some of the changes you may need to be aware of:
>> 1. We renamed web_tests/platform to web_tests/baselines.
>> 2. All the generic baselines are now put under
>> web_tests/baselines/generic. (reference files are allowed at both
>> baselines/generic or in the same folder of the test itself.)
>>
>> I planned to do another round of rebaseline then land this CL the
>> coming Saturday, to reduce the chance of merge conflict.
>>
>> After that, we will have another CL to actually break blink_web_tests
>> into two. This should have no impact on your local experiences. The only
>> difference is that we are now running legacy tests and wpt tests at
>> different steps, so you need to get log/results at different places.
>>
>> At this point blink_wpt_tests will continue to run with run_web_tests.py.
>> We have a plan to switch it to use wptrunner, targeting the middle of next
>> year. After that we will have tools, web_tests, wpt_tests under blink, and
>> we will use metadata as test expectation for wpt_tests. More details to
>> come.
>>
>> Thanks for your attention. If you have any suggestion/comments, feel free
>> to reply here, or put that in the crbug or CL. I definitely want to get
>> more input from you folks.
>>
>> Thanks, Weizhong
>>
>>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADXrSiqgL5jUtou9YBcvK8j_hzK-QtfEhFGEFrXM3XE6yY%2BnWg%40mail.gmail.com.

Re: [blink-dev] Developer pain as a result of "introducing blink_wpt_tests"

['Weizhong Xia' via blink-dev]

Hi blink devs

Thanks to those who joined the survey at https://forms.gle/ju45qciS5VTR4ywN7.
Most of you expressed the desire to put baselines at the same place of the
tests. Your voice is heard, and here is the plan for the next step.

In Q3 we will work on to completely separate legacy layout tests and wpt
tests, to put them under `third_party/blink/web_tests` and
`third_party/blink/wpt_tests` respectively. Generic baselines (including
generic virtual baselines) will be moved back to their previous place.
Rebaseline tool will be updated to work with this structure, and update
baselines for legacy layout tests and wpt tests in a single run. We will
have different copies of *TestExpectations*, *FlagSpecificConfig*,
*VirtualTestSuites* etc for legacy tests and wpt tests. When working on
those files, we will need to make sure we are updating the correct copy of
the file. (We will investigate if we need some presubmit check for such a
scenario).

The reason for this is two fold: as requested we want to put baselines side
to side to the tests, and we want to make the directory structure right to
speed up the switch to wptrunner.

Thoughts? Feel free to leave a comment in crbug/1299834.

Thanks, Weizhong



On Mon, Jun 6, 2022 at 5:00 PM Xianzhu Wang 
wrote:

> On Mon, Jun 6, 2022 at 3:52 PM Weizhong Xia  wrote:
>
>> Xianzhu, yes 'baselines' is the name we agreed on previously. The reason
>> I later changed back to use 'platform' is because that will make the CL
>> smaller, and make it easier for gerrit to handle it. We can make one round
>> rename when everything is stabilized. (I left you a message when you are
>> OOO. I am not sure if that message lived long enough for you to catch it.)
>>
>
> I caught the message. I guessed that the name 'platform' might be one of
> the reasons for the surprise to blink developers after the change, and the
> name 'baselines' might make the change easier to explain :)
>
> On Mon, Jun 6, 2022 at 3:52 PM Domenic Denicola 
> wrote:
>
>> I'm not sure I understand this logic. -expected.txt files are just
>> more-convenient, more in-your-face versions of TestExpectations files.
>> Surely you're not suggesting we get rid of TestExpectations files?
>>
>
> Sorry, "-expected.txt ... should be ... eventually be removed" in my
> previous email was not clear. I meant for each individual -expected.txt we
> should eventually remove it because we should fix the failure. The same
> logic applies to TestExpectations. At any time we may allow a certain
> number of failures but we should keep the number as small as possible.
>
> I think we should prefer TestExpectations to -expected.txt for WPT tests
> because the entries in TestExpectations have associated bugs which track
> the fixing process, unless we find a better way to track the fixing of the
> failures in -expected.txt. -expected.txt files do have their values, e.g.
> for partially-passing tests we can discover regressions and progressions of
> individual sub tests, but they should be rare.
>
> I think separating -expected.txt from the tests has the following benefits:
> - It makes it clear to blink developers that the files are not a part of
> WPT.
> - It simplifies the WPT export/import process and others by reducing
> blink-specific files under external/wpt.
>
> It does make it more difficult to find -expected.txt, but we already have
> the similar well-known logic for platform-specific baselines. Though
> platform-specific baselines are rare, ignoring a platform baseline can
> still cause surprises.
>
> I think we can improve the test result viewer
> 
> - to better show -expected.txt for passing tests
> - to show information about tests without actually running the tests
> WDYT?
>
>
>>
>> On Mon, Jun 6, 2022 at 6:30 PM Xianzhu Wang 
>> wrote:
>>
>>> I think we first need to answer a question: Why do we need
>>> *-expected.txt for WPT tests?
>>>
>>> Upstream WPT doesn't have *-expected.txt. *-expected.txt is a
>>> blink-specific thing to allow some failing WPT tests to pass on blink with
>>> temporarily allowed failures. If a test has -expected.txt, it means Chrome
>>> behaves differently than the standard web platform behavior (or the test
>>> itself is wrong). The files are sometimes harmful because they hide
>>> failures and web platform incompatibilities (e.g.
>>> ). So I think -expected.txt files for WPT
>>> tests should be rare and eventually be removed. An -expected.txt should not
>>> be treated as a part of the test itself because a) it doesn't exist in
>>> upstream WPT and 2) it doesn't describe the standard expected behavior,
>>> thus isn't necessarily placed besides the test.
>>>
>>> The directory name 'platform' may be misleading. 'baselines' may be a
>>> better name (but we should not rename until we decide what to do for
>>> generic baselines). For WPT tests, 'failures' is 

Re: [blink-dev] Intent to Ship: MathML

[Chris Harrelson]

EditingNG has already shipped. Only table fragmentation and printing are
still to ship, and hopefully they will both be done by the end of the year.

On Thu, Jun 23, 2022 at 4:39 AM Frédéric Wang  wrote:

> Hi Morten,
>
> Thanks for raising this issue, I forgot to mention it. We experimented
> this in the past and IIRC we found issues with:
>
> - Printing: indeed printing pages with math is likely to happen!
> - Multicol: Wikipedia uses that for the "References" section at the
> bottom of articles and some pages actually do use math inside!
> - SVG: definitely needed for math in graphics. This is no longer an
> issue now that foreignObject was implemented in LayoutNG.
> - Editing: I'm not sure what's the status of EditingNG but I believe we
> wanted to disable editability on MathML anyway due to complexity for
> editing math, which will require some tree fixup. This is better handled
> by other tools.
>
> I don't remember what was the recent status, but we definitely need to
> check again. I believe we have crash tests in WPT and another to check
> correct layout for math-in-svg.
>
> On 23/06/2022 13:06, Morten Stenshorne wrote:
> > Exciting times!
> >
> > Since the layout implementation of MathML is pure NG (i.e. it has no
> > legacy engine counterpart), you should be aware that this is somewhat
> > uncharted territory. We *do* have mechanisms that kick in when we need
> > to fall back to legacy layout (e.g. when printing, or when there are
> > tables inside multicol), and have NG-only content inside (such as
> > MathML), but no pure NG features have shipped yet, so we don't really
> > know how well this works on the world wild web.
> >
> > That said, we're also about to ship container queries, which has the
> > same problem - so you're not alone. I was hoping that we'd be rid of the
> > legacy engine completely before we started shipping pure NG features,
> > because of this risk. I'm not saying that we definitely need to wait for
> > the legacy engine to be completely gone, but you need to be aware of the
> > risk, at least. Maybe clusterfuzz will find something interesting once
> > this feature is switched to "stable". :)
> >
> > By the way, I just tested, and MathML inside legacy layout doesn't seem
> > to work. I filed
> > https://bugs.chromium.org/p/chromium/issues/detail?id=1338882
> >
> > Frédéric Wang  writes:
> >
> >> Contact emails
> >>
> >> fw...@chromium.org, rb...@chromium.org, bkard...@igalia.com
> >>
> >> Explainer
> >>
> >>
> https://github.com/mathml-refresh/mathml-core/blob/master/docs/explainer.md
> >> https://people.igalia.com/fwang/explainer-font-family-math
> >>
> >> Specification
> >>
> >> https://mathml-refresh.github.io/mathml-core
> >>
> >> Design docs
> >>
> >> https://drafts.csswg.org/css-fonts-4/#valdef-font-family-math
> >> https://w3c.github.io/mathml-aam
> >>
> https://docs.google.com/document/d/1biGEaWN8ThNTDtAbT1M5GIf6N5uQLWdxh2QhrG9uN5c
> >>
> https://docs.google.com/document/d/1bvY_Npe2zLW_705KXdmecsH6P9I9wBMpHRsZ9CxWNOI/edit#heading=h.u9hwm9tp8nuy
> >>
> >> Summary
> >>
> >> Adds native DOM/IDL, accessibility support and CSS-compatible
> OpenType-based layout of mathematical formulas. The reference
> >> specifications are MathML Core (which describes in extensive details a
> fundamental subset of the MathML 3 recommendation), MathML AAM
> >> (which describes mapping to platform accessibility APIs). This includes
> the "math" font-family as well as features included in section "CSS
> >> Extensions for Math Layout".
> >>
> >> Blink component
> >>
> >> Blink
> >>
> >> Search tags
> >>
> >> mathml
> >>
> >> TAG review
> >>
> >> https://github.com/w3ctag/design-reviews/issues/438
> https://github.com/w3ctag/design-reviews/issues/313#issuecomment-460523527
> >>
> >> TAG review status
> >>
> >> Issues addressed
> >>
> >> Risks
> >>
> >> Interoperability and Compatibility
> >>
> >> - This is not implementing the complete list of MathML3, OpenType MATH
> or accessibility features that one can find in other browsers.
> >>
> >> - New enhancements (e.g. clarification regarding CSS interoperability)
> may not be implemented in other browsers yet.
> >>
> >> - MathML Core and MathML AAM are still working drafts.
> >>
> >> Gecko: Shipped/Shipping
> >>
> >> WebKit: Shipped/Shipping
> >>
> >> Web developers: Positive (
> https://twitter.com/search?q=mathml%20chrome&f=live) Users have recently
> been excited about it,
> >> experimented exiting implementation under a flag and are eager to see
> it shipped soon. It is currently the 5th most starred Blink issue, see
> >>
> https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component:Blink&sort=-stars&colspec=ID%20Stars%20Pri%20Status%20Component%20Opened%20Summary
> >>
> >>
> >> Other signals:
> >>
> >> Ergonomics
> >>
> >> In the past, MathML trees were not treated specially at all and this
> was fast ! Now, more work is needed for pages that do math rendering
> >> e.g. accessing data from the MATH table, handling operator dictionar

Re: [blink-dev] Intent to Prototype and Ship: Response.json()

['Joe Medley' via blink-dev]

Thank you.
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Jun 23, 2022 at 12:14 AM Adam Rice  wrote:

> I expect to ship it in M105. I have updated chromestatus.com.
>
> On Thu, 23 Jun 2022 at 02:09, Joe Medley  wrote:
>
>> Adam,
>>
>> When are you hoping to ship?
>>
>> Joe
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Wed, Jun 22, 2022 at 8:56 AM Philip Jägenstedt 
>> wrote:
>>
>>> LGTM3
>>>
>>> The TAG review has been sitting for a month now, and this proposal has
>>> already received scrutiny in the spec discussion. If there's feedback (on
>>> naming or otherwise) before this reaches stable, we should take it into
>>> account.
>>>
>>> On Wed, Jun 22, 2022 at 5:54 PM Yoav Weiss 
>>> wrote:
>>>
 LGTM2

 On Wednesday, June 22, 2022 at 5:53:49 PM UTC+2 Chris Harrelson wrote:

> LGTM1
>
> On Tue, May 31, 2022 at 11:08 PM Yoav Weiss 
> wrote:
>
>>
>>
>> On Tue, May 31, 2022 at 4:08 AM Adam Rice  wrote:
>>
>>> Contact emailsri...@chromium.org, yhir...@chromium.org
>>>
>>> Explainer
>>> https://docs.google.com/document/d/1dTycWmyxLZNGTBW93fvtf1IQahx-vNwgu94yT1x9K50/edit
>>>
>>> Specification
>>> https://fetch.spec.whatwg.org/#ref-for-dom-response-json
>>>
>>> Summary
>>>
>>> Improves ergonomics for creating JSON Response objects. The Response
>>> constructor allows for creating the body of the response from many 
>>> types,
>>> however it is not possible to directly create a JSON object. The
>>> Response.json() static method fills this gap. It returns a Response 
>>> object
>>> with a body consisting the first argument serialized as JSON. The second
>>> argument is a ResponseInit option bag as with the Response constructor.
>>>
>>>
>>> Blink componentBlink>Network>FetchAPI
>>> 
>>>
>>> Motivation
>>>
>>> Creating a Response object with a body of a JSON object has been
>>> harder than the other types supported by Fetch. This change improves the
>>> ergonomics of creating a JSON response.
>>>
>>>
>>> Initial public proposalhttps://github.com/whatwg/fetch/issues/1389
>>>
>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/741
>>>
>>
>> The TAG review issue says they'd look into this next week. Given the
>> fact that the issue was filed a couple of weeks ago, it seems reasonable 
>> to
>> wait till then.
>>
>>
>>>
>>>
>>> TAG review statusPending
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Interoperability risk is low as Deno and Node have already
>>> implemented the feature, and it is a simple addition to the API. We 
>>> know of
>>> no compatibility risk. It could happen if someone is using a polyfill 
>>> with
>>> an incompatible API, but that is unlikely.
>>>
>>>
>>> *Gecko*: Worth prototyping (
>>> https://github.com/mozilla/standards-positions/issues/640)
>>>
>>> *WebKit*: Positive (
>>> https://lists.webkit.org/pipermail/webkit-dev/2022-May/032254.html)
>>>
>>> *Web developers*: Positive (
>>> https://github.com/whatwg/fetch/issues/1389) Example positive
>>> feedback:
>>> https://github.com/whatwg/fetch/issues/1389#issuecomment-1024726318 
>>> Example
>>> negative feedback:
>>> https://github.com/whatwg/fetch/issues/1389#issuecomment-1024880489
>>>
>>
>> Great feedback from developers!!
>>
>>
>>>
>>>
>>> *Other signals*:
>>>
>>> Ergonomics
>>>
>>> This is a convenience function that is purely an ergonomic
>>> improvement.
>>>
>>>
>>> Activation
>>>
>>> The feature can be easily polyfilled.
>>>
>>>
>>> Security
>>>
>>> The feature adds no capabilities that developers don't already have.
>>> The implementation mostly reuses existing logic, reducing the security 
>>> risk.
>>>
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based 
>>> applications?
>>>
>>> No
>>>
>>>
>>> Debuggability
>>>
>>> Automatically supported as a feature implemented in WebIDL.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?Yes
>>>
>>> Flag name
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://crbug.com/1305358
>>>
>>> No

Re: [blink-dev] Intent to Ship: MathML

[Frédéric Wang]

Hi Morten,

Thanks for raising this issue, I forgot to mention it. We experimented 
this in the past and IIRC we found issues with:


- Printing: indeed printing pages with math is likely to happen!
- Multicol: Wikipedia uses that for the "References" section at the 
bottom of articles and some pages actually do use math inside!
- SVG: definitely needed for math in graphics. This is no longer an 
issue now that foreignObject was implemented in LayoutNG.
- Editing: I'm not sure what's the status of EditingNG but I believe we 
wanted to disable editability on MathML anyway due to complexity for 
editing math, which will require some tree fixup. This is better handled 
by other tools.


I don't remember what was the recent status, but we definitely need to 
check again. I believe we have crash tests in WPT and another to check 
correct layout for math-in-svg.


On 23/06/2022 13:06, Morten Stenshorne wrote:

Exciting times!

Since the layout implementation of MathML is pure NG (i.e. it has no
legacy engine counterpart), you should be aware that this is somewhat
uncharted territory. We *do* have mechanisms that kick in when we need
to fall back to legacy layout (e.g. when printing, or when there are
tables inside multicol), and have NG-only content inside (such as
MathML), but no pure NG features have shipped yet, so we don't really
know how well this works on the world wild web.

That said, we're also about to ship container queries, which has the
same problem - so you're not alone. I was hoping that we'd be rid of the
legacy engine completely before we started shipping pure NG features,
because of this risk. I'm not saying that we definitely need to wait for
the legacy engine to be completely gone, but you need to be aware of the
risk, at least. Maybe clusterfuzz will find something interesting once
this feature is switched to "stable". :)

By the way, I just tested, and MathML inside legacy layout doesn't seem
to work. I filed
https://bugs.chromium.org/p/chromium/issues/detail?id=1338882

Frédéric Wang  writes:


Contact emails

fw...@chromium.org, rb...@chromium.org, bkard...@igalia.com

Explainer

https://github.com/mathml-refresh/mathml-core/blob/master/docs/explainer.md
https://people.igalia.com/fwang/explainer-font-family-math

Specification

https://mathml-refresh.github.io/mathml-core

Design docs

https://drafts.csswg.org/css-fonts-4/#valdef-font-family-math
https://w3c.github.io/mathml-aam
https://docs.google.com/document/d/1biGEaWN8ThNTDtAbT1M5GIf6N5uQLWdxh2QhrG9uN5c
https://docs.google.com/document/d/1bvY_Npe2zLW_705KXdmecsH6P9I9wBMpHRsZ9CxWNOI/edit#heading=h.u9hwm9tp8nuy

Summary

Adds native DOM/IDL, accessibility support and CSS-compatible OpenType-based 
layout of mathematical formulas. The reference
specifications are MathML Core (which describes in extensive details a 
fundamental subset of the MathML 3 recommendation), MathML AAM
(which describes mapping to platform accessibility APIs). This includes the "math" 
font-family as well as features included in section "CSS
Extensions for Math Layout".

Blink component

Blink

Search tags

mathml

TAG review

https://github.com/w3ctag/design-reviews/issues/438 
https://github.com/w3ctag/design-reviews/issues/313#issuecomment-460523527

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

- This is not implementing the complete list of MathML3, OpenType MATH or 
accessibility features that one can find in other browsers.

- New enhancements (e.g. clarification regarding CSS interoperability) may not 
be implemented in other browsers yet.

- MathML Core and MathML AAM are still working drafts.

Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: Positive (https://twitter.com/search?q=mathml%20chrome&f=live) 
Users have recently been excited about it,
experimented exiting implementation under a flag and are eager to see it 
shipped soon. It is currently the 5th most starred Blink issue, see
https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component:Blink&sort=-stars&colspec=ID%20Stars%20Pri%20Status%20Component%20Opened%20Summary


Other signals:

Ergonomics

In the past, MathML trees were not treated specially at all and this was fast ! 
Now, more work is needed for pages that do math rendering
e.g. accessing data from the MATH table, handling operator dictionary, using 
ink text bounds, performing low-level shaping of stretchy
operators, loading and applying CSS UA sheet, or exposing an accessibility 
tree. However, the only performance report we received so far
was issue #1073760, which was discarded after further analysis. In any case, 
performance is definitely better than existing non-native
technologies. Additionally, pages will likely need loading WOFF fonts on 
operating systems that don't ship math fonts. Work is in progress
here, see https://frederic-wang.fr/update-on-open-type-math-fonts.html for 
recent status.

Activation

- Editing MathML source is difficult but special authoring tool

Re: [blink-dev] Intent to Ship: MathML

[Morten Stenshorne]

Exciting times!

Since the layout implementation of MathML is pure NG (i.e. it has no
legacy engine counterpart), you should be aware that this is somewhat
uncharted territory. We *do* have mechanisms that kick in when we need
to fall back to legacy layout (e.g. when printing, or when there are
tables inside multicol), and have NG-only content inside (such as
MathML), but no pure NG features have shipped yet, so we don't really
know how well this works on the world wild web.

That said, we're also about to ship container queries, which has the
same problem - so you're not alone. I was hoping that we'd be rid of the
legacy engine completely before we started shipping pure NG features,
because of this risk. I'm not saying that we definitely need to wait for
the legacy engine to be completely gone, but you need to be aware of the
risk, at least. Maybe clusterfuzz will find something interesting once
this feature is switched to "stable". :)

By the way, I just tested, and MathML inside legacy layout doesn't seem
to work. I filed
https://bugs.chromium.org/p/chromium/issues/detail?id=1338882

Frédéric Wang  writes:

> Contact emails
>
> fw...@chromium.org, rb...@chromium.org, bkard...@igalia.com 
>
> Explainer
>
> https://github.com/mathml-refresh/mathml-core/blob/master/docs/explainer.md 
> https://people.igalia.com/fwang/explainer-font-family-math 
>
> Specification
>
> https://mathml-refresh.github.io/mathml-core 
>
> Design docs
>
> https://drafts.csswg.org/css-fonts-4/#valdef-font-family-math 
> https://w3c.github.io/mathml-aam 
> https://docs.google.com/document/d/1biGEaWN8ThNTDtAbT1M5GIf6N5uQLWdxh2QhrG9uN5c
>  
> https://docs.google.com/document/d/1bvY_Npe2zLW_705KXdmecsH6P9I9wBMpHRsZ9CxWNOI/edit#heading=h.u9hwm9tp8nuy
>  
>
> Summary
>
> Adds native DOM/IDL, accessibility support and CSS-compatible OpenType-based 
> layout of mathematical formulas. The reference
> specifications are MathML Core (which describes in extensive details a 
> fundamental subset of the MathML 3 recommendation), MathML AAM
> (which describes mapping to platform accessibility APIs). This includes the 
> "math" font-family as well as features included in section "CSS
> Extensions for Math Layout".
>
> Blink component
>
> Blink 
>
> Search tags
>
> mathml 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/438 
> https://github.com/w3ctag/design-reviews/issues/313#issuecomment-460523527 
>
> TAG review status
>
> Issues addressed 
>
> Risks
>
> Interoperability and Compatibility
>
> - This is not implementing the complete list of MathML3, OpenType MATH or 
> accessibility features that one can find in other browsers.
>
> - New enhancements (e.g. clarification regarding CSS interoperability) may 
> not be implemented in other browsers yet. 
>
> - MathML Core and MathML AAM are still working drafts. 
>
> Gecko: Shipped/Shipping 
>
> WebKit: Shipped/Shipping 
>
> Web developers: Positive 
> (https://twitter.com/search?q=mathml%20chrome&f=live) Users have recently 
> been excited about it,
> experimented exiting implementation under a flag and are eager to see it 
> shipped soon. It is currently the 5th most starred Blink issue, see
> https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component:Blink&sort=-stars&colspec=ID%20Stars%20Pri%20Status%20Component%20Opened%20Summary
>
>
> Other signals: 
>
> Ergonomics
>
> In the past, MathML trees were not treated specially at all and this was fast 
> ! Now, more work is needed for pages that do math rendering
> e.g. accessing data from the MATH table, handling operator dictionary, using 
> ink text bounds, performing low-level shaping of stretchy
> operators, loading and applying CSS UA sheet, or exposing an accessibility 
> tree. However, the only performance report we received so far
> was issue #1073760, which was discarded after further analysis. In any case, 
> performance is definitely better than existing non-native
> technologies. Additionally, pages will likely need loading WOFF fonts on 
> operating systems that don't ship math fonts. Work is in progress
> here, see https://frederic-wang.fr/update-on-open-type-math-fonts.html for 
> recent status. 
>
> Activation
>
> - Editing MathML source is difficult but special authoring tools & converters 
> do exist.
>
> - Implementation may not be as complete as expected by users but the spec 
> tries to allow extensibility and the Math WG provides polyfills
> at https://github.com/mathml-refresh/mathml-polyfills
>
> - Users may require WOFF fonts to properly render formulas (see above). 
>
> Security
>
> There is a risk due to the new attack surface:
>
> - Relatively large amount of new code.
>
> - Newly exposed APIs.
>
> - Interacting with several parts of the web platform.
>
> However, risks related to violation of layout algorithm are reduced now that 
> the specification clarifies how to perform it in a CSS-compatible
> way. We've fixed 17 issues reported during 2.5 years of development and there 
> are currently 

RE: [blink-dev] Intent to Prototype : Background Blur API.

[Bhaumik, Rijubrata]

We are going to first implement this on Windows. “Real” support is dependent on 
driver support. If on your client machine, the camera app can do it, then this 
API can also do it.
I don’t have a Mac, but there’s platform 
support, so we 
can collaborate once the initial Blink CLs lands.

From: 'François Beaufort 🇫🇷' via blink-dev 
Sent: Thursday, June 23, 2022 10:51 AM
To: Yoav Weiss 
Cc: Bhaumik, Rijubrata ; blink-dev@chromium.org; 
Guido Urdaneta ; Harald Alvestrand ; 
Youenn Fablet ; Bernard Aboba ; 
Jan-Ivar Bruaroey @Mozilla 
Subject: Re: [blink-dev] Intent to Prototype : Background Blur API.


Thank you for starting this effort!

Quick question: Will this feature be supported on all six Blink platforms 
(Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Not just 
exposing backgroundBlur properties but also it "real" support.

On Thu, Jun 23, 2022 at 9:26 AM Yoav Weiss 
mailto:yoavwe...@chromium.org>> wrote:
Exciting work!!

On Wed, Jun 22, 2022 at 11:46 PM Bhaumik, Rijubrata 
mailto:rijubrata.bhau...@intel.com>> wrote:
Contact emails
rijubrata.bhau...@intel.com, 
eero.hakki...@intel.com
Explainer
https://github.com/riju/backgroundBlur/blob/main/explainer.md
Specification
https://w3c.github.io/mediacapture-extensions/#exposing-mediastreamtrack-source-background-blur-support
Summary

Background Blur API gives web developers a choice to use the native platform's 
API for background segmentation. Background Blur has become one of the most 
used features on Video conferencing apps like Teams, Meet, Zoom, Webex, etc. We 
want give Web apps similar capabilities as their native counterparts, 
leveraging the same platform APIs and to delight users without completely 
relying on ML frameworks like TensorFlow.js, Mediapipe, WASM libraries or cloud 
based solutions.

Blink component
Blink>ImageCapture
Motivation
A vast majority of communication these days happens on our client devices. 
During video meetings, participants are usually aware of how they look and what 
their environment (usually their home) is revealing to the audience. Most 
folks, especially ones without a dedicated office space would be inclined to 
hide messy rooms with pets and kids. Video meetings like face to face meetings 
are important for non-verbal communication but participants would rather focus 
on the important subject by removing the distractions in the background and 
prevent any accidental snafus. Microsoft 
says
 in a 38 minute conference call, 13 minutes are wasted dealing with 
distractions and interruptions. Background Blur goes a long way to cutting down 
those disruptions. Zoom 
says-
 "When a custom virtual background is unavailable or not suiting your needs, 
but you still want to maintain some privacy with regards to your surroundings, 
the blur background option can be a great alternative. This option simply blurs 
the background of your video, obscuring exactly who or what is behind you. It's 
great for hiding a cluttered dorm room, taking a meeting in a coffee shop, or 
just keeping things professional." . In fact, NCSC (National Cyber Security 
Centre UK) suggests using background Blur or a background 
image
 for staff meetings to add a degree of personal privacy.
On the Web, due to a lack of a standardized API for Background Blur and 
widespread demand, developers have no options but to use ML frameworks like 
Tensorflow.js and other WASM libraries to satisfy their customers. This 
Background Blur API gives developers a choice to use the native platform's API.
Initial public proposal
https://github.com/w3c/mediacapture-extensions/pull/49
https://github.com/w3c/mediacapture-extensions/pull/61
Search tags
background blur, 
webrtc
TAG review

May be a good idea to file for a TAG review early.


TAG review status
Pending
Risks

Interoperability and Compatibility


Gecko: No signal, but spec LGTM ed by Jan-Ivar (Mozilla). 
https://github.com/mozilla/standards-positions/issues/658

WebKit: No signal but Apple co-author of explainer / PR. 
https://lists.webkit.org/pipermail/webkit-dev/2022-June/032311.html

Web developers: No signals

Other signals: Almost every video-conference app has background blur feature.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it 
has potentially high risk for Android WebView-based applications?

Debuggability

Is thi

Re: [blink-dev] Re: Intent to Ship: DisplayMediaStreamConstraints.systemAudio

['Elad Alon' via blink-dev]

Thanks you all!

On Tuesday, June 21, 2022 at 6:45:57 PM UTC+2 Chris Harrelson wrote:

> LGTM3
>
> On Thu, Jun 16, 2022 at 5:12 AM Mike Taylor  wrote:
>
>> LGTM2
>>
>> On 6/16/22 9:42 AM, Yoav Weiss wrote:
>>
>> LGTM1 to ship this without waiting on TAG feedback. Please add a feature 
>> flag just in case, and follow up on any TAG feedback in future milestones.
>>
>> On Thu, Jun 16, 2022 at 9:27 AM Elad Alon  wrote:
>>
>>> Hello Blink owners,
>>>
>>> I am working to align getDisplayMedia() and the Extension API, to the 
>>> point that deprecating the Hangouts Extension would be possible. It's going 
>>> to be a gradual process with multiple changes required. Shipping this one 
>>> particular API surface (systemAudio) in the next Chrome release would 
>>> greatly expedite projected timelines, as it would unblock some other work.
>>>
>>> I've spoken to Sangwhan (CCed), and it seems like TAG review is expected 
>>> end-of-July - a significant delay. I am therefore asking that, out of the 
>>> four intents recently sent, this one intent be approved without waiting for 
>>> TAG. Wdys?
>>>
>>> Thanks,
>>> Elad
>>>
>>> On Wednesday, June 8, 2022 at 5:47:49 PM UTC+2 sligh...@chromium.org 
>>> wrote:
>>>
 Thanks Harald and Elad. 

 On Thursday, June 2, 2022 at 5:19:17 AM UTC-7 Harald Alvestrand wrote:

> re webrtc trying to skip TAG review ... we were told at one point (a 
> few years back, I think) that we were sending too many TAG reviews; I 
> believe that at that point, something like 1/3 of the outstanding TAG 
> reviews were on relatively small WebRTC features. I guess we scaled back 
> too forcefully  thanks for pointing out the desire to course-correct. 
>
>
> On Wed, Jun 1, 2022 at 6:13 PM Alex Russell  
> wrote:
>
>> Hey Elad, 
>>
>> This is a pretty simple design, and it's great to see the progress 
>> here. That said, this group of intents (systemAudio, 
>> suppressLocalAudioPlayback, and selfBrowserSurface) would benefit from a 
>> joint explainer with considered alternatives outlined. The TAG might not 
>> have much to say about small changes, but our process asks teams to *at 
>> least *send them an FYI for non-controversial updates so that they 
>> can consider how parts fit together in future.
>>
>> Given that the WebRTC group has a history of trying to skip TAG 
>> review, it doesn't seem right for this set of features to launch without 
>> some intentional design review. Can you file a request with them or get 
>> several of the current and former TAG members (Rossen, David, Alice, 
>> myself, or Domenic) in the project to review the design directly?
>>
>> Thanks
>>
>>
>> On Wednesday, June 1, 2022 at 12:35:24 AM UTC-7 Elad Alon wrote:
>>
>>> I've set my alarm. 
>>> I'll implicitly assume the same period is intended for the other 
>>> three intents-to-ship sent at roughly the same time.
>>>
>>> On Wed, Jun 1, 2022 at 9:29 AM Yoav Weiss  
>>> wrote:
>>>
 Let's give them 1 more week to respond.

 On Wed, Jun 1, 2022 at 9:21 AM Elad Alon  
 wrote:

> Okay, will do. (I've also sent a personal email on the day 
> the intent went out.) 
> When shall I ping this thread if no response is received?
>
> On Wed, Jun 1, 2022 at 8:30 AM Yoav Weiss  
> wrote:
>
>>
>>
>> On Wednesday, May 25, 2022 at 2:38:53 PM UTC+2 Elad Alon wrote:
>>
>>> Contact emails elad...@chromium.org
>>>
>>> Explainer 
>>> https://docs.google.com/document/d/1q3oGy7hLJmdQA4ZK7QG7DnwgtcpL6oB2pqLQJ6MP1tY/edit?usp=sharing
>>>
>>
>>>
>>> Specification 
>>> https://github.com/w3c/mediacapture-screen-share/pull/222/files
>>>
>>> Summary 
>>>
>>> Hint indicating to the user agent whether the application, upon 
>>> calling getDisplayMedia() with {audio: true} or similar, wishes 
>>> *system 
>>> audio* to be offered to the user. (If not - only offer tab-audio.)
>>>
>>>
>>> Blink component Blink 
>>> 
>>>
>>> TAG review N/A. This is just an addition of a single flag to an 
>>> existing dictionary, following well-known patterns.
>>>
>>> TAG review status Not applicable
>>>
>>> Risks 
>>>
>>>
>>> Interoperability and Compatibility *Gecko*: Positive (
>>> https://github.com/mozilla/standards-positions/issues/638) 
>>> Jan-Ivar Bruaroey from Mozilla, and Youenn Fablet from Apple, have 
>>> both 
>>> collaborated with us closely in shaping this PR. They have then 
>>> approved 
>>> merging this PR into w3c/

Re: [blink-dev] Intent to Prototype : Background Blur API.

['François Beaufort 🇫🇷' via blink-dev]

Thank you for starting this effort!

Quick question: Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Not just
exposing backgroundBlur properties but also it "real" support.

On Thu, Jun 23, 2022 at 9:26 AM Yoav Weiss  wrote:

> Exciting work!!
>
> On Wed, Jun 22, 2022 at 11:46 PM Bhaumik, Rijubrata <
> rijubrata.bhau...@intel.com> wrote:
>
>> Contact emails
>>
>> rijubrata.bhau...@intel.com, eero.hakki...@intel.com
>>
>> Explainer
>>
>> https://github.com/riju/backgroundBlur/blob/main/explainer.md
>>
>> Specification
>>
>>
>> https://w3c.github.io/mediacapture-extensions/#exposing-mediastreamtrack-source-background-blur-support
>>
>> Summary
>>
>> Background Blur API gives web developers a choice to use the native
>> platform's API for background segmentation. Background Blur has become one
>> of the most used features on Video conferencing apps like Teams, Meet,
>> Zoom, Webex, etc. We want give Web apps similar capabilities as their
>> native counterparts, leveraging the same platform APIs and to delight users
>> without completely relying on ML frameworks like TensorFlow.js, Mediapipe,
>> WASM libraries or cloud based solutions.
>>
>>
>> Blink component
>>
>> Blink>ImageCapture
>> 
>>
>> Motivation A vast majority of communication these days happens on our
>> client devices. During video meetings, participants are usually aware of
>> how they look and what their environment (usually their home) is revealing
>> to the audience. Most folks, especially ones without a dedicated office
>> space would be inclined to hide messy rooms with pets and kids. Video
>> meetings like face to face meetings are important for non-verbal
>> communication but participants would rather focus on the important subject
>> by removing the distractions in the background and prevent any accidental
>> snafus. Microsoft says
>> 
>>  in
>> a 38 minute conference call, 13 minutes are wasted dealing with
>> distractions and interruptions. Background Blur goes a long way to cutting
>> down those disruptions. Zoom says
>> -
>> "*When a custom virtual background is unavailable or not suiting your
>> needs, but you still want to maintain some privacy with regards to your
>> surroundings, the blur background option can be a great alternative. This
>> option simply blurs the background of your video, obscuring exactly who or
>> what is behind you. It's great for hiding a cluttered dorm room, taking a
>> meeting in a coffee shop, or just keeping things professional.*" . In
>> fact, NCSC (National Cyber Security Centre UK) suggests using background
>> Blur or a background image
>> 
>>  for
>> staff meetings to add a degree of personal privacy. On the Web, due to a
>> lack of a standardized API for Background Blur and widespread demand,
>> developers have no options but to use ML frameworks like Tensorflow.js and
>> other WASM libraries to satisfy their customers. This Background Blur API
>> gives developers a choice to use the native platform's API. Initial
>> public proposal
>>
>> https://github.com/w3c/mediacapture-extensions/pull/49
>> https://github.com/w3c/mediacapture-extensions/pull/61
>>
>> Search tags
>>
>> background blur
>> , webrtc
>> 
>>
>> TAG review
>>
>
> May be a good idea to file for a TAG review early.
>
>
>>
>> TAG review status
>>
>> Pending
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>> *Gecko*: No signal, but spec LGTM ed by Jan-Ivar (Mozilla).
>> https://github.com/mozilla/standards-positions/issues/658
>>
>> *WebKit*: No signal but Apple co-author of explainer / PR.
>> https://lists.webkit.org/pipermail/webkit-dev/2022-June/032311.html
>>
>> *Web developers*: No signals
>>
>> *Other signals*: Almost every video-conference app has background blur
>> feature.
>>
>>
>> WebView application risks
>>
>> *Does this intent deprecate or change behavior of existing APIs, such
>> that it has potentially high risk for Android WebView-based applications?*
>>
>>
>>
>> Debuggability
>>
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes ( as part of CL )
>>
>> Flag name
>>
>> MediaCaptureBackgroundBlur
>>
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1338665   Estimated
>> milestones
>>
>> No milestones specified
>>
>>
>>
>> Link to entry on the Chrome Platform Status
>>

Re: [blink-dev] Intent to Prototype : Background Blur API.

[Yoav Weiss]

Exciting work!!

On Wed, Jun 22, 2022 at 11:46 PM Bhaumik, Rijubrata <
rijubrata.bhau...@intel.com> wrote:

> Contact emails
>
> rijubrata.bhau...@intel.com, eero.hakki...@intel.com
>
> Explainer
>
> https://github.com/riju/backgroundBlur/blob/main/explainer.md
>
> Specification
>
>
> https://w3c.github.io/mediacapture-extensions/#exposing-mediastreamtrack-source-background-blur-support
>
> Summary
>
> Background Blur API gives web developers a choice to use the native
> platform's API for background segmentation. Background Blur has become one
> of the most used features on Video conferencing apps like Teams, Meet,
> Zoom, Webex, etc. We want give Web apps similar capabilities as their
> native counterparts, leveraging the same platform APIs and to delight users
> without completely relying on ML frameworks like TensorFlow.js, Mediapipe,
> WASM libraries or cloud based solutions.
>
>
> Blink component
>
> Blink>ImageCapture
> 
>
> Motivation A vast majority of communication these days happens on our
> client devices. During video meetings, participants are usually aware of
> how they look and what their environment (usually their home) is revealing
> to the audience. Most folks, especially ones without a dedicated office
> space would be inclined to hide messy rooms with pets and kids. Video
> meetings like face to face meetings are important for non-verbal
> communication but participants would rather focus on the important subject
> by removing the distractions in the background and prevent any accidental
> snafus. Microsoft says
> 
>  in
> a 38 minute conference call, 13 minutes are wasted dealing with
> distractions and interruptions. Background Blur goes a long way to cutting
> down those disruptions. Zoom says
> -
> "*When a custom virtual background is unavailable or not suiting your
> needs, but you still want to maintain some privacy with regards to your
> surroundings, the blur background option can be a great alternative. This
> option simply blurs the background of your video, obscuring exactly who or
> what is behind you. It's great for hiding a cluttered dorm room, taking a
> meeting in a coffee shop, or just keeping things professional.*" . In
> fact, NCSC (National Cyber Security Centre UK) suggests using background
> Blur or a background image
> 
>  for
> staff meetings to add a degree of personal privacy. On the Web, due to a
> lack of a standardized API for Background Blur and widespread demand,
> developers have no options but to use ML frameworks like Tensorflow.js and
> other WASM libraries to satisfy their customers. This Background Blur API
> gives developers a choice to use the native platform's API. Initial
> public proposal
>
> https://github.com/w3c/mediacapture-extensions/pull/49
> https://github.com/w3c/mediacapture-extensions/pull/61
>
> Search tags
>
> background blur 
> , webrtc 
>
> TAG review
>

May be a good idea to file for a TAG review early.


>
> TAG review status
>
> Pending
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: No signal, but spec LGTM ed by Jan-Ivar (Mozilla).
> https://github.com/mozilla/standards-positions/issues/658
>
> *WebKit*: No signal but Apple co-author of explainer / PR.
> https://lists.webkit.org/pipermail/webkit-dev/2022-June/032311.html
>
> *Web developers*: No signals
>
> *Other signals*: Almost every video-conference app has background blur
> feature.
>
>
> WebView application risks
>
> *Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?*
>
>
>
> Debuggability
>
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes ( as part of CL )
>
> Flag name
>
> MediaCaptureBackgroundBlur
>
>
> Requires code in //chrome?
>
> False
>
> Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1338665
>   Estimated milestones
>
> No milestones specified
>
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5077577782263808
>
> This intent message was generated by Chrome Platform Status
> .
>
>
>
> --
> 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+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com

Re: [blink-dev] Intent to Prototype and Ship: Response.json()

[Adam Rice]

I expect to ship it in M105. I have updated chromestatus.com.

On Thu, 23 Jun 2022 at 02:09, Joe Medley  wrote:

> Adam,
>
> When are you hoping to ship?
>
> Joe
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>  816-678-7195
> *If an API's not documented it doesn't exist.*
>
>
> On Wed, Jun 22, 2022 at 8:56 AM Philip Jägenstedt 
> wrote:
>
>> LGTM3
>>
>> The TAG review has been sitting for a month now, and this proposal has
>> already received scrutiny in the spec discussion. If there's feedback (on
>> naming or otherwise) before this reaches stable, we should take it into
>> account.
>>
>> On Wed, Jun 22, 2022 at 5:54 PM Yoav Weiss 
>> wrote:
>>
>>> LGTM2
>>>
>>> On Wednesday, June 22, 2022 at 5:53:49 PM UTC+2 Chris Harrelson wrote:
>>>
 LGTM1

 On Tue, May 31, 2022 at 11:08 PM Yoav Weiss 
 wrote:

>
>
> On Tue, May 31, 2022 at 4:08 AM Adam Rice  wrote:
>
>> Contact emailsri...@chromium.org, yhir...@chromium.org
>>
>> Explainer
>> https://docs.google.com/document/d/1dTycWmyxLZNGTBW93fvtf1IQahx-vNwgu94yT1x9K50/edit
>>
>> Specificationhttps://fetch.spec.whatwg.org/#ref-for-dom-response-json
>>
>> Summary
>>
>> Improves ergonomics for creating JSON Response objects. The Response
>> constructor allows for creating the body of the response from many types,
>> however it is not possible to directly create a JSON object. The
>> Response.json() static method fills this gap. It returns a Response 
>> object
>> with a body consisting the first argument serialized as JSON. The second
>> argument is a ResponseInit option bag as with the Response constructor.
>>
>>
>> Blink componentBlink>Network>FetchAPI
>> 
>>
>> Motivation
>>
>> Creating a Response object with a body of a JSON object has been
>> harder than the other types supported by Fetch. This change improves the
>> ergonomics of creating a JSON response.
>>
>>
>> Initial public proposalhttps://github.com/whatwg/fetch/issues/1389
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/741
>>
>
> The TAG review issue says they'd look into this next week. Given the
> fact that the issue was filed a couple of weeks ago, it seems reasonable 
> to
> wait till then.
>
>
>>
>>
>> TAG review statusPending
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Interoperability risk is low as Deno and Node have already
>> implemented the feature, and it is a simple addition to the API. We know 
>> of
>> no compatibility risk. It could happen if someone is using a polyfill 
>> with
>> an incompatible API, but that is unlikely.
>>
>>
>> *Gecko*: Worth prototyping (
>> https://github.com/mozilla/standards-positions/issues/640)
>>
>> *WebKit*: Positive (
>> https://lists.webkit.org/pipermail/webkit-dev/2022-May/032254.html)
>>
>> *Web developers*: Positive (
>> https://github.com/whatwg/fetch/issues/1389) Example positive
>> feedback:
>> https://github.com/whatwg/fetch/issues/1389#issuecomment-1024726318 
>> Example
>> negative feedback:
>> https://github.com/whatwg/fetch/issues/1389#issuecomment-1024880489
>>
>
> Great feedback from developers!!
>
>
>>
>>
>> *Other signals*:
>>
>> Ergonomics
>>
>> This is a convenience function that is purely an ergonomic
>> improvement.
>>
>>
>> Activation
>>
>> The feature can be easily polyfilled.
>>
>>
>> Security
>>
>> The feature adds no capabilities that developers don't already have.
>> The implementation mostly reuses existing logic, reducing the security 
>> risk.
>>
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such
>> that it has potentially high risk for Android WebView-based applications?
>>
>> No
>>
>>
>> Debuggability
>>
>> Automatically supported as a feature implemented in WebIDL.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>>
>> Flag name
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/1305358
>>
>> Non-OSS dependencies
>>
>> Does the feature depend on any code or APIs outside the Chromium open
>> source repository and its open-source dependencies to function?
>> No
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5197912798658560
>>
>> This int