More like the non-Chrome browser for which Chrome developers must find workarounds. I can't remember encountering a Safari specific problem in the tens of websites I have developed in the last years. Now sure I understand the pain if you are developing web apps instead, but in that case maybe it's time to assume Chrome is an app platform (OS ?) and not just a browser, and simply only target that platform and don't try to shoehorn the web into it?

The web itself is an app platform. The only browser preventing it to happen on mobile is Safari. Have a look at the desktop. There, web apps have replaced most native apps long ago.

And indeed when we have a look at the desktop it further proves the point, Electron apps ship their whole execution platform, basically an OS inside an OS, and it's Chrome. So the divorce between Chrome the app platform and the web has already started. Safari is a blessing for me because it force that issue to crop up and be discussed, instead of just letting the web slowly become the Google platform.

It's not. And frankly will never be.

> The only browser preventing it to happen on mobile is Safari.

It's not preventing anything

> look at the desktop. There, web apps have replaced most native apps long ago.

What a strange fantasy world you live in.

I do admit sometimes I feel Safari to be lagging behind, but I think it's a far cry from the 'new IE'. At the very least it's not a given that it's the problem browser for developers.

However, in my view: as one of the four stewards of WHATWG, Apple have an obligation to either implement the standard, or propose a convincing alternative that the steering group can adopt.

I don’t know what’s more embarrassing; that Apple tried to use market power to modify a standard after failing to do so in committee, or that after six years even that strategy was a failure. Either way it all smacks of institutional arrogance.

That's how how standards work

If Apple do not wish to implement the standard, they should leave the steering group.

No, they shouldn't.

There was another standard, HTML Imports. It was agreed on, but then Mozilla decided not to implement them. Should Mozilla leave the steering group, too?

Members of a standards body are accountable for their actions. Endorsing a standard, then undermining it, is a gross dereliction of duty. These omissions have a direct impact, and you can draw a straight line from Apple’s overwhelming institutional arrogance to Safari being the “new IE”.

It's utterly disgusting because you just know that good proposals are nixed behind the scenes because Google doesn't want anyone disabling JS - their ads would suffer. More JS == GOOD, more declarative stuff in the spirit of HTML == BAD.

I really wish Apple would go their own way and propose and implement alternatives. Better than taking Google's highway. I would prefer a fragmented ecosystem over the Tyranny Of Chrome that wants to destroy your privacy and the spirit of the world wide web.

> Many years ago, Apple's WebKit team argued that we should have declarative way to define custom elements without scripts but we lost to the aggressive push by Google to get things shipped and iterate on it later ASAP.

[1] https://twitter.com/rniwa_dev/status/1352322006448947203

Apple are complaining here about their own failure to be convincing. They’ve then had the better part of a decade to find a better approach, and produced nothing concrete. Compounding one failure with another doesn’t improve their position.

This isn’t David v Goliath; WHATWG has four members, and none of them are underdogs. None of the participants here deserve even a shred of sympathy.

Yes, yes they are. This also means that none of the browser implementors should be on the steering committee by your criteria.

> Endorsing a standard, then undermining it

Let's see about that endorsement and "undermining":

--- start quote ---

Now I'm going to re-iterate that Apple objects to extending subclasses of HTMLElement using is= as currently spec'ed for various reasons we've stated in the past and this feature won't be supported in WebKit.

...

I'll note that we've vocally and repeatedly objected to having is=, and in fact, stated publicly that we won't implement this feature, but somehow the WG kept it in the spec. I wouldn't call that a consensus. We extremely reluctantly agreed to keep it in the spec until it gets removed at risk later.

...

we're against subclassing subclasses of HTMLElement (e.g. HTMLInputElement, etc...) for various reasons, so WebKit isn't going to support this feature anyway. Extension of builtin elements are much better served with mixins.

...

And this entire comment: https://github.com/WICG/webcomponents/issues/509#issuecommen...

--- end quote ---

So did Safari endorse Web Components? Yes. And they still do. See, for example, Template Instantiation Proposal (among many other things): https://github.com/WICG/webcomponents/blob/gh-pages/proposal...

Did Safari ever support `is=`? No.

Let's see their endorsement again:

--- start quote ---

The thing is, Apple has been objecting to this feature from the get go, and the only reason it remains in the spec is because Google kept objecting to it being removed from the spec.

The fact of matter is, we only agreed to keep it in the spec to wait until the feature becomes at-risk at CR stage so that it can be removed.

--- end quote ---

I would also recommend you read this comment on the whole process and "obligation to implement" and other things (it's not from Apple): https://github.com/WICG/webcomponents/issues/509#issuecommen...

> and you can draw a straight line from Apple’s overwhelming institutional arrogance to Safari being the “new IE”.

There's definitely a PR manager in Chrome who gets a bonus every time this line is repeated. See breaking the web forward: https://www.quirksmode.org/blog/archives/2021/08/breaking_th...

Trivialising the issue with whataboutism doesn’t make Apple any less culpable. Sure, shit sticks to other vendors too. Google often behave appallingly, but this’ll be my first and last mention of them in this thread, and I feel just fine about that having given them plenty of stick in the past. My comment was and remains about WebKit.