Re: [webkit-dev] Position on emerging standard: Declarative Shadow DOM

2021-02-23 Thread Ryosuke Niwa via webkit-dev
On Tue, Feb 23, 2021 at 5:06 PM Mason Freed via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> > On Fri Feb 19 20:36:12 PST 2021 Ryosuke Niwa via webkit-dev <
> > webkit-dev at lists.webkit.org> wrote:
> >
> > I replied in the issues directly so that people outside of the WebKit
> > community can follow the discussion.
>
> Thanks! I've replied there also.
>

The issue with the semantics of getInnerHTML is problematic enough that
we'd object to this feature as long as that's included in its current shape.

> How does one specify a declarative shadow root to use a specific custom
> > element registry?
>
> Well, I do see this as something that is better designed as part of the
> scoped custom element registry proposal. But the basic idea would be to
> just to add an attribute that allows the declarative shadow root to opt
> out of automatically using the global registry:
>
> 
>
> and that would keep any custom elements contained within the shadow root
> from automatically upgrading based on the global registry. Maybe by just
> assigning an empty custom registry to that shadow root. We'll need to add
> an attribute to ShadowRoot, as part of the SCER proposal, to allow custom
> elements to then set the appropriate custom registry later.
>

That seems to indicate that none of the custom elements inside a
declarative shadow root can be upgraded until all its ancestor custom
elements which use a custom element registry have been upgraded. This would
make the declarative shadow DOM's perf benefit less attractive IMO.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Position on emerging standard: Declarative Shadow DOM

2021-02-23 Thread Mason Freed via webkit-dev
> On Fri Feb 19 20:36:12 PST 2021 Ryosuke Niwa via webkit-dev <
> webkit-dev at lists.webkit.org> wrote:
>
> I replied in the issues directly so that people outside of the WebKit
> community can follow the discussion.

Thanks! I've replied there also.

> How does one specify a declarative shadow root to use a specific custom
> element registry?

Well, I do see this as something that is better designed as part of the
scoped custom element registry proposal. But the basic idea would be to
just to add an attribute that allows the declarative shadow root to opt
out of automatically using the global registry:



and that would keep any custom elements contained within the shadow root
from automatically upgrading based on the global registry. Maybe by just
assigning an empty custom registry to that shadow root. We'll need to add
an attribute to ShadowRoot, as part of the SCER proposal, to allow custom
elements to then set the appropriate custom registry later.

On Fri, Feb 19, 2021 at 2:38 PM Mason Freed  wrote:

> On Thu Feb 18 17:08:18 PST 2021 Ryosuke Niwa via webkit-dev <
> webkit-dev at lists.webkit.org> wrote:
>
> > The latest proposal does solve much of the problems we've identified in
> the
> > past, and it's looking to be a promising direction. Do you have any
> example
> > website or app that you can share with which resulted in the observed 15%
> > improvement in FCP? That would be a very intriguing observation and would
> > substantiate the support for this feature.
>
> Glad to hear you think it's promising! The example is from the AMP team,
> and you can see more detail at the Origin Trial results summary here:
>
> https://docs.google.com/document/d/1QmBKxQLE81PsMzyPCvYhzqRAn4hxz61Jzk0uXJAhaVc/edit
>
>
> > However, as I commented on https://github.com/whatwg/dom/pull/892 and
> have
> > previously stated during the last F2F and other avenues, the currently
> > proposed semantics of getInnerHTML is deeply problematic. We want
> > consistent semantics across different kinds of Web API, and what's being
> > proposed is very much different from what we had discussed what we would
> do
> > for selection.
>
> I just replied to the comment you made yesterday on DOM issue #892. I
> looked
> back at the F2F minutes (
> https://www.w3.org/2020/03/23-components-minutes.html)
> to refresh my memory, and it turns out the current API was actually
> suggested
> (by annevk) at that meeting. I don't see any comments from you about the
> API
> shape there, but perhaps I missed it?
>
> In terms of API shape, can you clarify what you feel is deeply problematic
> about it? I assume you're talking about the need to pass in closed shadow
> roots, to enable them to be serialized. I see that your comment there
> suggests
> the requirement to pass in *all* shadow roots, even open ones. But the
> linked
> comment on selection actually refers to just closed shadow roots also. I'm
> unclear why you would want/need to pass in open shadow roots?
>
>
> > Also, have people figured out how scoped custom element registries can
> > integrate with this feature in the future? Given that's the other most
> > frequently requested feature, it would be very regrettable if we later
> > found out some inconsistencies or awkwardness in their integrations.
>
> Yes, I've talked several times to justinfagnani about Scoped Custom Element
> Registries, and he sees no problem integrating with DSD. We'll likely
> just need to add an attribute that opts the shadow root out of using the
> global registry, but that seems straightforward. Do you have any particular
> concerns?
>
> Thanks,
> Mason
>
> On Thu, Feb 18, 2021 at 3:16 PM Mason Freed 
> wrote:
>
>> Hello WebKit,
>>
>> I just wanted to send a final heads-up that Chromium is intending to ship
>> the Declarative Shadow DOM feature. We haven't heard much back from WebKit
>> in the last 5 months or so, but in the meantime there has been some good
>> discussion with Mozilla and the broader community. Several more performance
>> investigations have been performed, around the overhead of Shadow DOM
>> generally, and around the potential polyfill alternatives for DSD. You can
>> see a summary of these, plus all of the other changes that we've
>> incorporated, in this comment on the Mozilla Standards Position thread
>> .
>> These changes are the result of your (and the community's) involvement and
>> feedback, so thanks. At this point, we believe all of the feedback has been
>> addressed.
>>
>> Thanks,
>> Mason
>>
>>
>> On Tue, Aug 11, 2020 at 10:27 AM Mason Freed 
>> wrote:
>>
>>> Yes, thanks! Welcome back!
>>>
>>> On Mon, Aug 10, 2020 at 3:24 PM Ryosuke Niwa  wrote:
>>>
 Hi,

 Sorry for the late reply. I've been on a medical leave. I just
 commented on https://github.com/whatwg/dom/issues/831

 - R. Niwa

 On Tue, Aug 4, 2020 at 4:26 PM Mason Freed 
 wrote:
 >
 > Hello WebKit 

Re: [webkit-dev] Commit-Queue failing intermittently

2021-02-23 Thread Aakash Jain via webkit-dev
Most of the issues with commit-queue were fixed. We also added automatic 
retries in commit-queue to better handle intermittent issues (in 
https://webkit.org/b/222038).

Please let me know if anyone notices any issue.

Thanks
Aakash

> On Feb 4, 2021, at 4:39 PM, Aakash Jain  wrote:
> 
> We are noticing intermittent issues with Commit-Queue failing to commit, 
> since we moved it to github. We are looking into it. Meanwhile, if 
> Commit-Queue fails on your patch, you can set cq+ again to retry.
> 
> Thanks
> Aakash
> 
>> On Jan 19, 2021, at 4:56 PM, Aakash Jain  wrote:
>> 
>> All the issues have been fixed.
>> 
>> Please let me know if anyone notices any issue.
>> 
>> Thanks
>> Aakash
>> 
>>> On Jan 19, 2021, at 12:23 PM, Aakash Jain  wrote:
>>> 
>>> We are noticing some issues on Style-Queue and Commit-Queue. We are 
>>> looking into that.
>>> 
>>> Thanks
>>> Aakash
>>> 
 On Jan 19, 2021, at 9:58 AM, Aakash Jain  wrote:
 
 Hi Everyone,
 
 We need to do some maintenance on the EWS bots (in order to switch the 
 repository from git.webkit.org to https://github.com/webkit/webkit, 
 https://bugs.webkit.org/show_bug.cgi?id=220479). EWS buildbot will be 
 offline for about an hour, so it wouldn't process any new builds. However, 
 EWS status-bubbles will still keep loading on Bugzilla.
 
 Thanks
 Aakash
>>> 
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for position: CSS scrollbar-gutter

2021-02-23 Thread Emilio Cobos Álvarez via webkit-dev
I guess that'd solve parts of the issue, but not the use-case of 
non-overlay scrollbars in overflow: auto causing reflow when the content 
initially overflows.


But it seems like a much simpler version of scrollbar-gutter (one that 
would only work with non-overlay scrollbars, and on scrollable boxes) 
could solve.


 -- Emilio

On 2/23/21 22:08, Emilio Cobos Álvarez via webkit-dev wrote:
Just thinking out loud, but has an environment variable for scrollbar 
widths (maybe two, one for thin scrollbars, one for regular-width 
scrollbars) be enough to do the job here?


I recall similar proposals in the CSSWG, but I'm not sure if they were 
discussed seriously. It seems it should be easier to implement, 
off-hand, and maybe less confusing? And it would allow the pattern Simon 
mentions here.


It should also allow solving some of the issues people hit with vh/vw if 
non-overlay scrollbars are used[1]. I guess for that last use-case we'd 
really need two pairs of values, one of which should return zero for 
overlay scrollbars for that use-case to work...? Anyhow, seems like this 
could be discussed in the CSSWG.


-- Emilio

[1]: https://github.com/w3c/csswg-drafts/issues/6026

On 2/23/21 18:45, Simon Fraser via webkit-dev wrote:

WebKit does not support this feature as specified.

Our opinion is that we don't want to encourage web developers to 
reserve space for scrollbars in a way that prevents non-interactive 
content from intruding into that space. This undoes a big advantage of 
overlay scrollbars, in that they leave more space for content.


Our preference would be some kind of margin value (perhaps a constant) 
that allows authors to move only interactive content outside of the 
area affected by overlay scrollbars.


Simon


On Feb 23, 2021, at 5:54 AM, Felipe Erias via webkit-dev 
 wrote:


Hi webkit-dev,

This is a request for WebKit's position on the CSS "scrollbar-gutter" 
property. The spec status is Working Draft. This feature is already 
implemented in Chrome behind a flag.


Spec:
  https://drafts.csswg.org/css-overflow-4/#scrollbar-gutter-property

Explainer:
  https://github.com/felipeerias/scrollbar-gutter-explainer

Existing WebKit bug:
  https://bugs.webkit.org/show_bug.cgi?id=167335

Summary:

The scrollbar-gutter property provides control over the presence of 
scrollbar gutters (the space which may be reserved to display a 
scrollbar).


This gives Web authors more agency over how their layouts interact 
with the scrollbars provided by the browser, so they can e.g. prevent 
excessive layout changes as content expands while avoiding unwanted 
visuals when scrolling isn't needed.


Thanks!

Best.
Felipe
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for position: CSS scrollbar-gutter

2021-02-23 Thread Emilio Cobos Álvarez via webkit-dev
Just thinking out loud, but has an environment variable for scrollbar 
widths (maybe two, one for thin scrollbars, one for regular-width 
scrollbars) be enough to do the job here?


I recall similar proposals in the CSSWG, but I'm not sure if they were 
discussed seriously. It seems it should be easier to implement, 
off-hand, and maybe less confusing? And it would allow the pattern Simon 
mentions here.


It should also allow solving some of the issues people hit with vh/vw if 
non-overlay scrollbars are used[1]. I guess for that last use-case we'd 
really need two pairs of values, one of which should return zero for 
overlay scrollbars for that use-case to work...? Anyhow, seems like this 
could be discussed in the CSSWG.


 -- Emilio

[1]: https://github.com/w3c/csswg-drafts/issues/6026

On 2/23/21 18:45, Simon Fraser via webkit-dev wrote:

WebKit does not support this feature as specified.

Our opinion is that we don't want to encourage web developers to reserve space 
for scrollbars in a way that prevents non-interactive content from intruding 
into that space. This undoes a big advantage of overlay scrollbars, in that 
they leave more space for content.

Our preference would be some kind of margin value (perhaps a constant) that 
allows authors to move only interactive content outside of the area affected by 
overlay scrollbars.

Simon



On Feb 23, 2021, at 5:54 AM, Felipe Erias via webkit-dev 
 wrote:

Hi webkit-dev,

This is a request for WebKit's position on the CSS "scrollbar-gutter" property. 
The spec status is Working Draft. This feature is already implemented in Chrome behind a 
flag.

Spec:
  https://drafts.csswg.org/css-overflow-4/#scrollbar-gutter-property

Explainer:
  https://github.com/felipeerias/scrollbar-gutter-explainer

Existing WebKit bug:
  https://bugs.webkit.org/show_bug.cgi?id=167335

Summary:

The scrollbar-gutter property provides control over the presence of scrollbar 
gutters (the space which may be reserved to display a scrollbar).

This gives Web authors more agency over how their layouts interact with the 
scrollbars provided by the browser, so they can e.g. prevent excessive layout 
changes as content expands while avoiding unwanted visuals when scrolling isn't 
needed.

Thanks!

Best.
Felipe
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for position: WebAssembly SIMD

2021-02-23 Thread Deepti Gandluri via webkit-dev
Thanks Keith, appreciate your reply.

On Mon, Feb 22, 2021 at 1:57 PM Keith Miller  wrote:

> Hi Deepti,
>
> We have not yet implemented the proposal but we generally have a positive
> opinion of it. I also can’t give any timeline for when it will be
> implemented in WebKit unfortunately.
>
> Cheers,
> Keith
>
> On Feb 17, 2021, at 12:22 PM, Deepti Gandluri via webkit-dev <
> webkit-dev@lists.webkit.org> wrote:
>
> Hello,
>
> This is a request for WebKit position on the WebAssembly SIMD proposal,
> which is now at Phase 4
> 
>  as
> of the last WebAssembly CG meeting on 2/16/2021. Chrome is planning to ship
> WebAssembly SIMD in 91.
>
> Proposal: https://github.com/WebAssembly/simd/tree/master/proposals/simd
> Specification:
> https://github.com/WebAssembly/simd/tree/master/document/core
> ChromeStatus: https://www.chromestatus.com/feature/6533147810332672
>
> Thanks,
> Deepti Gandluri
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for position: CSS scrollbar-gutter

2021-02-23 Thread Simon Fraser via webkit-dev
WebKit does not support this feature as specified.

Our opinion is that we don't want to encourage web developers to reserve space 
for scrollbars in a way that prevents non-interactive content from intruding 
into that space. This undoes a big advantage of overlay scrollbars, in that 
they leave more space for content.

Our preference would be some kind of margin value (perhaps a constant) that 
allows authors to move only interactive content outside of the area affected by 
overlay scrollbars.

Simon


> On Feb 23, 2021, at 5:54 AM, Felipe Erias via webkit-dev 
>  wrote:
> 
> Hi webkit-dev,
> 
> This is a request for WebKit's position on the CSS "scrollbar-gutter" 
> property. The spec status is Working Draft. This feature is already 
> implemented in Chrome behind a flag.
> 
> Spec:
>  https://drafts.csswg.org/css-overflow-4/#scrollbar-gutter-property
> 
> Explainer:
>  https://github.com/felipeerias/scrollbar-gutter-explainer
> 
> Existing WebKit bug:
>  https://bugs.webkit.org/show_bug.cgi?id=167335
> 
> Summary:
> 
> The scrollbar-gutter property provides control over the presence of scrollbar 
> gutters (the space which may be reserved to display a scrollbar).
> 
> This gives Web authors more agency over how their layouts interact with the 
> scrollbars provided by the browser, so they can e.g. prevent excessive layout 
> changes as content expands while avoiding unwanted visuals when scrolling 
> isn't needed.
> 
> Thanks!
> 
> Best.
> Felipe
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Request for position: CSS scrollbar-gutter

2021-02-23 Thread Felipe Erias via webkit-dev

Hi webkit-dev,

This is a request for WebKit's position on the CSS "scrollbar-gutter" 
property. The spec status is Working Draft. This feature is already 
implemented in Chrome behind a flag.


Spec:
  https://drafts.csswg.org/css-overflow-4/#scrollbar-gutter-property

Explainer:
  https://github.com/felipeerias/scrollbar-gutter-explainer

Existing WebKit bug:
  https://bugs.webkit.org/show_bug.cgi?id=167335

Summary:

The scrollbar-gutter property provides control over the presence of 
scrollbar gutters (the space which may be reserved to display a scrollbar).


This gives Web authors more agency over how their layouts interact with 
the scrollbars provided by the browser, so they can e.g. prevent 
excessive layout changes as content expands while avoiding unwanted 
visuals when scrolling isn't needed.


Thanks!

Best.
Felipe
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev