4 ms·

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

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...

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...