HN user
In the case of blink-dev, yeah moderators like me. But AFAIK we didn't block any replies there at all because nobody in that forum was making threats or anything like that. I also haven't seen much of anything on these HN threads which I'd say violates the code of conduct we use on the chromium forums.
Some things just aren't consistent, and I don't believe that you know what "the openness of the web" means, or really care :-).
I certainly could have done a better job trying to convince you of that in that post. Perhaps my follow-up was better? https://groups.google.com/a/chromium.org/g/blink-dev/c/Ux5h_...
FWIW the whole reason I keep working on the web platform at Google is because it's the place I think I can do the most good for openness on the web. See eg. https://thenewstack.io/browser-vendors-aim-to-heal-developer..., https://www.chromium.org/blink/platform-predictability/. "The Master Switch" my Tim Wu is my gospell.
If I and other chromium leads didn't actually care about openness then you'd be able to tell pretty clearly because Chromium would be closed source, we wouldn't have big programs like wpt.fyi, and we wouldn't bother even trying to talk about this stuff on open mailing lists.
Thank you!
Did you read the rest of the thread? Plenty of really good constructive yet forceful feedback on that thread which I was applauding and celebrating.
I think it's pretty disingenuous to suggest that I "tarred all opposition as criminals". Still I admit my wording could have been better, please see follow-up: https://groups.google.com/a/chromium.org/g/blink-dev/c/Ux5h_....
If he can’t differentiate between “negative feedback, delivered abusively” and “negative feedback, delivered forcefully” then he should not be someone involved in this decision-making process.
Have you ever managed a large team of people? If so, do you think a good manager would really tell people that part of their job is to accept threats of physical abuse?
Bingo
Did you see my point later in the thread about moderators like me explicitly approving all the posts which were arguing forcefully (but respectfully) against WEI? I think it's pretty clear we're not shutting down respectful disagreement, only abusive and threatening disagreement.
I'm one of the blink API owners who would need to approve this feature if it were to ship in Chrome. I outlined some of my thoughts on this earlier here: https://groups.google.com/a/chromium.org/g/blink-dev/c/Ux5h_...
It's complex and nuanced, all about altering probabilities of various bad things and TBH work still needs to be done to prove a useful middle ground even exists.
But one thing I can say for sure is there's no way I'm approving Chrome adding a feature which makes it possible for websites to be viewed only in Chrome. Nobody wants that and it's listed as an explicit anti-goal of the feature. Chrome couldn't have existed in the first place without masquerading as Safari, who masqueraded as Netscape etc.., this is something we're all very aware of and committed to in Chrome as its core to the openness of the web.
This is a complicated set of trade offs and I've argued on both sides of the fence so I can't pretend to imply the decision is at all clear cut. But let me respond to a couple details here.
First, the 'jQuery bloat' you're worried about looked like it was going to happen without Chrome native support: http://blog.jquery.com/2015/02/24/getting-on-point/. One of our goals in revisiting the decision was to avoid frameworks like jQuery having to include such polyfills to Chrome users.
The other thing is that we shouldn't assume Chrome doing Pointer Events means we won't also improve Touch Events. That's a complicated decision influenced in large part by participation by other browser vendors in the standards process around Touch Events.
I think there is a valid concern here. But what we're seeing in practice from many major frameworks and apps is that they're unifying events anyway and special-casing the device type when needed for a great experience. Pointer Events still lets you treat the devices distinctly if you want to, and no amount of API design can make up for developers who can't justify investing in building a great UX.
Of course Microsoft has now shown the DO value compatibility enough to implement Touch Events, and is even one of the most active members in the Touch Events community group working to improve Touch Events in the W3C.
I'm pretty sure Microsoft is going to go full steam ahead with pointer events.
Note that even Microsoft acknowledges the "touch events are here to stay" argument: IE mobile now supports touch events: http://blogs.msdn.com/b/ie/archive/2014/07/31/the-mobile-web...
Agreed! We had a great "input face-to-face" meeting at Microsoft back in June, and the collaboration between IE, Safari, Firefox and Chrome teams seems better than ever. Despite our differences of opinion, we finally all appear to be working towards common goals with interoperability foremost.
Right, we (Chrome team) definitely care about multi-input-device scenarios (I started at Google by leading the chrome work for the chromebook pixel). We're just trying to project out 5-10 years where we expect most Interent traffic to come from phones/tablets to a mobile-first (touch-first) world - rather than carry the baggage of the mouse-centric world. Here's some ramblings on how we may be able to evolve touch events to fill this need: http://crbug.com/404128
There was a delay, but we worked past it. The web would definitely be a better place if Apple would participate in the input API standardization process though.
Well said. We're deeply committed on the blink team to making such polyfills and frameworks easy (eg. it's a big part of why we shipped touch-action in blink). That's where the fighting over what API shape is "best" can best happen - in a market with unlimited choice and furious competition.