date:20220525

[blink-dev] Intent to Extend Experiment: Cookies Having Independent Partitioned State (CHIPS)

2022-05-25 Thread 'Dylan Cutler' via blink-dev

Contact emails

dylancut...@google.com, kaustub...@google.com

Spec (Copied from I2E)

https://github.com/WICG/CHIPS

Summary (Copied from I2E)

Given that Chrome plans on obsoleting unpartitioned third-party cookies, we
want to give developers the ability to use cookies in cross-site contexts
that are partitioned by top-level site (or First-Party Set, where the site
uses that feature) to meet use cases that are not cross-site tracking
related (e.g. SaaS embeds, headless CMS, sandbox domains, etc.). In order
to do so, we introduce a mechanism to opt-in to having their third-party
cookies partitioned by top-level site using a new cookie attribute,
Partitioned.

Link to “Intent to Prototype” blink-dev discussion (Copied from I2E)

https://groups.google.com/a/chromium.org/g/blink-dev/c/hvMJ33kqHRo

Goals for experimentation (Copied from I2E)

CHIPS is a new, opt-in technology meant to preserve a set of use cases
(e.g. third-party embeds) that may break once third-party cookies are
phased out while preventing cross-site tracking. We need to validate
whether the proposed syntax and semantics solve these use cases prior to
third-party cookie obsoletion by giving developers a way to test it in a
scaled manner and provide early feedback. We hope to validate ergonomics,
deployability, and backward compatibility.

Experimental timeline (Modified)

The experiment started in M100 and started on March 29th, 2022 and is
currently scheduled to run until June 14, 2022.

We would like to extend the experiment through M104; or in other words,
until the release of M105, which is August 30th, 2022.

Any risks when the experiment finishes? (Copied from I2E)

Since Chrome will not send and may delete partitioned cookies when it is
started with the feature disabled, sites that set cookies with the
Partitioned attribute during the experiment will no longer have those
cookies available on clients' machines.

Reasons this experiment is being extended (New)

We are talking to multiple interested testing partners, with different
use cases, who have requested additional time to prepare for the origin
trial, and test the feature. Extending the trial would allow us to gather
more feedback across more use cases.
-

We discovered a bug
that
prevents Origin Trial opt-in from third-party contexts, which is the
typical configuration to use the feature. This bug has been fixed in M103.
-

We have received feedback

that the current origin trial opt-in mechanism is difficult to deploy for
large organizations. We have proposed an update to the design

of this mechanism, which we aim to release in M103.

Ongoing technical constraints (Copied from I2E)

None.

Debuggability (Copied from I2E)

We have coordinated with the DevTools team to surface cookie partition keys
to developers in DevTools. We have added a new cookie inclusion reason with
a debug string when sites set Partitioned cookies incorrectly. We may also
support surfacing partitioned cookies that are not included in requests
because their partition key did not match the top-level site in DevTools.

Will this feature be supported on all five Blink platforms supported by
Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)? (Copied from
I2E)

Yes.

Link to entry on the feature dashboard
(Copied from I2E)

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

--
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/CAMCNMFSx%3DLnTJGOGt0S5GnefQGGEhtea5tUxFkix%3DKYFDxZbyQ%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Prototype: Reduce fingerprinting in the Accept-Language header and support for HTTP Variants

2022-05-25 Thread Brian Birtles

2022年5月26日木曜日 0:25:24 UTC+9 Daniel Bratell:

> I think expanding from one to two languages will be enough to cover many 
> of the use cases, and I don't think that will add much information (TBD).
>
I'm skeptical about that, particularly because of different variants. e.g. 
for a site only available in Korean or Japanese, "en-AU, en-UK, en-US, en, 
ja, da" should still show Japanese content. Similarly for a user who 
understands various flavours of Chinese, followed by Japanese, but not 
English.

>

-- 
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/95b40315-e36d-4df7-ab30-0dafedd58e58n%40chromium.org.

[blink-dev] Re: Intent to Prototype and Ship: Multi-Screen Window Placement: Fullscreen Companion Window

2022-05-25 Thread Mike Wasserman

Thanks for asking! Here is an initial draft PR, now out for review: <
https://github.com/w3c/window-placement/pull/101>
An alternate formulation might extend HTML's Tracking User Activation
models <
https://html.spec.whatwg.org/multipage/interaction.html#tracking-user-activation>
and refine the use of those models in individual APIs.

On Wed, May 25, 2022 at 1:55 AM Yoav Weiss  wrote:

>
>
> On Tuesday, May 10, 2022 at 2:35:40 AM UTC+2 Mike Wasserman wrote:
>
>> Contact emails
>>
>> m...@chromium.org
>>
>>
>> Explainer
>>
>>
>> https://github.com/w3c/window-placement/blob/main/EXPLAINER_initiating_multi_screen_experiences.md
>>
>> Specification
>>
>>
>> https://github.com/w3c/window-placement/blob/main/EXPLAINER_initiating_multi_screen_experiences.md#spec-changes
>>
>
> Are there PRs that define the new processing models for this?
>
>
>>
>> Design docs
>>
>>
>> https://docs.google.com/document/d/1RRlGQharWVnmxKTomfKhNiaeE31L7iXHeXVfifOvwJA
>>
>> Summary
>>
>> Fullscreen Companion Window allows sites to place fullscreen content and
>> a popup window on separate screens from a single user activation.
>>
>> This is a small requested enhancement of the Multi-Screen Window
>> Placement feature: https://chromestatus.com/feature/5252960583942144
>>
>> Blink component
>>
>> Blink>Screen>MultiScreen
>> 
>>
>> TAG review
>>
>>
>> https://github.com/w3ctag/design-reviews/issues/602#issuecomment-1121694034
>>
>> TAG review status
>>
>> Pending
>>
>> Risks
>> Interoperability and Compatibility
>>
>> The main risk is that this feature fails to become an interoperable part
>> of the web platform if other browsers do not implement it. Scripted
>> attempts to open a popup window after requesting fullscreen would likely be
>> blocked by user agents that do not implement this feature, even if they
>> implement the basic Multi-Screen Window Placement API.
>>
>> Gecko: No signal (
>> https://github.com/mozilla/standards-positions/issues/636)
>>
>> WebKit: No signal (
>> https://lists.webkit.org/pipermail/webkit-dev/2022-May/032223.html)
>>
>> Web developers: Positive (
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1233970) This
>> functionality is requested by a prominent API partner
>>
>> Ergonomics
>>
>> There is currently no way to detect feature support before attempted
>> usage; see
>> https://docs.google.com/document/d/1RRlGQharWVnmxKTomfKhNiaeE31L7iXHeXVfifOvwJA/edit?pli=1#heading=h.vu2lz7aeddz6
>>
>> Activation
>>
>> Developers can make immediate use of this API enhancement.
>>
>> Security
>>
>> This feature was designed from the ground-up to adhere to the strictest
>> usable security measures possible, as an incremental enhancement of
>> existing web platform APIs. See the design document for details.
>>
>> WebView application risks
>>
>> None
>>
>> Debuggability
>>
>> Existing mechanisms support debugging fullscreen and popup window open
>> requests.
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> No. An existing automated/manual WPT covers the ability to open
>> cross-screen popups . We aim to
>> extend test coverage for this specific scenario soon <
>> https://crbug.com/1323361>.
>>
>> DevTrial instructions
>>
>> https://github.com/w3c/window-placement/blob/main/HOWTO.md
>>
>> Flag name
>>
>> --enable-blink-features=WindowPlacement
>>
>> Requires code in //chrome?
>>
>> True -
>> https://docs.google.com/spreadsheets/d/1QV4SW4JBG3IyLzaonohUhim7nzncwK4ioop2cgUYevw/edit#gid=0=34:34
>>
>> Tracking bug
>>
>> https://crbug.com/1233970
>>
>> Launch bug
>>
>> https://crbug.com/1315615
>>
>> Sample links
>>
>> https://michaelwasserman.github.io/window-placement-demo/
>>
>> (See DevTrial instructions)
>>
>> Estimated milestones
>>
>> DevTrial on desktop: 102
>>
>> Shipping on desktop: 103
>>
>> Anticipated spec changes
>>
>> No changes anticipated that would introduce web compat/interop risk
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5173162437246976
>>
>> Links to previous Intent discussions
>>
>> Intents for the Multi-Screen Window Placement API:
>>
>>-
>>
>>I2P: <
>>https://groups.google.com/a/chromium.org/g/blink-dev/c/X6rEbWvU7cI>
>>-
>>
>>I2E1: <
>>https://groups.google.com/a/chromium.org/g/blink-dev/c/C6xw8i1ZIdE>
>>-
>>
>>I2E2: <
>>https://groups.google.com/a/chromium.org/g/blink-dev/c/jznxQK1U8ZQ>
>>-
>>
>>I2S: <
>>https://groups.google.com/a/chromium.org/g/blink-dev/c/i6Zoc7jU0dM>
>>
>>

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

[blink-dev] Re: FYI: Remove the service worker requirement for WebAPKs

2022-05-25 Thread Ella Ge

Launch bug: crbug.com/1325327
On Wednesday, May 25, 2022 at 5:54:58 PM UTC-4 Ella Ge wrote:

> Hi blink-dev,
>
> We are experimenting with removing the service worker requirement for 
> installing PWAs on Android. Websites will no longer need to have service 
> worker and offline support to be installed.
>
> Context:
> Chrome for Android offers to install a website when the site meets the 
> install-criterias .
> The Mobile Web Install team is intending to move the two requirements: 
> (1) a Web App Manifest populated with a particular set of fields, and (2) 
> an active service worker that is able to issue an HTTP 200 response when no 
> network connectivity is available.
>
> In particular, the service worker requirement has led to a number of 
> websites implementing otherwise empty, non-functional service workers, 
> which slows down the Web.
>
> We are running the experiment of removing the service worker 
> requirement on Canary/Dev on M103 and planning to roll out to Beta/Stable.
>
> -- 
> Ella Ge
>

-- 
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/2a482721-13b2-4499-8031-ea1b2f6ea5f4n%40chromium.org.

[blink-dev] FYI: Remove the service worker requirement for WebAPKs

2022-05-25 Thread Ella Ge

Hi blink-dev,

We are experimenting with removing the service worker requirement for
installing PWAs on Android. Websites will no longer need to have service
worker and offline support to be installed.

Context:
Chrome for Android offers to install a website when the site meets the
install-criterias .
The Mobile Web Install team is intending to move the two requirements: (1)
a Web App Manifest populated with a particular set of fields, and (2) an
active service worker that is able to issue an HTTP 200 response when no
network connectivity is available.

In particular, the service worker requirement has led to a number of
websites implementing otherwise empty, non-functional service workers,
which slows down the Web.

We are running the experiment of removing the service worker requirement on
Canary/Dev on M103 and planning to roll out to Beta/Stable.

-- 
Ella Ge

-- 
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/CAGbAJuHOuVCFrkOPpoz1S%2BiYGQTEUpDZgOmSQSX1gm%2B11jcCRA%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

2022-05-25 Thread 'Chris Harrelson' via blink-dev

On Wed, May 25, 2022 at 1:44 PM Philip Jägenstedt 
wrote:

> It looks like the TAG was prodded, since the "2022-06-13-week"
> milestone was just added to
> https://github.com/w3ctag/design-reviews/issues/734.
>
> However, I don't think it's reasonable for us to keep waiting for the
> TAG until mid-June when this proposal already had plenty of input from
> other vendors in https://github.com/w3c/csswg-drafts/issues/6850.
>
> This API checks the synchronously available state to determine if the
> element is going to be hidden in the next frame, but it doesn't
> determine if it's really visible like Intersection Observer. That
> seems like a useful thing to have.


The useful thing is:
* Reliably detect visibility according to some basic semantics that are
common to test for (use cases listed in the issue)
* Provide a performant way to detect content-visibility:hidden


> However, the bits involving inert
> and aria-hidden do seem a bit out of place for something called
> isVisible, to me.
>

These two are no longer part of the proposal.

Alex, can you simulate the TAG and give some suggestions for what
> names they should suggest? isHidden() is the first that comes to mind
> for me.


> Best regards,
> Philip
>
> On Wed, May 25, 2022 at 5:43 PM Alex Russell 
> wrote:
> >
> > The TAG has not substantively commented on this one, and I'd expect them
> to raise some concerns. For instance, this is a synchronous method, but
> we've explicitly built Intersection Observers as an async mechansim for
> cheaply computing *true* visibility, whereas this API only checks some
> current CSS properties (with options). This seems to be poorly integrated,
> and I'd have expected the TAG to at least suggest a different name.
> >
> > Have you considered an OT? Or prodded the TAG?
> >
> > Best Regards,
> >
> > Alex
> >
> > On Wednesday, May 25, 2022 at 1:40:50 AM UTC-7 Yoav Weiss wrote:
> >>
> >> LGTM2
> >>
> >> On Friday, May 20, 2022 at 9:44:11 PM UTC+2 Dave Tapuska wrote:
> >>>
> >>> Ya I only ran into this when investigating how visibility really
> works. Such as visibilityChanged events and document.visibilityState do not
> change for a hidden iframe. (which I guess is correct based on its
> definition, because those are about the tab being in the foreground or
> not). The only problem I have with this definition is that the CSS spec
> declares it as "rendered" and if someone is considering that as pixels on
> the display that isn't quite correct.
> >>>
> >>> I did find enough stack overflow articles about people asking about
> interactions with the parent document. I don't think making it work for
> same origin iframes vs cross origin iframes is something that would give
> much benefit.
> >>>
> >>> dave.
> >>>
> >>> On Fri, May 20, 2022 at 2:39 PM Joey Arhar 
> wrote:
> 
>  > Oh that is what was debated here
> 
>  I think that the use of "document" there was about being in the
> viewport and being painted, not about iframes.
> 
>  Currently, isVisible doesn't look at parent iframes. I don't think
> there's anything wrong with adding that functionality for LocalFrames, but
> doing so for RemoteFrames would probably have security/privacy
> considerations.
> 
>  On Thu, May 19, 2022 at 5:17 PM Dave Tapuska 
> wrote:
> >
> > So how does this method work for iframes that have their visibility
> hidden? Is it intended to work for that?
> >
> > 
> >  
> > 
> >
> > div's isVisible will always be true. Perhaps isVisible needs a
> caveat that it only works for the current document. Oh that is what was
> debated here.
> >
> > dave.
> >
> > On Thu, May 19, 2022 at 6:52 PM Mike Taylor 
> wrote:
> >>
> >> Given the CSSWG resolution in
> https://github.com/w3c/csswg-drafts/issues/7274#issuecomment-1130214343,
> LGTM1 to ship assuming we're not shipping `checkInert` with the rest.
> >>
> >> Thanks for addressing Mozilla's feedback.
> >>
> >> On 5/5/22 4:26 PM, Joey Arhar wrote:
> >>
> >> > Can you ask for signals?
> >>
> >> https://github.com/mozilla/standards-positions/issues/634
> >> https://lists.webkit.org/pipermail/webkit-dev/2022-May/032218.html
> >>
> >> On Wed, May 4, 2022 at 3:02 AM Yoav Weiss 
> wrote:
> >>>
> >>>
> >>>
> >>> On Wednesday, May 4, 2022 at 1:08:11 AM UTC+2 Joey Arhar wrote:
> 
>  Contact emails
> 
>  jar...@chromium.org
> 
>  Explainer
> 
> 
> https://github.com/WICG/display-locking/blob/main/explainers/isvisible.md
> 
>  Specification
> 
>  https://drafts.csswg.org/cssom-view/#dom-element-isvisible
> 
>  Summary
> 
>  Element.isVisible() returns true if the element is visible, and
> false if it is not. It checks a variety of factors that would make an
> element invisible, including display:none, visibility, content-visibility,
> and

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

2022-05-25 Thread Philip Jägenstedt

It looks like the TAG was prodded, since the "2022-06-13-week"
milestone was just added to
https://github.com/w3ctag/design-reviews/issues/734.

However, I don't think it's reasonable for us to keep waiting for the
TAG until mid-June when this proposal already had plenty of input from
other vendors in https://github.com/w3c/csswg-drafts/issues/6850.

This API checks the synchronously available state to determine if the
element is going to be hidden in the next frame, but it doesn't
determine if it's really visible like Intersection Observer. That
seems like a useful thing to have. However, the bits involving inert
and aria-hidden do seem a bit out of place for something called
isVisible, to me.

Alex, can you simulate the TAG and give some suggestions for what
names they should suggest? isHidden() is the first that comes to mind
for me.

Best regards,
Philip

On Wed, May 25, 2022 at 5:43 PM Alex Russell  wrote:
>
> The TAG has not substantively commented on this one, and I'd expect them to 
> raise some concerns. For instance, this is a synchronous method, but we've 
> explicitly built Intersection Observers as an async mechansim for cheaply 
> computing *true* visibility, whereas this API only checks some current CSS 
> properties (with options). This seems to be poorly integrated, and I'd have 
> expected the TAG to at least suggest a different name.
>
> Have you considered an OT? Or prodded the TAG?
>
> Best Regards,
>
> Alex
>
> On Wednesday, May 25, 2022 at 1:40:50 AM UTC-7 Yoav Weiss wrote:
>>
>> LGTM2
>>
>> On Friday, May 20, 2022 at 9:44:11 PM UTC+2 Dave Tapuska wrote:
>>>
>>> Ya I only ran into this when investigating how visibility really works. 
>>> Such as visibilityChanged events and document.visibilityState do not change 
>>> for a hidden iframe. (which I guess is correct based on its definition, 
>>> because those are about the tab being in the foreground or not). The only 
>>> problem I have with this definition is that the CSS spec declares it as 
>>> "rendered" and if someone is considering that as pixels on the display that 
>>> isn't quite correct.
>>>
>>> I did find enough stack overflow articles about people asking about 
>>> interactions with the parent document. I don't think making it work for 
>>> same origin iframes vs cross origin iframes is something that would give 
>>> much benefit.
>>>
>>> dave.
>>>
>>> On Fri, May 20, 2022 at 2:39 PM Joey Arhar  wrote:

 > Oh that is what was debated here

 I think that the use of "document" there was about being in the viewport 
 and being painted, not about iframes.

 Currently, isVisible doesn't look at parent iframes. I don't think there's 
 anything wrong with adding that functionality for LocalFrames, but doing 
 so for RemoteFrames would probably have security/privacy considerations.

 On Thu, May 19, 2022 at 5:17 PM Dave Tapuska  wrote:
>
> So how does this method work for iframes that have their visibility 
> hidden? Is it intended to work for that?
>
> 
>  
> 
>
> div's isVisible will always be true. Perhaps isVisible needs a caveat 
> that it only works for the current document. Oh that is what was debated 
> here.
>
> dave.
>
> On Thu, May 19, 2022 at 6:52 PM Mike Taylor  
> wrote:
>>
>> Given the CSSWG resolution in 
>> https://github.com/w3c/csswg-drafts/issues/7274#issuecomment-1130214343, 
>> LGTM1 to ship assuming we're not shipping `checkInert` with the rest.
>>
>> Thanks for addressing Mozilla's feedback.
>>
>> On 5/5/22 4:26 PM, Joey Arhar wrote:
>>
>> > Can you ask for signals?
>>
>> https://github.com/mozilla/standards-positions/issues/634
>> https://lists.webkit.org/pipermail/webkit-dev/2022-May/032218.html
>>
>> On Wed, May 4, 2022 at 3:02 AM Yoav Weiss  wrote:
>>>
>>>
>>>
>>> On Wednesday, May 4, 2022 at 1:08:11 AM UTC+2 Joey Arhar wrote:

 Contact emails

 jar...@chromium.org

 Explainer

 https://github.com/WICG/display-locking/blob/main/explainers/isvisible.md

 Specification

 https://drafts.csswg.org/cssom-view/#dom-element-isvisible

 Summary

 Element.isVisible() returns true if the element is visible, and false 
 if it is not. It checks a variety of factors that would make an 
 element invisible, including display:none, visibility, 
 content-visibility, and opacity.

 Blink component

 Blink>DOM

 TAG review

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

 TAG review status

 Pending

 Risks

 Interoperability and Compatibility

 This feature is not particularly contentious or complicated, but

[blink-dev] Re: Intent to Experiment: Increased max nesting level for setTimeout(0)

2022-05-25 Thread Etienne Pierre-doray

Hi all,

I'm sharing an update with results of the experiments over 21 days on
Chrome Beta M102.

The results below are mostly small percentages changes, and the finch
guidelines

 says to trust results on Stable. Given no issue have been raised AFAIK I
would like to roll out a 1% finch experiment on Stable and I'm wondering
what would be the required steps to do this (besides flipping boxes on the
launch crbug.com/1298967 ) without amending what
the spec
 says
just yet.

The experiment MaxUnthrottledTimeoutNestingLevel

has been running on canary/dev/beta M101 and M102.

Another experiment SetTimeoutZeroWithoutClamping 
which removes setTimeout(,0) clamping to 1 ms is running at Enabled(25%)
and Default(50%) on Beta. Analyzing the results for both experiments
together makes sense because our goal is to avoid delayed tasks for
immediate setTimeout()s.

MaxUnthrottledTimeoutNestingLevel (50% enabled / 50% control) +
SetTimeoutZeroWithoutClamping (Default + Enabled is 75%)

Finch Win

,

No impact on Guiding Metrics

Finch Mac

-15.85% Time To Paint For Each Ad Frame @ 95%ile 2-diamonds

Finch Android

-1.78% First Input Delay @ 99%ile 1-diamonds

-0.74% Time to Largest Contentful Paint @ 99%ile 1-diamonds

-0.79% Cumulative Layout Shift @ 95%ile 2-diamonds

-1.45 / 1.26% Startup Time @ 95 / 99%ile 1 / 2-diamonds

+1.93% Scroll Latency Count 1-diamonds

+0.32% Memory: Renderer@ 50%ile 1-diamonds

MaxUnthrottledTimeoutNestingLevel ignoring SetTimeoutZeroWithoutClamping

Note: Results here are less interesting since our goal is to avoid delayed
tasks for immediate setTimeout()s, which is only achieved under
SetTimeoutZeroWithoutClamping.

Finch Win

+1.73% Time to First Contentful Paint @ 95%ile 2-diamonds

-1.28% Frame Drawing Interval @ 95%ile 1-diamonds

-1.44% Startup Time @ 99%ile 1-diamonds

Note: the downside of experimenting on Stable is that the intersection of
both 1% experiments is very small and we probably won't be able to analyze
results alongside before SetTimeoutZeroWithoutClamping ships (this should
happen soon though).

Maybe a console warning message if we hit the nesting level that we plan to
> increase? I'm not sure how effective that would be in helping get folks to
> try it.
>
I'm trying this out here
.

On Wed, Mar 30, 2022 at 2:19 PM Scott Haseley  wrote:

> On Wed, Mar 30, 2022 at 10:41 AM Etienne Pierre-doray <
> etien...@chromium.org> wrote:
>
>> Thanks!
>>>
>>> What's the plan for finding sites this breaks? Monitor bug reports? Or
>>> is there something more proactive we could do?
>>>
>> I'm thinking about bug reports and guardian metrics. shaseley@ might
>> have additional insight from running a similar experiment
>> crbug.com/1263190
>>
>
> Yeah that's what I was thinking; that's the approach we're taking for
> removing setTimeout(0) 1 ms clamping. It would be helpful if devs could try
> this out and report issues (it's enabled behind a flag
> ).
> Maybe a console warning message if we hit the nesting level that we plan to
> increase? I'm not sure how effective that would be in helping get folks to
> try it.
>
> On Wed, Mar 30, 2022 at 6:00 AM Yoav Weiss  wrote:
>>
>>> LGTM to experiment M101-102 inclusive
>>> Thanks for working on this!!
>>> What's the plan for finding sites this breaks? Monitor bug reports? Or
>>> is there something more proactive we could do?
>>>
>>> On Monday, March 28, 2022 at 9:36:30 PM UTC+2 Etienne Pierre-doray wrote:
>>>
 Contact emailsetien...@chromium.org

 ExplainerNone

 Specification
 https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html

 Design docs

 https://docs.google.com/document/d/1boT0k8BQjl7mXXzvI9SdN4XJPSza27vE8T0CNxmMhCI

 Summary

 Increase the nesting threshold before which setTimeout(..., <4ms) start
 being clamped, from 5 to 100. setTimeout(..., 0) is commonly used to break
 down long Javascript tasks and let other internal tasks run, which prevents
 the browser from hanging. setTimeouts and setIntervals with an interval <
 4ms are not clamped as aggressively as they were before. This improves
 short horizon performance, but websites

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

2022-05-25 Thread Alex Russell

I'd like to see an explainer and completed TAG review before moving 
forward. Could this perhaps be going to OT instead?

On Wednesday, May 25, 2022 at 3:44:22 AM UTC-7 Emilio Cobos Alvarez wrote:

> On 5/25/22 09:38, Manuel Rego Casasnovas wrote:
> > There are these tests for ":modal":
> > * http://http://wpt.live//css/selectors/modal-pseudo-class.html
> > *
> > http://
> http://wpt.live//css/selectors/invalidation/modal-pseudo-class-in-has.html
> > 
> > They are for , but it looks there are no tests for the
> > fullscreen case.
>
> It isn't clear from the resolution[1] that this should apply to 
> fullscreen, and it doesn't seem like WebKit's implementation does that 
> (it seems a bit weird that it would since fullscreen at least in Gecko 
> isn't modal / doesn't make the rest of the page inert...).
>
> I commented on the spec issue about this.
>
> -- Emilio
>
> [1]: 
> https://github.com/w3c/csswg-drafts/issues/6965#issuecomment-1118033655

-- 
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/36e33354-41ab-4020-891a-ef83a67f6b9en%40chromium.org.

Re: [blink-dev] Intent to Ship: CSS object-view-box

2022-05-25 Thread slightlyoff via Chromestatus

Reserved LGTM1. I'm concerned that the TAG review was filed late and has not 
resolved. Our process depends on folks getting good guidance from senior 
engineers with a wide view of the platform and the connections between parts. 
The only reason I'm not blocking this one until the TAG review finishes is the 
CSS-centric nature of the feature, but I would not expect to be approving 
another feature that doesn't have either an explainer by the proposers or a 
completed TAG review from this team in future.

-- 
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/dfbfb705dfd828c2%40google.com.

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

2022-05-25 Thread Alex Russell

The TAG has not substantively commented on this one, and I'd expect them to 
raise some concerns. For instance, this is a synchronous method, but we've 
explicitly built Intersection Observers as an async mechansim for cheaply 
computing *true* visibility, whereas this API only checks some current CSS 
properties (with options). This seems to be poorly integrated, and I'd have 
expected the TAG to at least suggest a different name.

Have you considered an OT? Or prodded the TAG?

Best Regards,

Alex

On Wednesday, May 25, 2022 at 1:40:50 AM UTC-7 Yoav Weiss wrote:

> LGTM2
>
> On Friday, May 20, 2022 at 9:44:11 PM UTC+2 Dave Tapuska wrote:
>
>> Ya I only ran into this when investigating how visibility really works. 
>> Such as visibilityChanged events and document.visibilityState do not change 
>> for a hidden iframe. (which I guess is correct based on its definition, 
>> because those are about the tab being in the foreground or not). The only 
>> problem I have with this definition is that the CSS spec declares it as 
>> "rendered" and if someone is considering that as pixels on the display that 
>> isn't quite correct.
>>
>> I did find enough stack overflow articles about people asking about 
>> interactions with the parent document. I don't think making it work for 
>> same origin iframes vs cross origin iframes is something that would give 
>> much benefit. 
>>
>> dave.
>>
>> On Fri, May 20, 2022 at 2:39 PM Joey Arhar  wrote:
>>
>>> > Oh that is what was debated here 
>>> 
>>>
>>> I think that the use of "document" there was about being in the viewport 
>>> and being painted, not about iframes.
>>>
>>> Currently, isVisible doesn't look at parent iframes. I don't think 
>>> there's anything wrong with adding that functionality for LocalFrames, but 
>>> doing so for RemoteFrames would probably have security/privacy 
>>> considerations.
>>>
>>> On Thu, May 19, 2022 at 5:17 PM Dave Tapuska  
>>> wrote:
>>>
 So how does this method work for iframes that have their visibility 
 hidden? Is it intended to work for that?

 
  
 

 div's isVisible will always be true. Perhaps isVisible needs a caveat 
 that it only works for the current document. Oh that is what was debated 
 here 
 
 .

 dave.

 On Thu, May 19, 2022 at 6:52 PM Mike Taylor  
 wrote:

> Given the CSSWG resolution in 
> https://github.com/w3c/csswg-drafts/issues/7274#issuecomment-1130214343, 
> LGTM1 to ship assuming we're not shipping `checkInert` with the rest.
>
> Thanks for addressing Mozilla's feedback.
>
> On 5/5/22 4:26 PM, Joey Arhar wrote:
>
> > Can you ask for signals? 
>
> https://github.com/mozilla/standards-positions/issues/634
> https://lists.webkit.org/pipermail/webkit-dev/2022-May/032218.html
>
> On Wed, May 4, 2022 at 3:02 AM Yoav Weiss  
> wrote:
>
>>
>>
>> On Wednesday, May 4, 2022 at 1:08:11 AM UTC+2 Joey Arhar wrote:
>>
>>> Contact emails jar...@chromium.org
>>>
>>> Explainer 
>>> https://github.com/WICG/display-locking/blob/main/explainers/isvisible.md
>>>
>>> Specification 
>>> https://drafts.csswg.org/cssom-view/#dom-element-isvisible
>>>
>>> Summary 
>>>
>>> Element.isVisible() returns true if the element is visible, and 
>>> false if it is not. It checks a variety of factors that would make an 
>>> element invisible, including display:none, visibility, 
>>> content-visibility, 
>>> and opacity.
>>>
>>>
>>> Blink component Blink>DOM 
>>> 
>>>
>>> TAG review https://github.com/w3ctag/design-reviews/issues/734
>>>
>>> TAG review status Pending
>>>
>>> Risks 
>>>
>>>
>>> Interoperability and Compatibility 
>>>
>>> This feature is not particularly contentious or complicated, but is 
>>> mostly useful in the presence of content-visibility.
>>>
>>>
>>> Gecko: No signal
>>>
>>> WebKit: No signal
>>>
>>
>> Can you ask for signals?
>>  
>>
>>>
>>> Web developers: No signals
>>>
>>
>> Would be good to gather signals here as well.
>>  
>>
>>>
>>> Other signals:
>>>
>>> Ergonomics 
>>>
>>> This feature could be used in tandem with content-visibility or 
>>> details elements. Usage of this API will not make it hard for Chrome to 
>>> maintain good performance.
>>>
>>>
>>> Activation 
>>>
>>> This feature is easy to feature detect and polyfill.
>>>
>>>
>>> Security 
>>>
>>> I have no security risks/considerations for this feature.
>>>
>>>
>>> WebView application risks 
>>>
>>> Does this

Re: [blink-dev] Re: Intent to Ship: Subresource loading with Web Bundles

2022-05-25 Thread Alex Russell

There are high-scale operational challenges to distributing content 
optimally in many scenarios (e.g., Store packaged first-run or 
out-of-the-box-experiences) that need more than what Service Workers alone 
can provide. We are positive about this technology because it can help 
address those problems and open up new product opportunities (that we 
cannot say more about).

Best Regards,

Alex

On Tuesday, May 24, 2022 at 10:26:28 AM UTC-7 bema...@microsoft.com wrote:

> >>  You could have used a service worker and cache things in order to get 
> the same thing, combined with progressive web applications for 
> installability.
>
> This is true, but I think ergonomics of an encapsulated page/application 
> make it easier to reason about for very large applications. Maintaining the 
> service worker and the cache at scale can become a barrier to entry for 
> some developers and applications.
>
> On Tuesday, May 24, 2022 at 10:12:33 AM UTC-7 PhistucK wrote:
>
>> Not that I am against, but does this unlock previously locked 
>> opportunities in the specific examples you just mentioned?
>> You could have used a service worker and cache things in order to get the 
>> same thing, combined with progressive web applications for installability.
>>
>> ☆*PhistucK*
>>
>>
>> On Tue, May 24, 2022 at 4:35 PM 'Ben Mathwig' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Microsoft has a strong interest in seeing this feature ship. We believe 
>>> that sub-resource bundling is opening the door to a new way of shipping and 
>>> delivering offline web applications, changing the traditional definition of 
>>> “web application”.
>>>
>>> Here are some ways Microsoft products can take advantage of this:
>>>
>>> *PowerApps*
>>>
>>> Microsoft PowerApps allows a developer to author an application and 
>>> deploy to iOS, Android, and the web. The first two platforms allow 
>>> applications to be deployed and used when the device is offline, but the 
>>> latter is currently not “installable” on the device. Web bundling could 
>>> unlock the capability for a web application to be “installed” on a device 
>>> to operate offline.
>>>
>>> *Office Online*
>>>
>>> Office productivity web applications are a perfect example of 
>>> applications that could benefit from a packaged bundle of application 
>>> resources. Combined with local storage APIs, this could help developers 
>>> reach communities that have little to no network connectivity.
>>>
>>>  
>>>
>>> While there have been concerns brought up by the community, we welcome 
>>> the opportunity to collaborate on addressing these issues in the next 
>>> iteration of this project. We feel confident we can resolve them in a way 
>>> that preserves the integrity of the open web.
>>>
>>>
>>> Ben Mathwig
>>> Senior Product Manager
>>> Microsoft Edge Web Platform
>>>
>>>
>>> On Sunday, May 22, 2022 at 6:28:50 PM UTC-7 deno...@chromium.org wrote:
>>>
 Hello

 I am sharing the feedback from the Origin Trial with 12 participants:

- 

10 of them responded "Extremely likely" to "How likely are you to 
keep using this feature?" 
- 

Qualitative feedback:


- 

"I'm very excited about the CSP interpretation change rolling out 
in M92"
- 

"looking forward to the CSP fix!"
- 

"I'm very glad you're working on this!"
- 

"This feature is great! I'd love to see it fully launch"

 Daisuke


 On Sat, May 21, 2022 at 5:38 AM 'Jeff Kaufman' via blink-dev <
 blin...@chromium.org> wrote:

> Thanks, Otto!  As someone who used to work on mod_pagespeed I wanted 
> to give a bit more context on how web bundles improve on what is possible 
> for automatic site optimization tools like mod_pagesped:
>
> 1. Combining many small images into a single file otherwise requires 
> spriting (with css to identify which area of the image you want for each 
> usage) and mod_pagespeed's ability to do that automatically 
> (sprite_images 
> filter ) is 
> limited.  It needs to understand the site's css and the publisher needs 
> to 
> have already set their css up to minimize the changes required.  With 
> bundles it is much simpler: you put all the tiny image files in the 
> bundle, 
> and you rewrite the URLs to point into the bundle.
>
> 2. Combining many small css or js files into a single file (
> combine_css , 
> combine_js ) 
> requires hacks to prevent invalid css or js from breaking the rest.  It's 
> reasonably common that publishers will have  href=invalid.css> that doesn't parse, and if you blindly concatenate with 
> other css you will change the

Re: [blink-dev] Re: Intent to Prototype: Reduce fingerprinting in the Accept-Language header and support for HTTP Variants

2022-05-25 Thread Daniel Bratell

I am happy to see you working on reducing the fingerprinting surface on 
the web, and this seems like a worthwhile place get rid of some entropy. 
Though, just like some other comments here suggest, I also suspect that 
just a single language might not be enough.


There is a disparity between the languages that are primary languages 
for people on this planet, and the languages used for content on the 
web. The web has a dominance of languages that are shared by many, such 
as English, Chinese, Russian, Spanish and Persian. If someone's primary 
language is a smaller language they will face a couple of bad options:


1. Use a common second language as primary language, and miss out on 
content in the language they understand best.


2. Accept that they will get some default language on pages and hope 
that is one they can read.


3. Hope that every multi-language site they visit is rewritten to 
negotiate a language.


I think expanding from one to two languages will be enough to cover many 
of the use cases, and I don't think that will add much information 
(TBD). Here in Sweden, I expect a majority to have [sv, en] for 
instance, in Catalonia it might be [ca, es] and so on.


A compromise might be to always keep the first "common" language though 
it adds the problem of determining what is a "common" language.


I'm a bit concerned that this might cause issues that will be invisible 
for those that live entirely on the English speaking web so I hope you 
take care to avoid such biases.


/Daniel

On 2022-05-23 16:05, Victor Tan wrote:
Yea, we definitely will collect metrics on those performance. thanks 
for your comments.


On Sunday, May 22, 2022 at 2:08:02 PM UTC-4 Harald Alvestrand wrote:

I hope you will be recording the percentage of extra round trips,
split on main language preference. This may be a disproportionate
impact on people without English as their first language.



On Sun, May 22, 2022 at 6:15 PM Victor Tan
 wrote:

The browser will only do language negotiation if necessary.
Yea, you are right, it would take an extra round trip in some
cases. We also plan to save some selections in memory to avoid
introducing large latency.

On Sunday, May 22, 2022 at 12:11:23 PM UTC-4 Harald Alvestrand
wrote:

So one extra round trip per page?


On Sun, May 22, 2022 at 5:31 PM Victor Tan
 wrote:

Hi Harald,
The browser will do language negotiation with resend
the request (only happen once) with accept-language:en
to get a result with English page.

Victor

On Saturday, May 21, 2022 at 8:38:47 AM UTC-4 Harald
Alvestrand wrote:

So if my config is (no, en), the site supports
(fr, en), the first response will be in French
with a Vary:(fr, en) header? Will the browser
automatically detect that a better alternative is
available and re-ask, imposing an extra RTT, or
will the result remain French?

fre. 20. mai 2022, 19:11 skrev 'Victor Tan' via
blink-dev :

NOTES: This intend won't implement Variants in
the HTTP cache. It only focus on using
Variants http header as a support-languages
head which in the definition on section 2

.

On Thursday, May 19, 2022 at 10:20:29 AM UTC-4
vict...@chromium.org wrote:


Contact emails

vict...@chromium.org, abe...@chromium.org


Explainer


https://github.com/Tanych/accept-language



Specification

Variants header:

https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06




Summary

Support the HTTP Variants header and
implement the reduction of information
that could be used for fingerprinting in
the Accept-Language header, so that Chrome
only sends the user’s most preferred
language in the Accept-Language header on
the initial request.


Blink component

[blink-dev] Intent to Ship: MediaTrackConstraintSet.displaySurface

2022-05-25 Thread 'Elad Alon' via blink-dev

Contact emailselada...@chromium.org

Explainer
https://docs.google.com/document/d/1uI51R4YfFQtfiDTw1KfnLqzIu45OgxhYoUT7khlhmwQ/edit?usp=sharing

Specificationhttps://github.com/w3c/mediacapture-screen-share/pull/186/files

Summary

When getDisplayMedia() is called, the browser offers the user a choice of
display surfaces - tabs, windows and monitors. Using the displaySurface
constraint, the Web application may now hint to the browser if it prefers
that a certain surface type be more prominently offered to the user.

Blink componentBlink

TAG reviewN/A. This is just an addition of a single flag to an existing
dictionary, following well-known patterns.

TAG review statusNot applicable

Risks

Interoperability and Compatibility

*Gecko*: Positive (https://github.com/mozilla/standards-positions/issues/642)
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/mediacapture-screen-share. This is implicit
support, so I'd consider it POSITIVE even though, as of the time of this
writing, the official request for position has not yet been answered.

*WebKit*: Positive (
https://lists.webkit.org/pipermail/webkit-dev/2022-May/032253.html)
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/mediacapture-screen-share. This is implicit
support, so I'd consider it POSITIVE even though, as of the time of this
writing, the official request for position has not yet been answered.

*Web developers*: Positive See Appendix I of the internal design doc:
https://docs.google.com/document/d/1U_aNptMZuYFuFWu7leq43V3hqOQ9zMEumG3x413q2pY/edit#heading=h.693jj8mh4gkw

*Other signals*:

WebView application risks

N/A

Debuggability

N/A

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

Supported on all platforms that support getDisplayMedia. Namely, all
desktop platforms.

Is this feature fully tested by web-platform-tests

?No

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1224912

Estimated milestones

No milestones specified

Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/bVVEn-TOTYs

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/a/chromium.org/d/msgid/blink-dev/CAMO6jDOWjwDfQ9QWLLiQbu3cspjNevQskGjVYFb-RiYLbQMGqg%40mail.gmail.com.

[blink-dev] Intent to Prototype: MediaTrackConstraintSet.displaySurface

2022-05-25 Thread 'Elad Alon' via blink-dev

Contact emailselada...@chromium.org

Explainer
https://docs.google.com/document/d/1uI51R4YfFQtfiDTw1KfnLqzIu45OgxhYoUT7khlhmwQ/edit?usp=sharing

Specificationhttps://github.com/w3c/mediacapture-screen-share/pull/186/files

Summary

Blink componentBlink

Motivation

Less friction for user journeys that are tied to specific pairings between
the capturing Web application and a specific capture source type.

Initial public proposal
https://github.com/w3c/mediacapture-screen-share/issues/184

TAG reviewN/A. This is just an addition of a single flag to an existing
dictionary, following well-known patterns.

TAG review statusNot applicable

Risks

Interoperability and Compatibility

*Web developers*: Positive
See Appendix I of the internal design doc:
https://docs.google.com/document/d/1U_aNptMZuYFuFWu7leq43V3hqOQ9zMEumG3x413q2pY/edit#heading=h.693jj8mh4gkw

*Other signals*:

WebView application risks

N/A

Debuggability

N/A

Is this feature fully tested by web-platform-tests

?No

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1224912

Estimated milestones

No milestones specified

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

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/a/chromium.org/d/msgid/blink-dev/CAMO6jDP-jOA81pMDKWBqE%2Bw0rR7mvYHSeU9mtQLpddJepw3%3Dsg%40mail.gmail.com.

[blink-dev] Intent to Ship: MediaTrackSupportedConstraints.suppressLocalAudioPlayback

2022-05-25 Thread 'Elad Alon' via blink-dev

Contact emailselada...@chromium.org

Explainer
https://docs.google.com/document/d/1OmuV1W4f2UvToeNxUVGHv8NcFuL63r94gWwz9i_-VBc/edit?usp=sharing

Specificationhttps://github.com/w3c/mediacapture-screen-share/pull/164/files

Summary

Consider a Web application APP which is display-capturing a tab TAB. We add
a mechanism by which APP may control whether the audio playing in TAB would
be played out of the user’s local speakers.

Blink componentBlink

TAG reviewN/A. This is just an addition of a single flag to an existing
dictionary, following well-known patterns.

TAG review statusNot applicable

Risks

Interoperability and Compatibility

*Gecko*: Positive (https://github.com/mozilla/standards-positions/issues/641)
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/mediacapture-screen-share. This is implicit
support, so I'd consider it POSITIVE even though, as of the time of this
writing, the official request for position has not yet been answered.

*WebKit*: Positive (
https://lists.webkit.org/pipermail/webkit-dev/2022-May/032252.html)
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/mediacapture-screen-share. This is implicit
support, so I'd consider it POSITIVE even though, as of the time of this
writing, the official request for position has not yet been answered.

*Web developers*: Positive

- This was requested by multiple Web-dev teams inside of Google.
- External developers have asked for a different change in Chrome, which
we'll be able to uncontroversially affect only once this API surface is
shipped - see crbug.com/1317964 for some details.

*Other signals*:

WebView application risks

N/A

Debuggability

N/A

Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?No. Supported on all
platforms that support getDisplayMedia. (Namely, all desktop platforms.)

Is this feature fully tested by web-platform-tests

?No

Estimated milestones

No milestones specified

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/cANVKeNMHyE

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/a/chromium.org/d/msgid/blink-dev/CAMO6jDPkdMUyPA92uw0Osc6x6K%2BECvwTSU5W5jKCOrzNN8GtgA%40mail.gmail.com.

[blink-dev] Intent to Prototype: MediaTrackSupportedConstraints.suppressLocalAudioPlayback

2022-05-25 Thread 'Elad Alon' via blink-dev

Contact emailselada...@chromium.org

Explainer
https://docs.google.com/document/d/1OmuV1W4f2UvToeNxUVGHv8NcFuL63r94gWwz9i_-VBc/edit?usp=sharing

Specificationhttps://github.com/w3c/mediacapture-screen-share/pull/164/files

Summary

Consider a Web application APP which is display-capturing a tab TAB. We add
a mechanism by which APP may control whether the audio playing in TAB would
be played out of the user’s local speakers.

Blink componentBlink

Motivation

A common scenario in corporate settings is for several users to gather in a
shared physical room, and for one of them to use their laptop and VC
software to share a tab to a large monitor in that room. Often, audio is
also played out over the room’s speakers. (Because these speakers are
typically louder than the laptop’s speakers, and because this way, audio is
in-sync with the video played out over the monitor.)

Initial public proposal
https://github.com/w3c/mediacapture-screen-share/issues/161

TAG reviewN/A. This is just an addition of a single flag to an existing
dictionary, following well-known patterns.

TAG review statusNot applicable

Risks

Interoperability and Compatibility

*Web developers*: Positive * This was requested by multiple Web-dev teams
inside of Google. * External developers have asked for a different change
in Chrome, which we'll be able to uncontroversially affect only once this
API surface is shipped - see crbug.com/1317964 for some details.

*Other signals*:

WebView application risks

N/A

Debuggability

N/A

Is this feature fully tested by web-platform-tests

?No

Estimated milestones

No milestones specified

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

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/a/chromium.org/d/msgid/blink-dev/CAMO6jDM-5yC_pxXpzSrsS1JYEy%2BErih0aNehsJLvoFcf%2Bg_9Ww%40mail.gmail.com.

[blink-dev] Intent to Ship: DisplayMediaStreamConstraints.selfBrowserSurface

2022-05-25 Thread 'Elad Alon' via blink-dev

Contact emailselada...@chromium.org

Explainer
https://docs.google.com/document/d/1M63lyDHV-v6LPFzHjfsjBDMfyn075pySa3xfIRSB9zU/edit?usp=sharing

Specificationhttps://github.com/w3c/mediacapture-screen-share/pull/216/files

Summary

Hint allowing Web applications to instruct the browser whether, upon
calling getDisplayMedia(), the current tab should be excluded from the list
of tabs offered to the user.

Blink componentBlink

TAG reviewN/A. This is just an addition of a single flag to an existing
dictionary, following well-known patterns.

TAG review statusNot applicable

Risks

Interoperability and Compatibility

*Gecko*: Positive (https://github.com/mozilla/standards-positions/issues/639)
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/mediacapture-screen-share. This is implicit
support, so I'd consider it POSITIVE even though, as of the time of this
writing, the official request for position has not yet been answered.

*WebKit*: Positive (
https://lists.webkit.org/pipermail/webkit-dev/2022-May/032249.html)
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/mediacapture-screen-share. This is implicit
support, so I'd consider it POSITIVE even though, as of the time of this
writing, the official request for position has not yet been answered.

*Web developers*: Positive Interest expressed by Google Meet.

Security

The current tab is the surface most under an attacker’s control. Nudging
the user away from this risky surface is a good thing. Of course, malicious
applications can avoid using this new control, or use it to retain the old
behavior (current tab still offered). This is not a problem - it simply
means that this new surface offers no degradation in security, although not
a security feature in its own right.

WebView application risks

N/A

Debuggability

N/A

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

Supported on all platforms that support getDisplayMedia. Namely, all
desktop platforms.

Is this feature fully tested by web-platform-tests

?No

Estimated milestones

No milestones specified

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/COid122-_AE

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/a/chromium.org/d/msgid/blink-dev/CAMO6jDPgMh05sBUqVO7JS4-1Fy1B79Z59%2Bn-bVwbwHBWE%2B6orA%40mail.gmail.com.

[blink-dev] Intent to Prototype: DisplayMediaStreamConstraints.selfBrowserSurface

2022-05-25 Thread 'Elad Alon' via blink-dev

Contact emailselada...@chromium.org

Explainer
https://docs.google.com/document/d/1M63lyDHV-v6LPFzHjfsjBDMfyn075pySa3xfIRSB9zU/edit?usp=sharing

Specificationhttps://github.com/w3c/mediacapture-screen-share/pull/216/files

Summary

Hint allowing Web applications to instruct the browser whether, upon
calling getDisplayMedia(), the current tab should be excluded from the list
of tabs offered to the user.

Blink componentBlink

Motivation

Accidental self-capture is a common problem for video conferencing
software. When users accidentally choose the tab in which the VC app is
running, a Hall-of-Mirrors effect is produced, confusing users and
derailing discussions with remote users.

Initial public proposal
https://github.com/w3c/mediacapture-screen-share/issues/209

TAG reviewN/A. This is just an addition of a single flag to an existing
dictionary, following well-known patterns.

TAG review statusNot applicable

Risks

Interoperability and Compatibility

*Web developers*: Positive Interest expressed by Google Meet.

*Other signals*:

Security

WebView application risks

N/A

Debuggability

N/A

Is this feature fully tested by web-platform-tests

?No

Estimated milestones

No milestones specified

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

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/a/chromium.org/d/msgid/blink-dev/CAMO6jDN_Jd-466uDwtP-Wqag9r6gEQWM4r%3DFbdL7NsYuy1oucg%40mail.gmail.com.

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

2022-05-25 Thread 'Elad Alon' via blink-dev

Contact emailselada...@chromium.org

Explainer
https://docs.google.com/document/d/1q3oGy7hLJmdQA4ZK7QG7DnwgtcpL6oB2pqLQJ6MP1tY/edit?usp=sharing

Specificationhttps://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 componentBlink

TAG reviewN/A. This is just an addition of a single flag to an existing
dictionary, following well-known patterns.

TAG review statusNot 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/mediacapture-screen-share. This is implicit
support, so I'd consider it POSITIVE even though, as of the time of this
writing, the official request for position has not yet been answered.

*WebKit*: Positive (
https://lists.webkit.org/pipermail/webkit-dev/2022-May/032247.html)
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/mediacapture-screen-share. This is implicit
support, so I'd consider it POSITIVE even though, as of the time of this
writing, the official request for position has not yet been answered.

*Web developers*: Positive Endorsed by Google Meet.

Security

This feature can only be used by Web applications to REDUCE the amount of
private information they obtain from the user. As such, this is a net
security gain.

Debuggability

N/A

Is this feature fully tested by web-platform-tests

?No

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1329129

Estimated milestones

No milestones specified

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/zUJh3aXAC3k

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/a/chromium.org/d/msgid/blink-dev/CAMO6jDNAVkBVEAZ68YGeOu5B8SW%2Bs-d1gQTxCQ1d6hmymJthjA%40mail.gmail.com.

[blink-dev] Intent to Prototype: DisplayMediaStreamConstraints.systemAudio

2022-05-25 Thread 'Elad Alon' via blink-dev

Contact emailselada...@chromium.org

Explainer
https://docs.google.com/document/d/1q3oGy7hLJmdQA4ZK7QG7DnwgtcpL6oB2pqLQJ6MP1tY/edit?usp=sharing

Specificationhttps://github.com/w3c/mediacapture-screen-share/pull/222/files

Summary

Blink componentBlink

Motivation

User agents may offer audio to be captured alongside video, if the
application specifies {audio: true}, or maps audio to anything else that's
different from false. But not all audio is created alike. Consider
video-conferencing applications. Tab-audio is often useful, and can be
shared with remote participants. But system-audio includes participants'
own audio, and it is NOT desirable to share it back. State of the art? VC
applications can ask for "audio", use it if it's tab-audio, and discard it
otherwise. This works, but it's sub-optimal. The user is left confused. The
user wanted to share system-audio, the user was offered to share-system,
the user explicitly approved sharing system-audio - and now remote
participants are telling the user that they can't, in fact, hear the
system-audio. Now how confusing is that?! It’s better to allow applications
to ask for less - allow the application to ask for non-system audio.

Initial public proposal
https://github.com/w3c/mediacapture-screen-share/issues/219

TAG reviewN/A. This is just an addition of a single flag to an existing
dictionary, following well-known patterns.

TAG review statusNot applicable

Risks

Interoperability and Compatibility

*Web developers*: Positive Endorsed by Google Meet.

*Other signals*:

Security

This feature can only be used by Web applications to REDUCE the amount of
private information they obtain from the user. As such, this is a net
security gain.

WebView application risks

N/A

Debuggability

N/A

Is this feature fully tested by web-platform-tests

?No

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1329129

Estimated milestones

No milestones specified

Anticipated spec changes

N/A

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

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/a/chromium.org/d/msgid/blink-dev/CAMO6jDNS3OAe7dD0rfLB7tqnLrfYAkDROr6OP2qWcToexbwWFA%40mail.gmail.com.

Re: [blink-dev] Intent to Extend Origin Trial: Subresource loading with Web Bundles

2022-05-25 Thread Yoav Weiss

Thanks for clarifying that. The break in the OT provides us with a
guarantee that it has not been burnt in.


LGTM to experiment m103-m104, given the OT feedback provided on the other
thread.

On Wed, May 25, 2022 at 12:47 PM Daisuke Enomoto 
wrote:

> I would like to make it clear that the previous OT has expired in M101 and
> it's not enabled in M102. So this intent is to enable it back for 103
> through 104.
>
> Daisuke
>
> On Wed, May 25, 2022 at 12:30 PM Daisuke Enomoto 
> wrote:
>
>> Contact emails
>>
>> hay...@chromium.org, denom...@chromium.org
>>
>> Explainer
>>
>>
>> https://github.com/WICG/webpackage/blob/master/explainers/subresource-loading.md
>>
>> Specification
>>
>> https://wicg.github.io/webpackage/subresource-loading.html
>>
>> Design docs
>>
>>
>> https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/content/browser/web_package/subresource_loading_origin_trial.md
>>
>> Summary
>>
>> We sent the I2S
>> 
>> for the Subresource loading with Web Bundles on April 13th and received a
>> couple of critical feedback we should address before moving forward. While
>> we’re actively engaged with various stakeholders to address them, we
>> realized the previous OT
>> 
>> had expired in M101, which caused an unintended negative impact to the OT
>> participants in that they couldn’t continue to test their changes to use
>> the new format. Therefore, we’re sending this Intent to Extend OT to allow
>> them to check for the possibility of regressions introduced with the
>> changes. The features added in the previous OT are listed below. From the
>> implementation perspective, there is no difference between the previous OT
>> and this time.
>>
>>
>>1.
>>
>>

Re: [blink-dev] Intent to Extend Origin Trial: Subresource loading with Web Bundles

2022-05-25 Thread Daisuke Enomoto

I would like to make it clear that the previous OT has expired in M101 and
it's not enabled in M102. So this intent is to enable it back for 103
through 104.

Daisuke

On Wed, May 25, 2022 at 12:30 PM Daisuke Enomoto 
wrote:

> Contact emails
>
> hay...@chromium.org, denom...@chromium.org
>
> Explainer
>
>
> https://github.com/WICG/webpackage/blob/master/explainers/subresource-loading.md
>
> Specification
>
> https://wicg.github.io/webpackage/subresource-loading.html
>
> Design docs
>
>
> https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/content/browser/web_package/subresource_loading_origin_trial.md
>
> Summary
>
> We sent the I2S
> 
> for the Subresource loading with Web Bundles on April 13th and received a
> couple of critical feedback we should address before moving forward. While
> we’re actively engaged with various stakeholders to address them, we
> realized the previous OT
> 
> had expired in M101, which caused an unintended negative impact to the OT
> participants in that they couldn’t continue to test their changes to use
> the new format. Therefore, we’re sending this Intent to Extend OT to allow
> them to check for the possibility of regressions introduced with the
> changes. The features added in the previous OT are listed below. From the
> implementation perspective, there is no difference between the previous OT
> and this time.
>
>
>1.
>
>

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

2022-05-25 Thread Emilio Cobos Álvarez


On 5/25/22 09:38, Manuel Rego Casasnovas wrote:

There are these tests for ":modal":
* http://http://wpt.live//css/selectors/modal-pseudo-class.html
*
http://http://wpt.live//css/selectors/invalidation/modal-pseudo-class-in-has.html

They are for , but it looks there are no tests for the
fullscreen case.


It isn't clear from the resolution[1] that this should apply to 
fullscreen, and it doesn't seem like WebKit's implementation does that 
(it seems a bit weird that it would since fullscreen at least in Gecko 
isn't modal / doesn't make the rest of the page inert...).


I commented on the spec issue about this.

 -- Emilio

[1]: https://github.com/w3c/csswg-drafts/issues/6965#issuecomment-1118033655

--
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/db38fa0a-76a4-2215-b48a-ecaa7640a06e%40mozilla.com.


OpenPGP_0xE1152D0994E4BF8A.asc
Description: OpenPGP public key

Re: [blink-dev] Intent to Ship: 'blocking=rendering' attribute on scripts and style sheets

2022-05-25 Thread Yoav Weiss

Thanks for working on this!! :)

On Mon, May 23, 2022 at 9:21 PM Xiaocheng Hu 
wrote:

> (Note: The feature no longer works on preloads, compared to the original
> I2P. See explainer for details.)
>
> Contact emailsxiaoche...@chromium.org
>
> Explainer
> https://gist.github.com/xiaochengh/9404abbecdc3b45c0e9f3d5e99fbc65d#file-proposal-v3-md
>
> Specificationhttps://github.com/whatwg/html/pull/7474
>
> Summary
>
> Allows putting 'blocking=render' as an attribute and value to a

[blink-dev] Re: Intent to Prototype and Ship: Multi-Screen Window Placement: Fullscreen Companion Window

2022-05-25 Thread Yoav Weiss



On Tuesday, May 10, 2022 at 2:35:40 AM UTC+2 Mike Wasserman wrote:

> Contact emails
>
> m...@chromium.org
>
>
> Explainer
>
>
> https://github.com/w3c/window-placement/blob/main/EXPLAINER_initiating_multi_screen_experiences.md
>
> Specification
>
>
> https://github.com/w3c/window-placement/blob/main/EXPLAINER_initiating_multi_screen_experiences.md#spec-changes
>

Are there PRs that define the new processing models for this?
 

>
> Design docs
>
>
> https://docs.google.com/document/d/1RRlGQharWVnmxKTomfKhNiaeE31L7iXHeXVfifOvwJA
>
> Summary
>
> Fullscreen Companion Window allows sites to place fullscreen content and a 
> popup window on separate screens from a single user activation.
>
> This is a small requested enhancement of the Multi-Screen Window Placement 
> feature: https://chromestatus.com/feature/5252960583942144
>
> Blink component
>
> Blink>Screen>MultiScreen 
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/602#issuecomment-1121694034
>
> TAG review status
>
> Pending
>
> Risks
> Interoperability and Compatibility
>
> The main risk is that this feature fails to become an interoperable part 
> of the web platform if other browsers do not implement it. Scripted 
> attempts to open a popup window after requesting fullscreen would likely be 
> blocked by user agents that do not implement this feature, even if they 
> implement the basic Multi-Screen Window Placement API.
>
> Gecko: No signal (
> https://github.com/mozilla/standards-positions/issues/636)
>
> WebKit: No signal (
> https://lists.webkit.org/pipermail/webkit-dev/2022-May/032223.html)
>
> Web developers: Positive (
> https://bugs.chromium.org/p/chromium/issues/detail?id=1233970) This 
> functionality is requested by a prominent API partner
>
> Ergonomics
>
> There is currently no way to detect feature support before attempted 
> usage; see 
> https://docs.google.com/document/d/1RRlGQharWVnmxKTomfKhNiaeE31L7iXHeXVfifOvwJA/edit?pli=1#heading=h.vu2lz7aeddz6
>
> Activation
>
> Developers can make immediate use of this API enhancement.
>
> Security
>
> This feature was designed from the ground-up to adhere to the strictest 
> usable security measures possible, as an incremental enhancement of 
> existing web platform APIs. See the design document for details.
>
> WebView application risks
>
> None
>
> Debuggability
>
> Existing mechanisms support debugging fullscreen and popup window open 
> requests.
>
> Is this feature fully tested by web-platform-tests 
> 
> ?
>
> No. An existing automated/manual WPT covers the ability to open 
> cross-screen popups . We aim to extend 
> test coverage for this specific scenario soon .
>
> DevTrial instructions
>
> https://github.com/w3c/window-placement/blob/main/HOWTO.md
>
> Flag name
>
> --enable-blink-features=WindowPlacement
>
> Requires code in //chrome?
>
> True - 
> https://docs.google.com/spreadsheets/d/1QV4SW4JBG3IyLzaonohUhim7nzncwK4ioop2cgUYevw/edit#gid=0=34:34
>
> Tracking bug
>
> https://crbug.com/1233970
>
> Launch bug
>
> https://crbug.com/1315615
>
> Sample links
>
> https://michaelwasserman.github.io/window-placement-demo/
>
> (See DevTrial instructions)
>
> Estimated milestones
>
> DevTrial on desktop: 102
>
> Shipping on desktop: 103
>
> Anticipated spec changes
>
> No changes anticipated that would introduce web compat/interop risk 
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5173162437246976
>
> Links to previous Intent discussions
>
> Intents for the Multi-Screen Window Placement API:
>
>- 
>
>I2P: <
>https://groups.google.com/a/chromium.org/g/blink-dev/c/X6rEbWvU7cI>
>- 
>
>I2E1: <
>https://groups.google.com/a/chromium.org/g/blink-dev/c/C6xw8i1ZIdE>
>- 
>
>I2E2: <
>https://groups.google.com/a/chromium.org/g/blink-dev/c/jznxQK1U8ZQ>
>- 
>
>I2S: <
>https://groups.google.com/a/chromium.org/g/blink-dev/c/i6Zoc7jU0dM>
>
>

-- 
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/dc2f9c8b-0be8-4973-a458-9aa599252e46n%40chromium.org.

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

2022-05-25 Thread Yoav Weiss

LGTM2

On Friday, May 20, 2022 at 9:44:11 PM UTC+2 Dave Tapuska wrote:

> Ya I only ran into this when investigating how visibility really works. 
> Such as visibilityChanged events and document.visibilityState do not change 
> for a hidden iframe. (which I guess is correct based on its definition, 
> because those are about the tab being in the foreground or not). The only 
> problem I have with this definition is that the CSS spec declares it as 
> "rendered" and if someone is considering that as pixels on the display that 
> isn't quite correct.
>
> I did find enough stack overflow articles about people asking about 
> interactions with the parent document. I don't think making it work for 
> same origin iframes vs cross origin iframes is something that would give 
> much benefit. 
>
> dave.
>
> On Fri, May 20, 2022 at 2:39 PM Joey Arhar  wrote:
>
>> > Oh that is what was debated here 
>> 
>>
>> I think that the use of "document" there was about being in the viewport 
>> and being painted, not about iframes.
>>
>> Currently, isVisible doesn't look at parent iframes. I don't think 
>> there's anything wrong with adding that functionality for LocalFrames, but 
>> doing so for RemoteFrames would probably have security/privacy 
>> considerations.
>>
>> On Thu, May 19, 2022 at 5:17 PM Dave Tapuska  
>> wrote:
>>
>>> So how does this method work for iframes that have their visibility 
>>> hidden? Is it intended to work for that?
>>>
>>> 
>>>  
>>> 
>>>
>>> div's isVisible will always be true. Perhaps isVisible needs a caveat 
>>> that it only works for the current document. Oh that is what was debated 
>>> here 
>>> 
>>> .
>>>
>>> dave.
>>>
>>> On Thu, May 19, 2022 at 6:52 PM Mike Taylor  
>>> wrote:
>>>
 Given the CSSWG resolution in 
 https://github.com/w3c/csswg-drafts/issues/7274#issuecomment-1130214343, 
 LGTM1 to ship assuming we're not shipping `checkInert` with the rest.

 Thanks for addressing Mozilla's feedback.

 On 5/5/22 4:26 PM, Joey Arhar wrote:

 > Can you ask for signals? 

 https://github.com/mozilla/standards-positions/issues/634
 https://lists.webkit.org/pipermail/webkit-dev/2022-May/032218.html

 On Wed, May 4, 2022 at 3:02 AM Yoav Weiss  
 wrote:

>
>
> On Wednesday, May 4, 2022 at 1:08:11 AM UTC+2 Joey Arhar wrote:
>
>> Contact emails jar...@chromium.org
>>
>> Explainer 
>> https://github.com/WICG/display-locking/blob/main/explainers/isvisible.md
>>
>> Specification 
>> https://drafts.csswg.org/cssom-view/#dom-element-isvisible
>>
>> Summary 
>>
>> Element.isVisible() returns true if the element is visible, and false 
>> if it is not. It checks a variety of factors that would make an element 
>> invisible, including display:none, visibility, content-visibility, and 
>> opacity.
>>
>>
>> Blink component Blink>DOM 
>> 
>>
>> TAG review https://github.com/w3ctag/design-reviews/issues/734
>>
>> TAG review status Pending
>>
>> Risks 
>>
>>
>> Interoperability and Compatibility 
>>
>> This feature is not particularly contentious or complicated, but is 
>> mostly useful in the presence of content-visibility.
>>
>>
>> Gecko: No signal
>>
>> WebKit: No signal
>>
>
> Can you ask for signals?
>  
>
>>
>> Web developers: No signals
>>
>
> Would be good to gather signals here as well.
>  
>
>>
>> Other signals:
>>
>> Ergonomics 
>>
>> This feature could be used in tandem with content-visibility or 
>> details elements. Usage of this API will not make it hard for Chrome to 
>> maintain good performance.
>>
>>
>> Activation 
>>
>> This feature is easy to feature detect and polyfill.
>>
>>
>> Security 
>>
>> I have no security risks/considerations for this 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?
>>
>> This does not deprecate or change any existing APIs and does not have 
>> any risk for WebView.
>>
>>
>> Debuggability 
>>
>> This feature does not need any new debugging features.
>>
>>
>> Is this feature fully tested by web-platform-tests 
>> 
>> ? Yes
>>
>> Flag name --enable-blink-features=isVisible
>>
>> Requires code in //chrome? False
>>
>> Tracking bug 
>>

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

2022-05-25 Thread Manuel Rego Casasnovas



On 25/05/2022 08:52, Yoav Weiss wrote:
> 
> Is this feature fully tested by web-platform-tests
> 
> ?
> 
> Yes
> 
> 
> Link to the WPTs?

There are these tests for ":modal":
* http://http://wpt.live//css/selectors/modal-pseudo-class.html
*
http://http://wpt.live//css/selectors/invalidation/modal-pseudo-class-in-has.html

They are for , but it looks there are no tests for the
fullscreen case.

Cheers,
  Rego

-- 
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/64c52fb9-febb-9e08-cf2e-fd75d0ac696a%40igalia.com.

[blink-dev] Re: Intent to Ship: Region Capture

2022-05-25 Thread Yoav Weiss

Hey Jan-Ivar,

Answers below, but feel free to reach out and we can discuss offline any
further misunderstandings.

On Tue, May 24, 2022 at 8:19 PM Jan-Ivar Bruaroey  wrote:

> Thanks Yoav for taking the time to get involved with the issues. As you
> mentioned, #11 is resolved by a PR we're working to merge, which means
> there are only 2 "points of contention".
>
> I noticed performance is absent from your points of contention. which I
> think reflects great progress made in #17 in just a week, since that was a
> claim from the Chrome team earlier that I think we put to bed.
>

I don't think it's an actual point of contention, just an artifact of the
other disagreements that came up during the discussion of the different
implementation designs. The reason I didn't bring it up here is that going
with the more conservative choice of an async API enables implementations
to make all kinds of performance related tradeoffs, rather than force them
into specific ones.

>
> #48 was opened just 5 days ago when we discovered Chrome had previously
> undisclosed needs here (the spec says it cannot fail). It seems early to
> call this one (unless you're tied to a certain outcome).
>
> I find the characterization of people trying to be helpful as "back-seat
> implementation design" unfortunate, since Chome's claims to the WG were
> about implementation hardship, claiming few if any actual web developer
> benefits from their design. I think that sets the terms of conversation to
> be about implementation, and short of responding with "not our problem, we
> disagree this is hard to implement", I'm not sure what we could have said
> that wouldn't be characterized this way.
>

Apologies, but there's a difference between making helpful suggestions
about implementation options and second-guessing another implementer's
choices, characterising them as inferior
.
At some point, the best way to prove that some implementation choices are
better than others is using a competing, better implementation.

>
> I'm concerned that what Chrome would ship would not be what ends up being
> standardized, given how issues are progressing.
>

If what ends up being standardized and cemented by multiple implementations
is different from what ships in Chromium, I'm confident Chromium would
align its implementation to the standard, following other
implementation's footsteps. Making conservative and future compatible
choices (such as an async API that can fail) would help us make that
switch, if needed.

> This is not the same state we found ourselves in earlier, since some
> issues have been solved and others found. Since a major customer voiced in
> #17 they were open to any of the proposed spec alternatives,
>

I think you may want to re-read that comment
.
It essentially says that the developer constituency of this particular
feature doesn't share your views on the issues with async APIs, nor about
the confusion that call failures may cause them.

> it seems odd that the Chrome team is holding on to what amounts to minor
> design aspects
>

I can say the same about other participants in that debate. The Chrome team
in this case has an implementation of the feature that's going for it,
during which they thought long and hard about the tradeoffs of the various
approaches.

> they've been unable to defend or demonstrate much web developer benefit
> from.
>

Avoiding repeating the same argument over and over again out of respect to
everyone's time does not constitute "inability to defend".

> On Tue, May 24, 2022 at 5:46 AM Yoav Weiss  wrote:
>
>> After carefully studying the discussions on the various threads (as well
>> as participating in them, trying to bridge the gaps), my previous LGTM
>> still stands.
>>
>> I believe there are 3 points of contention:
>> * API shape esthetics
>>  (#11)
>> * Async nature of CropTarget minting
>>  (#17)
>> * Whether CropTarget minting should be able to fail
>>  (#48)
>>
>> On API shape esthetics, we've managed to reach a reasonable compromise
>> that's being defined in #50
>> . Please make sure
>> that we're shipping the shape defined there, as well as that the PR itself
>> lands at some point.
>>
>> As for the need for async minting and their potential failure, I tried to
>> clarify the processing model in #47
>> . It'd be great if
>> we can land those parts in the spec as well.
>> At the same time, the discussions on #17 and #48 don't seem to converge,
>> and revolve mostly around back-seat implementation design, which IMO is
>> somewhat out-of-place for a WG discussion.
>>
>> Going with an

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

2022-05-25 Thread Yoav Weiss

On Tue, May 24, 2022 at 4:38 PM Jihwan Kim  wrote:

> Contact emailsbluewhale.m...@gmail.com
>
> ExplainerNone
>

A short text explaining what the feature is with an example would've gone a
long way to help folks (like me) understand this intent.


>
> Specificationhttps://www.w3.org/TR/selectors-4/#modal-state
>
> Summary
>
> A pseudo class selector to style dialog element.
>

The spec also mentions fullscreen. Is it covered by this intent as well?


> The :modal pseudo-class represents an element which is in a state that
> excludes all interaction with elements outside it until it has been
> dismissed.
>
>
> Blink componentBlink>CSS
> 
>
> TAG review
>

I agree that a TAG review may not be necessary here since this is adopted
by the CSSWG and shipped in another engine.


>
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> Gecko: Shipped/Shipping (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1768535)
>

That's an open issue, not an indication they shipped this.


>
> WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=240109)
>
> Web developers: No signals
>

> Other signals:
>
> 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
>
> Automatically supported, same as other pseudo-elements.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>

Link to the WPTs?


>
>
> Flag name
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1327113
>
> Estimated milestones
>
> No milestones specified
>
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5192833009975296
>
> 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/a/chromium.org/d/msgid/blink-dev/CAPJHA1oU6TM%3DqU6udPJ46g2%3DUoYYiObOuoYrSLboMBZe7icofQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVEWFBSd8QW8MAjd3KuKcViuruefQWc6eQP%2BE4SGRVA9w%40mail.gmail.com.

Re: [blink-dev] Re: Intent To Ship: Prevent fixed elements from moving during elastic overscroll.

2022-05-25 Thread Yoav Weiss

Hey Rahul!

A few things missing with the intent:

   - An explainer would be helpful to clarify the motivation for this and
   if this has any web exposed impact (and e.g. how would developers that want
   to keep to current behavior could cope with different engines doing
   different things)
   - Is this specified? I see the WG discussion, but not sure if a spec
   change followed
   - Can you ask for official Mozilla and WebKit positions? (
   https://bit.ly/blink-signals)

Cheers :)
Yoav

On Tue, May 24, 2022 at 8:08 PM Robert Flack  wrote:

>
>
> On Tue, May 24, 2022 at 1:27 PM 'Rahul Arakeri' via input-dev <
> input-...@chromium.org> wrote:
>
>> *Contact emails*: arak...@microsoft.com
>>
>>
>>
>> *CSSWG discussion*: [css-overscroll] Whether to move position:fixed
>> elements during overscrolling · Issue #6299 · w3c/csswg-drafts (github.com)
>> 
>>
>>
>>
>> *Summary*: Currently, position:fixed elements move when the scroller is
>> overscrolled. With this change, we intend to prevent fixed elements from
>> moving during an elastic overscroll.
>>
>>
>>
>> *Blink component*: Blink>Scroll
>> 
>>
>>
>>
>>
>> *Chromestatus*: Prevent overscroll for fixed elements. - Chrome Platform
>> Status (chromestatus.com)
>> 
>>
>>
>>
>> *Risks*:
>>
>>- Interoperability: Firefox/Safari still moves fixed elements on
>>overscroll.
>>
>> Just wanted to clarify, iOS Safari does not move fixed position elements
> on overscroll except when you start scrolling at the scroller edge in order
> to make room for the refresh affordance, so there's already some
> inconsistency here.
>
> Also it is considered a bug that fixed content does still move on Safari
> desktop
>  so
> they would likely be willing to follow along with this change.
>
>
>>
>>- Interacting with websites will *feel* different (going forward) on
>>platforms that support overscroll. This may lead to some web devs amending
>>pages to preserve their original UX. We are currently running experiments
>>in Microsoft Edge to determine user impact and would also discuss the
>>possibility of doing origin trials in Chromium with Google engineers.
>>
>>
>>
>> *Debuggability*: N/A
>>
>> *Is this feature fully tested by web-platform-tests?*
>>
>> Yes. We did a dry run
>>  with
>> the feature turned on and noticed test failures. They will need to be
>> addressed before the feature can be turned on.
>>
>> *Flag name*: FixedElementsDontOverscroll
>>
>>- Usage: chrome.exe --enable-features=ElasticOverscroll
>>--enable-blink-features=FixedElementsDontOverscroll
>>
>>
>>
>> *Estimated milestone*:
>>
>> 105
>>
>>
>>
>> *Tracking bugs*:
>>
>>- Chromium:
>>   - 585766 - Overscroll shouldn't affect fixed elements - chromium
>>   
>>- Firefox:
>>   - *https://github.com/mozilla/wg-decisions/issues/757
>>   *
>>   - *https://bugzilla.mozilla.org/show_bug.cgi?id=1760368
>>   *
>>- Webkit:
>>   - *https://bugs.webkit.org/show_bug.cgi?id=206227
>>   *
>>
>>
>>
>> *Misc:*
>>
>>- BlinkOn 16 talk: (1311) Keynote Presentation & Lightning Talks -
>>Session 1 [BlinkOn 16] - YouTube
>>
>>
>> --
> 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/CAJh39TOdn6Hksb1Zb8H5oqsUu0xvS%2BmqvypEghDsNtsQRFr1Nw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXNkOOG4qWEP51BHj-3VCeE-B%3DoS3yL9Uz9tMypAA-JcQ%40mail.gmail.com.

[blink-dev] Intent to Extend Experiment: Cookies Having Independent Partitioned State (CHIPS)

Re: [blink-dev] Re: Intent to Prototype: Reduce fingerprinting in the Accept-Language header and support for HTTP Variants

[blink-dev] Re: Intent to Prototype and Ship: Multi-Screen Window Placement: Fullscreen Companion Window

[blink-dev] Re: FYI: Remove the service worker requirement for WebAPKs

[blink-dev] FYI: Remove the service worker requirement for WebAPKs

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

[blink-dev] Re: Intent to Experiment: Increased max nesting level for setTimeout(0)

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

Re: [blink-dev] Intent to Ship: CSS object-view-box

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

Re: [blink-dev] Re: Intent to Ship: Subresource loading with Web Bundles

Re: [blink-dev] Re: Intent to Prototype: Reduce fingerprinting in the Accept-Language header and support for HTTP Variants

[blink-dev] Intent to Ship: MediaTrackConstraintSet.displaySurface

[blink-dev] Intent to Prototype: MediaTrackConstraintSet.displaySurface

[blink-dev] Intent to Ship: MediaTrackSupportedConstraints.suppressLocalAudioPlayback

[blink-dev] Intent to Prototype: MediaTrackSupportedConstraints.suppressLocalAudioPlayback

[blink-dev] Intent to Ship: DisplayMediaStreamConstraints.selfBrowserSurface

[blink-dev] Intent to Prototype: DisplayMediaStreamConstraints.selfBrowserSurface

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

[blink-dev] Intent to Prototype: DisplayMediaStreamConstraints.systemAudio

Re: [blink-dev] Intent to Extend Origin Trial: Subresource loading with Web Bundles

Re: [blink-dev] Intent to Extend Origin Trial: Subresource loading with Web Bundles

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

Re: [blink-dev] Intent to Ship: 'blocking=rendering' attribute on scripts and style sheets

[blink-dev] Re: Intent to Prototype and Ship: Multi-Screen Window Placement: Fullscreen Companion Window

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

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

[blink-dev] Re: Intent to Ship: Region Capture

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

Re: [blink-dev] Re: Intent To Ship: Prevent fixed elements from moving during elastic overscroll.

31 matches

Site Navigation

Mail list logo

Footer information