[webkit-dev] Request for position: new window.open() behavior

2021-11-19 Thread Mason Freed via webkit-dev
Hi WebKit,

I'd like to get WebKit's position on some changes that were recently made
to the spec  for window.open().
Chromium is planning to ship

these
new behaviors soon. The chromestatus entry
 has the full details,
but in essence, this makes two changes to the spec. First is that a new
windowFeature value, 'popup', can be used to explicitly trigger a popup
(popup=1) vs. a window/tab (popup=0). The other change is that the
BarProp.visible properties will all return the same values, true for
tab/window, false for popup. We do not believe either of these changes
should cause compat problems, but we'll monitor for bugs as we roll it out.

These changes simplify the usage of window.open() and work toward better
interop in this area. We're hopeful that you're supportive of this change.

Thanks,
Mason
___
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
>> <https://github.com/mozilla/standards-positions/issues/335#issuecomment-781697858>.
>> 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,

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

2021-02-19 Thread Mason Freed via webkit-dev
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
> <https://github.com/mozilla/standards-positions/issues/335#issuecomment-781697858>.
> 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 folks,
>>> >
>>> > I just wanted to quickly ping this thread to see if there was any
>>> interest in posting a position on declarative Shadow DOM. My original post
>>> here didn't gather much feedback. :-)
>>> >
>>> > Thanks,
>>> > Mason
>>> >
>>> >
>>> > On Tue, May 26, 2020 at 12:11 PM Mason Freed 
>>> wrote:
>>> >>
>>> >> Hello WebKit!
>>> >>
>>> >> I would like to request an official WebKit position on the
>>> Declarative Shadow DOM proposal. There have been some great comments and
>>> discussion from WebKit folks on the issue thread, but it is a bit unclear
>>> whether the overall proposal is something WebKit would support. This was
>>> brought up and discussed, e.g., on the DOM spec

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

2021-02-18 Thread Mason Freed via webkit-dev
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
<https://github.com/mozilla/standards-positions/issues/335#issuecomment-781697858>.
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 folks,
>> >
>> > I just wanted to quickly ping this thread to see if there was any
>> interest in posting a position on declarative Shadow DOM. My original post
>> here didn't gather much feedback. :-)
>> >
>> > Thanks,
>> > Mason
>> >
>> >
>> > On Tue, May 26, 2020 at 12:11 PM Mason Freed 
>> wrote:
>> >>
>> >> Hello WebKit!
>> >>
>> >> I would like to request an official WebKit position on the Declarative
>> Shadow DOM proposal. There have been some great comments and discussion
>> from WebKit folks on the issue thread, but it is a bit unclear whether the
>> overall proposal is something WebKit would support. This was brought up and
>> discussed, e.g., on the DOM spec PR here:
>> https://github.com/whatwg/dom/pull/858#issuecomment-623735890
>> >>
>> >> Please see below for all of the relevant supporting documents and
>> discussions.
>> >>
>> >> Explainer:
>> https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md
>> >> WhatWG DOM Issue discussion: https://github.com/whatwg/dom/issues/831
>> >> HTML Spec PR: https://github.com/whatwg/html/pull/5465
>> >> DOM Spec PR: https://github.com/whatwg/dom/pull/858
>> >> TAG review: https://github.com/w3ctag/design-reviews/issues/494
>> >> Request for Mozilla Position:
>> https://github.com/mozilla/standards-positions/issues/335
>> >>
>> >> Thanks,
>> >> Mason Freed
>> >>
>> > ___
>> > 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] Position on emerging standard: Declarative Shadow DOM

2020-08-11 Thread Mason Freed
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 folks,
> >
> > I just wanted to quickly ping this thread to see if there was any
> interest in posting a position on declarative Shadow DOM. My original post
> here didn't gather much feedback. :-)
> >
> > Thanks,
> > Mason
> >
> >
> > On Tue, May 26, 2020 at 12:11 PM Mason Freed 
> wrote:
> >>
> >> Hello WebKit!
> >>
> >> I would like to request an official WebKit position on the Declarative
> Shadow DOM proposal. There have been some great comments and discussion
> from WebKit folks on the issue thread, but it is a bit unclear whether the
> overall proposal is something WebKit would support. This was brought up and
> discussed, e.g., on the DOM spec PR here:
> https://github.com/whatwg/dom/pull/858#issuecomment-623735890
> >>
> >> Please see below for all of the relevant supporting documents and
> discussions.
> >>
> >> Explainer:
> https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md
> >> WhatWG DOM Issue discussion: https://github.com/whatwg/dom/issues/831
> >> HTML Spec PR: https://github.com/whatwg/html/pull/5465
> >> DOM Spec PR: https://github.com/whatwg/dom/pull/858
> >> TAG review: https://github.com/w3ctag/design-reviews/issues/494
> >> Request for Mozilla Position:
> https://github.com/mozilla/standards-positions/issues/335
> >>
> >> Thanks,
> >> Mason Freed
> >>
> > ___
> > 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] Position on emerging standard: Declarative Shadow DOM

2020-08-04 Thread Mason Freed
Hello WebKit folks,

I just wanted to quickly ping this thread to see if there was any interest
in posting a position on declarative Shadow DOM. My original post here
didn't gather much feedback. :-)

Thanks,
Mason


On Tue, May 26, 2020 at 12:11 PM Mason Freed 
wrote:

> Hello WebKit!
>
> I would like to request an official WebKit position on the Declarative
> Shadow DOM proposal. There have been some great comments and discussion
> from WebKit folks on the issue thread, but it is a bit unclear whether the
> overall proposal is something WebKit would support. This was brought up and
> discussed, e.g., on the DOM spec PR here:
> https://github.com/whatwg/dom/pull/858#issuecomment-623735890
>
> Please see below for all of the relevant supporting documents and
> discussions.
>
> Explainer:
> https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md
> WhatWG DOM Issue discussion: https://github.com/whatwg/dom/issues/831
> HTML Spec PR: https://github.com/whatwg/html/pull/5465
> DOM Spec PR: https://github.com/whatwg/dom/pull/858
> TAG review: https://github.com/w3ctag/design-reviews/issues/494
> Request for Mozilla Position:
> https://github.com/mozilla/standards-positions/issues/335
>
> Thanks,
> Mason Freed
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Position on emerging standard: HTMLLinkElement "disabled" attribute behavior

2020-05-27 Thread Mason Freed
Hi WebKit,

I would like to request an official WebKit position on the changes to the
HTMLLinkElement "disabled" attribute behavior, as discussed here:
https://github.com/whatwg/html/issues/3840. The interop situation here is
not great, so it would be good to align on a single spec. I would like to
ship the behavior specified in https://github.com/whatwg/html/pull/4519 in
Chromium, and Gecko already ships this behavior.

Thanks,
Mason Freed
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2020-05-26 Thread Mason Freed
Hello WebKit!

I would like to request an official WebKit position on the Declarative
Shadow DOM proposal. There have been some great comments and discussion
from WebKit folks on the issue thread, but it is a bit unclear whether the
overall proposal is something WebKit would support. This was brought up and
discussed, e.g., on the DOM spec PR here:
https://github.com/whatwg/dom/pull/858#issuecomment-623735890

Please see below for all of the relevant supporting documents and
discussions.

Explainer:
https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md
WhatWG DOM Issue discussion: https://github.com/whatwg/dom/issues/831
HTML Spec PR: https://github.com/whatwg/html/pull/5465
DOM Spec PR: https://github.com/whatwg/dom/pull/858
TAG review: https://github.com/w3ctag/design-reviews/issues/494
Request for Mozilla Position:
https://github.com/mozilla/standards-positions/issues/335

Thanks,
Mason Freed
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev