3 ms·

Alas that Web Components will be forever held back from their true potential until WebKit pulls their obstinate finger out and implements the customised built-i

Alas that Web Components will be forever held back from their true potential until WebKit pulls their obstinate finger out and implements the customised built-ins half of the standard. Or proposes something better that otherwise solves the content model issues. To date they have done neither, leaving us with a shortfall of composability and a fistful of janky polyfills

troupo 2y ago
> Or proposes something better that otherwise solves the content model issues. They have proposed it. They have also explained why the existing proposal for customisable built ins is a loaded gun waiting to explode. > To date they have done neither Tell me you know nothing about the topic without telling me that
- deleted 2y ago
  [deleted]
- deleted 2y ago
  [deleted]
- inopinatus 2y ago
  > They have proposed it. They have also explained [cut] That is laughable. I've been following this since finding that my code extending built-in elements for progressive enhancement in the Hotwire framework was dead in the water on Safari and no polyfill could resuscitate it because the browser infrastructure was fundamentally missing. In reality, Apple have sat on the pot groaning for a decade without taking a dump, and the stated reason in 2016 was this, entirely: rniwa> The problem here is that UA internally checks local name e.g. `element.localName == aTag` to do various things, and all of that code needs to be updated to account for the fact there could be an instance of `HTMLAnchorElement` whose local name is not `a`. Thus frankly placing it in the too-hard-basket, a refreshing piece of honesty from a company that's usually in love with its own bullshit. You don't have to look hard at the WebKit source code to grok that, yes, it surely would require a massive chunk of refactoring. Still, here's the updated response, from 2023, after a flamebait thread on WebKit/standards-positions that attracted a mountain of withering criticism: rniwa> The position has been established. [WebKit locked as off-topic] Which I took to mean, "all of you whinging bastards can get fucked, it's our browser". So it's fundamentally an effort-reward gap for Apple that has become a dug-in entrenched position over time as more product managers flail around hoping to justify it. Pretending an obviously commercial/resourcing decision is due to <bunch of technical reasons> is a common way to avoid committing resources, but any engineer who actually believes that fiction is a damn fool. I'm reminded of Cisco's hissy fit with the IEEE over PoE. Apple aren't dumb enough to miss that refusing to implement part of a published standard erodes their claim of stewardship over that standard, and if a major customer really wanted it, they'd flip-flip in a heartbeat. > Tell me you know nothing about the topic without telling me that Aw, you're gonna hurt my feelings.
  - troupo 2y ago
    > Maybe instead of breaking it down you could help make it better? Its not. > and the stated reason in 2016 was this, entirely: It's not the entirety of the reason > Which I took to mean, "all of you whinging bastards can get fucked, it's our browser" Since you keep completely misrepresenting and lying about Webkit's position, sure. I honestly couldn't care about your vitriol in the rest of your message, or any other messages. Adieu.

troupo 2y ago

> Or proposes something better that otherwise solves the content model issues. They have proposed it. They have also explained why the existing proposal for customisable built ins is a loaded gun waiting to explode. > To date they have done neither Tell me you know nothing about the topic without telling me that

deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
inopinatus 2y ago
> They have proposed it. They have also explained [cut] That is laughable. I've been following this since finding that my code extending built-in elements for progressive enhancement in the Hotwire framework was dead in the water on Safari and no polyfill could resuscitate it because the browser infrastructure was fundamentally missing. In reality, Apple have sat on the pot groaning for a decade without taking a dump, and the stated reason in 2016 was this, entirely: rniwa> The problem here is that UA internally checks local name e.g. `element.localName == aTag` to do various things, and all of that code needs to be updated to account for the fact there could be an instance of `HTMLAnchorElement` whose local name is not `a`. Thus frankly placing it in the too-hard-basket, a refreshing piece of honesty from a company that's usually in love with its own bullshit. You don't have to look hard at the WebKit source code to grok that, yes, it surely would require a massive chunk of refactoring. Still, here's the updated response, from 2023, after a flamebait thread on WebKit/standards-positions that attracted a mountain of withering criticism: rniwa> The position has been established. [WebKit locked as off-topic] Which I took to mean, "all of you whinging bastards can get fucked, it's our browser". So it's fundamentally an effort-reward gap for Apple that has become a dug-in entrenched position over time as more product managers flail around hoping to justify it. Pretending an obviously commercial/resourcing decision is due to <bunch of technical reasons> is a common way to avoid committing resources, but any engineer who actually believes that fiction is a damn fool. I'm reminded of Cisco's hissy fit with the IEEE over PoE. Apple aren't dumb enough to miss that refusing to implement part of a published standard erodes their claim of stewardship over that standard, and if a major customer really wanted it, they'd flip-flip in a heartbeat. > Tell me you know nothing about the topic without telling me that Aw, you're gonna hurt my feelings.
- troupo 2y ago
  > Maybe instead of breaking it down you could help make it better? Its not. > and the stated reason in 2016 was this, entirely: It's not the entirety of the reason > Which I took to mean, "all of you whinging bastards can get fucked, it's our browser" Since you keep completely misrepresenting and lying about Webkit's position, sure. I honestly couldn't care about your vitriol in the rest of your message, or any other messages. Adieu.