These are good points, but here are some more to consider:

- Apple, particularly recently, have been terrible on supporting modern web proposals. Worse than anyone. Much worse than the typical historical reputational lower bar that is Microsoft.

- Apple's record on proposing new web standards has been demonstrably aggressively anti-open and not generally condusive to promoting interop https://www.w3.org/2012/te-pag/pagreport.html

- Apple's general record on cross-platform development is pretty much non-existent. To the contrary, much of their business decisions are specifically based on limiting interop with non-Apple platforms.

I think on a holistic level, if you take Apple's record into account at all, any criticisms from them of a cross-platform proposal of any kind need to be taken in context. Before you even start considering the pros and cons of Vulkan or WebVulkan, there's a very blatant case of cui bono to examine behind this.

Even if you do get past that, the points about commonality between native and web APIs are growing more and more relevant every day as Emscripten, WebAssembly and other such tech brings the two worlds closer to each other. Cross-compilation efforts will invariably be made easier with a more consistent API between (web and native) platforms.

"Before you even start considering the pros and cons of Vulkan or WebVulkan, there's a very blatant case of cui bono to examine behind this."

Not really. Because yes, it is well known that Apple closes down their system and wants full controll over it and locks other partys out. One of the Reasons for me, to not buy them.

But what does this have to do, when they propose a new Web API? If Apple chooses to go a different way with metal (and a way apparently quite some devs like), than I don't see much point in trying to force them to go another way. Maybe metal is even superior - I can't judge that, but I am not going to say vulkan is superior, just because it is open(even though I would like it to be superior just for that fact). ButI don't see much point in dragging Web-Technologys into these discussion in the first place.

Especially since apparently it is possible to implement the proposed WebGPU on top of metal, vulkan or Direct3D !!

And even though "Cross-compilation efforts will invariably be made easier with a more consistent API between (web and native) platforms." is true , it is not gonna happen at the moment, since simply not everybody wants vulkan at the moment, but 2 major players stick with something else. And I am not sure it is only for power reasons, but maybe also for technical reasons, as I read from quite some devs, that working with vulcan is huge pain(and they prefer metal, if it would be open) .... as it is not made for working with it directly, but rather to be worked through a higher level API. So ... is there a different proposal for that higher level API than WebGPU to be discussed right now?

> But what does this have to do, when they propose a new Web API?

The web being inherently cross-platform in nature there's a motivation on their part to not support it, or - in this case - cripple it (perhaps to a mild degree but at least enough to render it categorically inferior to native metal and not worth the trade-offs). I can't say that their proposal does this necessarily, but there's inarguably a motivation to do so.

For a previous obvious example of this kind of thing, see the deliberate crippling of iOS UIWebView.

> I am not sure it is only for power reasons, but maybe also for technical reasons

Call me a cynic, but while there may be good, valid technical arguments against Vulkan, it's mainly for power reasons.

Hm, do you really believe, that Apple wants to artifical cripple the web?

I see, that they hypothetically might have motivation, to do so ... but this is not valid, since the web is inferior to native implemantations in the first place! The "only" advantage of the web is, that it is more or less, cross plattform.

As far as i can remember, they've been consistently behind on support for emerging web technologies (since the app store came out), it just doesn't seen to be in their business interests to keep up.

Not really. What about MSE / DASH and touch events? Apple were often hindering adoption if new technologies, if they had their own locked up / patented alternatives, which they didn't want to undermine my accepting open competition.

But it is something different, to not "keep up" with full priority, than to intentionally sabotage WebStandards ...

Sabotage is a strong word, but it doesn't have to be intentionally malevolent. In psychology the word sabotage is often used to describe situations where people don't have faith in relationships (maybe because of personal hangups) and go at them half heartedly. When their relationships fizzle out, people said to "sabotage relationships" are often left feeling confused about what happened.

Apple has consistently shown that their locked down platform is priority number one. I think there are people who, for better or worse, have grown wary of that and need some extra convincing if Apple wants to influence big decisions.

Safari feels more and more like IE to me as the years go by. I just have a hard time taking it seriously and don't go out of my way to support it, just like Apple doesn't go out of it's way to support it when they have proprietary platforms that they can make vastly more money from.

All that said, yes, Apple has pushed the envelope from time to time, and has made some major contributions to open standards, so credit where credit is due, and accountability where accountability is due.

The UIWebView is an interesting example. They released significant performance advances in the iOS Safari web browser, but denied those features to developers of cross-platform apps on frameworks such as Cordova, artificially degrading the performance of Cordova apps compared to natively developed iOS apps. Both need to go through the AppStore anyway, but keeping as much dev lock-in as possible in terms of the tech used is obviously an interest here.

Add to that the fact that what positive feature development there has been in Safari (e.g. the above-mentioned excellent es6 support in the Technical Preview) has very specifically excluded the addition of any of the APIs that begin to blur the web/native divide (web notifications, userMedia, service workers, &c.)

But where does your example show, that they sabotage webstandards?

It shows what I said before, yes they control their system and making it harder for other implemations if they want ... but his is something completely different.

... and it might be that they dont like certain standards ... but graphics is a different category.

>the web is inferior to native in the first place

The web is de facto inferior, but it is not de jure inferior. That is to say that many people would very much like to see the web match native in capability, and efforts that derail this effort are criticized in kind.