Is the issue here that a worse idea got accepted, or that a better idea got accepted over one that took much longer to develop?
If the proposed idea from this "single Apple employee" is obviously inferior, then that does indeed sound like a problem. But apparently the idea was discussed for a few days. So it doesn't sound like it's conclusively worse.
When it comes to programming -- especially creating the spec for something this fundamental -- then the best idea should win, irrespective of how long that idea took to be born. If you're cheesed because months of discussion and (semi-)consensus was bumped by a better solution that took days to be discussed, then that's not a problem, that sounds like exactly what should happen.
The point of TFA is that there was a long debated solution in the works that got tossed aside in favour of something a vendor representative chucked in.
How can you determine if it's technically superior if you discriminate on the basis of the source of the feature? Choosing between death-by-committee or trusted-auto-approval is not hard.
i.e. the vendors, and not the community of people interested, are in effect (if not necessarily intentionally) dictating the process. The upshot is we'll see features that benefit browser vendors (whether in ease of implementation or insert-conspiratorial-nefarious-Apple-vertical-integration) rather than features that benefit web developers.
Yes, but the long-debated solution settled on a solution that obviously wasn't very strong, if it can't withhold an external suggestion like this.
Mostly what I get from the article is the sense that people are put off not because of how the Apple proposal was put up for discussion, but that they spent months of their time discussing something, and feel like they got nothing for it. And that rings false to me; either that discussion was useful and helped them identify something superior Apple proposal, or the discussion was a waste of time and resulted in nothing useful, in which case they should just be mad at themselves (or the process).
I don't get the Apple conspiracy angle here. They want something that works better with WebKit? So that means that all of iOS, Android, Chrome and Safari browsers benefit.
>Yes, but the long-debated solution settled on a solution that obviously wasn't very strong, if it can't withhold an external suggestion like this.
The implication is that the long-debated solution lost out not because it was inferior but because it didn't come from a browser vendor. After all, the difference in timescale and hoop jumping is stark.
And the implication of that is that no browser vendors were involved in the months-long discussion. If that's true, then that seems like a huge mistake on the part of the committee.
There is no "Apple conspiracy angle". Nobody has suggested Apple were forcing their implementation.
They aren't even angry that they spent months for the proposal to be rejected.
They're angry that they go through the standard processes for months, when vendors seem to just throw an idea out there and it's in the spec within days.
Nobody's blaming Apple. It just appears from the outside that there is a rule for vendors, and a rule for everyone else.
If the proposed idea from this "single Apple employee" is obviously inferior, then that does indeed sound like a problem. But apparently the idea was discussed for a few days. So it doesn't sound like it's conclusively worse.
When it comes to programming -- especially creating the spec for something this fundamental -- then the best idea should win, irrespective of how long that idea took to be born. If you're cheesed because months of discussion and (semi-)consensus was bumped by a better solution that took days to be discussed, then that's not a problem, that sounds like exactly what should happen.