5 ms·

Webkit is not committed to fully implementing the HTML Living Standard, or more precisely, they are committed to killing off the parts they don't like by declin

Webkit is not committed to fully implementing the HTML Living Standard, or more precisely, they are committed to killing off the parts they don't like by declining to implement them. They point-blank refuse to implement Customized Built-in Elements, for example, and in such (unusually, for the context) vehement, uncompromising, and unconstructive language¹ that I can only surmise some Apple apparatchik's fragile ego would be irreparably shattered by even contemplating an amendment of this position. Thanks to such attitudes, Safari remains the "new IE", the problem browser for which developers must find workarounds. (1) e.g. https://github.com/WICG/webcomponents/issues/509 https://github.com/WICG/webcomponents/issues/509 and other forums besides

inopinatus 5y ago
Curiously, the above remark was at +4 and is currently -2, which really just goes to show how polarising Apple is by timezone.
eyelidlessness 5y ago
I glanced at the linked issue and I see demands for disregarding the standard to accommodate a non-standard API. Is that what you’re asking for? Or are you on the side of implementing the living standard as it evolves? If there’s another position I’m missing feel free to fill in the blank.
- inopinatus 5y ago
  That is a very heavily commented ticket (600+ comments) so it’s hard to assess all the alternative positions. 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.
  - dmitriid 5y ago
    They presented a clear case of why they refuse to implement them. That's how how standards work
    - inopinatus 5y ago
      Their reasoning was evidently not accepted. If Apple do not wish to implement the standard, they should leave the steering group.
      - dmitriid 5y ago
        > 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?
        inopinatus 5y ago
        HTML Imports were superseded whilst still a draft. 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”.
        drcongo 5y ago
        There's some impressive projecting going on here.
        dmitriid 5y ago
        > Members of a standards body are accountable for their actions. 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#issuecomment-230700060 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/proposals/Template-Instantiation.md 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#issuecomment-233589604 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_the_we.html https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
tarsinge 5y ago
> Safari remains the "new IE", the problem browser for which developers must find workarounds. 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?
- agust 5y ago
  Sure, simple websites mostly work in Safari. But we're in 2022, and indeed a lot of companies develop web apps, and not simple websites like 20 years ago. 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.
  - dmitriid 5y ago
    > The web itself is an app 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.
    - agust 5y ago
      Very convincing, thank you for this well argued response.
      - dmitriid 5y ago
        It's in the vein of your statements, and it takes too much time to explain why this is wrong. And this has been said many times before by many people far more eloquent and knowledgable than I. Yet this sentiment persists (even if it's driven by emotion on the one hand and relentless Chrome propaganda on the other).
barrell 5y ago
As a long time web dev who primarily uses Safari for development, I find myself constantly looking for workarounds for Chrome. 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.
- agust 5y ago
  That's definitely not representative of the general sentiment. As far as I'm concerned, probably around 95% of my debugging time is spent on Safari. Stuff usually works like a charm in Chrome or Firefox. Safari is a gigantic pain due to its plethora of bugs (and new ones appearing with each release) and missing features preventing you to easily work around them.

inopinatus 5y ago

Curiously, the above remark was at +4 and is currently -2, which really just goes to show how polarising Apple is by timezone.

eyelidlessness 5y ago

I glanced at the linked issue and I see demands for disregarding the standard to accommodate a non-standard API. Is that what you’re asking for? Or are you on the side of implementing the living standard as it evolves? If there’s another position I’m missing feel free to fill in the blank.

inopinatus 5y ago
That is a very heavily commented ticket (600+ comments) so it’s hard to assess all the alternative positions. 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.
- dmitriid 5y ago
  They presented a clear case of why they refuse to implement them. That's how how standards work
  - inopinatus 5y ago
    Their reasoning was evidently not accepted. If Apple do not wish to implement the standard, they should leave the steering group.
    - dmitriid 5y ago
      > 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?
      - inopinatus 5y ago
        HTML Imports were superseded whilst still a draft. 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”.
        drcongo 5y ago
        There's some impressive projecting going on here.
        dmitriid 5y ago
        > Members of a standards body are accountable for their actions. 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#issuecomment-230700060 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/proposals/Template-Instantiation.md 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#issuecomment-233589604 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_the_we.html https://www.quirksmode.org/blog/archives/2021/08/breaking_th...

tarsinge 5y ago

> Safari remains the "new IE", the problem browser for which developers must find workarounds. 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?

agust 5y ago
Sure, simple websites mostly work in Safari. But we're in 2022, and indeed a lot of companies develop web apps, and not simple websites like 20 years ago. 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.
- dmitriid 5y ago
  > The web itself is an app 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.
  - agust 5y ago
    Very convincing, thank you for this well argued response.
    - dmitriid 5y ago
      It's in the vein of your statements, and it takes too much time to explain why this is wrong. And this has been said many times before by many people far more eloquent and knowledgable than I. Yet this sentiment persists (even if it's driven by emotion on the one hand and relentless Chrome propaganda on the other).

barrell 5y ago

As a long time web dev who primarily uses Safari for development, I find myself constantly looking for workarounds for Chrome. 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.

agust 5y ago
That's definitely not representative of the general sentiment. As far as I'm concerned, probably around 95% of my debugging time is spent on Safari. Stuff usually works like a charm in Chrome or Firefox. Safari is a gigantic pain due to its plethora of bugs (and new ones appearing with each release) and missing features preventing you to easily work around them.