Re: [webkit-dev] Request for position: Canvas 2D display-p3 support

[Sam Weinig via webkit-dev]

Hi Christopher,

We are in favor of this proposal.

- Sam

> On Jun 9, 2021, at 6:39 PM, Christopher Cameron via webkit-dev 
>  wrote:
> 
> Hi webkit-dev,
> 
> (and sorry for the duplicate post here, I mangled the headers on the previous 
> post!)
> 
> This is a request for WebKit's position on display-p3 support for Canvas 2D. 
> This is already being tracked in bugs.webkit.org  
> here .
> 
> Summary:
> 
> Adds a color space parameter to CanvasRenderingContext2DSettings, which 
> defaults to "srgb" and can take on the value of "display-p3". Adds 
> ImageDataSettings, which allows specifying a color space parameter to 
> getImageData/createImageData and related constructors.
> 
> Spec:
> 
> WhatWG spec changes merged in this PR 
> .
> 
> Tests:
> 
> https://github.com/web-platform-tests/wpt/tree/master/html/canvas/element/wide-gamut-canvas
>  
> 
> Includes tests of ImageData (get and put), and ensuring no loss when doing 
> toBlob and toDataURL round-trips.
> 
> Thank you for your feedback!
> 
> Christopher
> ___
> 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] Safari/Webkit Team and Developer Communication

[Matthew Thomas via webkit-dev]

To *Safari/Webkit-Developers*,


I'd like to draw your attention to the following threads on this years
WWDC21:


https://developer.apple.com/forums/thread/681748  (Safari/Webkit Team and
Developer Communication")

https://developer.apple.com/forums/thread/681575 (Notifications for
Web-Apps on iOS?)


As web-developers we feel we have limited influence over Safari
(specifically iOS Safari) and there's the growing perception that Safari is
being strategically underfunded with specific features never being
developed in order to push users towards the AppStore and it's 70+ billion
$ in yearly revenue.  We also understand that as people who actually
develop browsers you are as passionate if not more so than the development
community about the open web but we also understand that you don't have
control over exactly what gets built/funded.


Our feeling is that:

   - The Safari/Webkit Team does not have the budget/staffing it needs to
   keep up with the full feature set of a modern browser.
   - Upper management *strategically underfunds* or does not develop
   specific features to push developers to use the AppStore instead where
   Apple can then take a 30% cut off revenue / lock apps into the Apple
   ecosystem.
   - Upper Management does not see much value in funding the open-web in
   general but specifically does not want to fund anything that would allow
   native-app like functionality in a web-app on a mobile device.
   - Developer feature requests are largely ignored because of point no 2.
   - Other browsers are not allowed in iOS primarily because of point no 2.
   (with privacy/security being a very secondary reason)


In terms of developing web-apps Safari on iOS is the *number one limiting
factor*.  Every year goes past, we request the same basic set of features
but the *core *capabilities of web-apps remains largely stagnant. The
Safari team needs a much higher budget, a ton more staff and should be able
to operate relatively independently of external business goals. Priorities
should be set between a combination of what's good for users and what's
good for developers,  how much money the AppStore makes should not be a
consideration when deciding what does and what doesn't get developed.


Safari and Web-Apps are often touted by Apple Legal in antitrust/monopoly
investigations as the alternative to the AppStore.  How can they be the
alternative with the current feature set.  This threat alone should push
Apple to fund the Safari team and make web-apps a viable competitor with
native.


Please take a read of the linked posts above and please respond if you have
any opinions or you don't agree with any of the assumptions/perceptions
above.


We implore you, talk to your colleagues, directors, senior directors, svps,
vps, *advocate* for the open-web / web-apps and try to push Safari in a
direction where it at least has the core basic features that native apps
have.  This change has to come from within the organization, all we can do
as outsiders is appeal for your help.


Thank-you for your hard work and time, please help us make this change.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Request for position: Canvas 2D display-p3 support

[Christopher Cameron via webkit-dev]

Hi webkit-dev,

(and sorry for the duplicate post here, I mangled the headers on the
previous post!)

This is a request for WebKit's position on display-p3 support for Canvas
2D. This is already being tracked in bugs.webkit.org here
.

*Summary:*

Adds a color space parameter to CanvasRenderingContext2DSettings, which
defaults to "srgb" and can take on the value of "display-p3".
Adds ImageDataSettings, which allows specifying a color space parameter to
getImageData/createImageData and related constructors.

*Spec:*

WhatWG spec changes merged in this PR

.

*Tests:*

https://github.com/web-platform-tests/wpt/tree/master/html/canvas/element/wide-gamut-canvas
Includes tests of ImageData (get and put), and ensuring no loss when doing
toBlob and toDataURL round-trips.

Thank you for your feedback!

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

Re: [webkit-dev] Use of Swift (for bridging) in the WebKit project

[Geoff Garen via webkit-dev]

Got it. Seems like, in this case, this is the best (i.e. only) way to do things.

For the general case, I’m not sure what the current “no new language” policy 
states, but I would favor some kind of amendment that said “…unless it’s the 
only way to do things because you’re calling out to something in that language, 
and in that case please try to make the usage as minimal as reasonably 
possible”.

Thanks,
Geoff

> On Jun 9, 2021, at 11:37 AM, Jer Noble  wrote:
> 
> 
> 
>> On Jun 9, 2021, at 11:31 AM, Geoff Garen  wrote:
>> 
>> In this specific case
>> 
>>  What is the API we’re trying to call into?
> 
> This is calling into the GroupActivities.framework API which was announced at 
> WWDC this week.
> 
>>  Is using Swift the only way to call into it?
> 
> This was true at the time we wrote it, as GroupActivities required using the 
> Combine framework, which does not have an Objective-C API. I'm learning that 
> this may not be the case in the future. If GroupActivities is modified to not 
> require Combine, I will gladly remove the .swift.
> 
>>  Is there any way to reduce the use of Swift to only the calls into it, 
>> and not the surrounding objects (which all seem to be marked @objc anyway)?
> 
> The surrounding objects have to be written in Swift (in order to call Swift 
> APIs), but callable from Objective-C/++, which is why they're marked as 
> @objc. I believe that they are as minimal as I can make them.
> 
> -Jer
> 
>> Thanks,
>> Geoff
>> 
>>> On Jun 8, 2021, at 4:27 PM, Sam Weinig via webkit-dev 
>>>  wrote:
>>> 
>>> Hi Jer,
>>> 
>>> I think it sounds like a reasonable rule to allow Swift for bridging 
>>> purposes only, with the caveat that we should prefer Objective-C/C where it 
>>> can be used.
>>> 
>>> The one other place that Swift seems reasonable for WebKit is in the 
>>> definition and refinement of Swift bindings to WebKit’s public API.
>>> 
>>> That is to say, for the time being, we should avoid Swift in tools and core 
>>> functionality.
>>> 
>>> Thanks for bringing this up on the list.
>>> 
>>> - Sam
>>> 
 On Jun 8, 2021, at 3:57 PM, Jer Noble via webkit-dev 
  wrote:
 
 Hi all!
 
 We're working on some new features that currently use APIs exposed through 
 Swift. We have not yet approved writing and committing WebKit code in 
 Swift, given runtime, library, and just plain mental overhead that comes 
 with adding a new language to the project. But I'd argue that doing so for 
 the purpose of allowing existing C++ code to call into Swift APIs is 
 probably not terrible.
 
 Should we relax our "no new language" policy, only for the purposes of 
 allowing our core language code to call into APIs in Swift?
 
 (ref: https://bugs.webkit.org/show_bug.cgi?id=226757)
 
 Thanks, and look forward to hearing from everyone,
 
 -Jer
 ___
 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: preferCurrentTab

[Sam Weinig via webkit-dev]

Hi Elad,

Are there other existing uses of the term “tab” in other web exposed APIs? It 
feels a bit wrong to be wrong to be encoding that specific UI treatment into 
API.

- Sam

> On Jun 9, 2021, at 4:20 AM, Elad Alon via webkit-dev 
>  wrote:
> 
> This is a request for WebKit's position on adding a dictionary member in 
> MediaStreamConstraints called preferCurrentTab. If preferCurrentTab is set to 
> true, the user agent will display the current tab as the most prominent 
> option in the media-picker which getDisplayMedia invokes.
> 
> Links:
> Explainer 
> 
> Spec 
> ChromeStatus 
> ___
> 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] s...@webkit.org

[Christopher Cameron via webkit-dev]

Hi webkit-dev,

This is a request for WebKit's position on display-p3 support for Canvas
2D. This is already being tracked in bugs.webkit.org here
.

*Summary:*

Adds a color space parameter to CanvasRenderingContext2DSettings, which
defaults to "srgb" and can take on the value of "display-p3".
Adds ImageDataSettings, which allows specifying a color space parameter to
getImageData/createImageData and related constructors.

*Spec:*

WhatWG spec changes merged in this PR

.

*Tests:*

https://github.com/web-platform-tests/wpt/tree/master/html/canvas/element/wide-gamut-canvas
Includes tests of ImageData (get and put), and ensuring no loss when doing
toBlob and toDataURL round-trips.

Thank you for your feedback!

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

Re: [webkit-dev] Use of Swift (for bridging) in the WebKit project

[Jer Noble via webkit-dev]

> On Jun 9, 2021, at 11:31 AM, Geoff Garen  wrote:
> 
> In this specific case
> 
>   What is the API we’re trying to call into?

This is calling into the GroupActivities.framework API which was announced at 
WWDC this week.

>   Is using Swift the only way to call into it?

This was true at the time we wrote it, as GroupActivities required using the 
Combine framework, which does not have an Objective-C API. I'm learning that 
this may not be the case in the future. If GroupActivities is modified to not 
require Combine, I will gladly remove the .swift.

>   Is there any way to reduce the use of Swift to only the calls into it, 
> and not the surrounding objects (which all seem to be marked @objc anyway)?

The surrounding objects have to be written in Swift (in order to call Swift 
APIs), but callable from Objective-C/++, which is why they're marked as @objc. 
I believe that they are as minimal as I can make them.

-Jer

> Thanks,
> Geoff
> 
>> On Jun 8, 2021, at 4:27 PM, Sam Weinig via webkit-dev 
>>  wrote:
>> 
>> Hi Jer,
>> 
>> I think it sounds like a reasonable rule to allow Swift for bridging 
>> purposes only, with the caveat that we should prefer Objective-C/C where it 
>> can be used.
>> 
>> The one other place that Swift seems reasonable for WebKit is in the 
>> definition and refinement of Swift bindings to WebKit’s public API.
>> 
>> That is to say, for the time being, we should avoid Swift in tools and core 
>> functionality.
>> 
>> Thanks for bringing this up on the list.
>> 
>> - Sam
>> 
>>> On Jun 8, 2021, at 3:57 PM, Jer Noble via webkit-dev 
>>>  wrote:
>>> 
>>> Hi all!
>>> 
>>> We're working on some new features that currently use APIs exposed through 
>>> Swift. We have not yet approved writing and committing WebKit code in 
>>> Swift, given runtime, library, and just plain mental overhead that comes 
>>> with adding a new language to the project. But I'd argue that doing so for 
>>> the purpose of allowing existing C++ code to call into Swift APIs is 
>>> probably not terrible.
>>> 
>>> Should we relax our "no new language" policy, only for the purposes of 
>>> allowing our core language code to call into APIs in Swift?
>>> 
>>> (ref: https://bugs.webkit.org/show_bug.cgi?id=226757)
>>> 
>>> Thanks, and look forward to hearing from everyone,
>>> 
>>> -Jer
>>> ___
>>> 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] Use of Swift (for bridging) in the WebKit project

[Geoff Garen via webkit-dev]

In this specific case

What is the API we’re trying to call into?

Is using Swift the only way to call into it?

Is there any way to reduce the use of Swift to only the calls into it, 
and not the surrounding objects (which all seem to be marked @objc anyway)?

Thanks,
Geoff

> On Jun 8, 2021, at 4:27 PM, Sam Weinig via webkit-dev 
>  wrote:
> 
> Hi Jer,
> 
> I think it sounds like a reasonable rule to allow Swift for bridging purposes 
> only, with the caveat that we should prefer Objective-C/C where it can be 
> used.
> 
> The one other place that Swift seems reasonable for WebKit is in the 
> definition and refinement of Swift bindings to WebKit’s public API.
> 
> That is to say, for the time being, we should avoid Swift in tools and core 
> functionality.
> 
> Thanks for bringing this up on the list.
> 
> - Sam
> 
>> On Jun 8, 2021, at 3:57 PM, Jer Noble via webkit-dev 
>>  wrote:
>> 
>> Hi all!
>> 
>> We're working on some new features that currently use APIs exposed through 
>> Swift. We have not yet approved writing and committing WebKit code in Swift, 
>> given runtime, library, and just plain mental overhead that comes with 
>> adding a new language to the project. But I'd argue that doing so for the 
>> purpose of allowing existing C++ code to call into Swift APIs is probably 
>> not terrible.
>> 
>> Should we relax our "no new language" policy, only for the purposes of 
>> allowing our core language code to call into APIs in Swift?
>> 
>> (ref: https://bugs.webkit.org/show_bug.cgi?id=226757)
>> 
>> Thanks, and look forward to hearing from everyone,
>> 
>> -Jer
>> ___
>> 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] Feedback on Blink's text fragment directive proposal

[David Bokan via webkit-dev]

+1 that this seems like a really nice fit for text fragments, even if it's
only to reuse the text-matching implementation.

By way of an update, Chrome is rolling out a "copy-link-to-text" context
menu item (a built-in version of the earlier discussed extension):
https://blog.google/products/chrome/more-helpful-chrome-throughout-your-workday

Incidentally, the link above shows where text-fragments can be helpful. The
page lists many features and doesn't provide convenient `id` anchors. With
a text fragment, I can link you to
https://blog.google/products/chrome/more-helpful-chrome-throughout-your-workday/#:~:text=Link%20to%20your%20highlighted%20text.
Unfortunately, I can't know what browser the recipient will open the link
with (guessing webkit-dev@ typically doesn't use Chrome :). To be truly
useful, we'd need these links to be understood by WebKit and Gecko as well.

I've come across text-fragment links where they'd be helpful to the user:
 - The link in "Musk has previously spoken about" on this Verge article

 - Citation 9 in this Wikipedia page


With the built in functionality, I expect these links will become more
prevalent and seen by users of WebKit based browsers. We'll have more usage
numbers soon on how often these links are being generated from Chrome.

On Wed, Jun 9, 2021 at 12:37 PM Thomas Steiner  wrote:

> On Wed, Jun 9, 2021 at 6:27 PM Megan Gardner 
> wrote:
>
>> We are store the explicite range/position information in the associated
>> note, and also use text matching as a fallback.
>>
>
> Thanks for responding! Any desire to adopt the Text Fragment syntax (
> https://web.dev/text-fragments/) for the (brilliant) Quick Notes feature?
>
> Note that we have enabled this feature in Chrome for iOS (
> https://apps.apple.com/us/app/google-chrome/id535886823) by injecting a
> polyfill into the `WKWebView`. You can test it by opening this link
> https://blog.chromium.org/2019/12/chrome-80-content-indexing-es-modules.html#:~:text=ECMAScript%20Modules%20in%20Web%20Workers
> with Chrome.
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Feedback on Blink's text fragment directive proposal

[Thomas Steiner via webkit-dev]

On Wed, Jun 9, 2021 at 6:27 PM Megan Gardner 
wrote:

> We are store the explicite range/position information in the associated
> note, and also use text matching as a fallback.
>

Thanks for responding! Any desire to adopt the Text Fragment syntax (
https://web.dev/text-fragments/) for the (brilliant) Quick Notes feature?

Note that we have enabled this feature in Chrome for iOS (
https://apps.apple.com/us/app/google-chrome/id535886823) by injecting a
polyfill into the `WKWebView`. You can test it by opening this link
https://blog.chromium.org/2019/12/chrome-80-content-indexing-es-modules.html#:~:text=ECMAScript%20Modules%20in%20Web%20Workers
with Chrome.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Feedback on Blink's text fragment directive proposal

[Megan Gardner via webkit-dev]

We are store the explicite range/position information in the associated note, 
and also use text matching as a fallback.

Megan Gardner

> On Jun 8, 2021, at 2:24 AM, Thomas Steiner via webkit-dev 
>  wrote:
> 
> Hi all,
> 
> Seems like Quick Notes, announced at WWDC2021 (deep-link: 
> https://youtu.be/0TD96VTf0Xs?t=2832 ), 
> implements the behavior of Text Fragments, including the highlighting part 
> and the disambiguation of duplicate texts (see my screencast 
> https://youtu.be/4MzxJGZvt1Y ). I fail to 
> reverse-engineer how this works, but from observing the behavior it well 
> looks like it could be using the #:~:text=foo syntax. Can you shine some 
> light on this?
> 
> Thanks,
> Tom
> ___
> 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: preferCurrentTab

[Elad Alon via webkit-dev]

This is a request for WebKit's position on adding a dictionary member in
MediaStreamConstraints called preferCurrentTab. If preferCurrentTab is set
to true, the user agent will display the current tab as the most prominent
option in the media-picker which getDisplayMedia invokes.

Links:

   - Explainer
   

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