Did you know that I ported gecko to iOS *twice*? Once back in 2010 on a jailbroken device and once again in 2015 on stock iOS:https://imgur.com/tBGy9hB
-
-
-
Replying to @slightlylate @TedMielczarek
This might be the way to distribute alternative browser's on iOS: https://youtu.be/ftyWe6DVvO4 I know there will be some limitations, but hey, whatever works. But probably still not enough to invest in such browser's development.
1 reply 0 retweets 0 likes -
Replying to @nekrtemplar @TedMielczarek
That's the issue; Apple's explicit policy suppresses both extant and potential browser competition. Combined with the worst-in-the-industry feature pace of their engine, a death knell for the web as computing goes mobile.
1 reply 0 retweets 2 likes -
I agree with the sentiment that it'd be great to see more feature investment from Apple. If Apple relented on their iOS policy & allowed 3rd-party browser engines, the main effect would be a larger share for browser market leader Chromium. That's a decrease in competition.
1 reply 0 retweets 2 likes -
Replying to @robpalmer2 @slightlylate and
Or they could compete by merit?
1 reply 0 retweets 10 likes -
Replying to @hashseed @robpalmer2 and
Lots of folks seem to accept that engine diversity is *de facto* desirable. It doesn't take much interrogation of this to see the edges. E.g., what if we had a 100 evenly-distributed engines, but half of them never added any new features? Or only features 2/3 of engines have?
3 replies 0 retweets 6 likes -
Replying to @slightlylate @hashseed and
In that configuration, it only takes 34% of engines adopting that policy to stall all progress. So we should be clear and specific about what we want engine diversity to achieve. Ability to diverge/go-own-way? Perf competition? Feature pace? Ecosystem resilience?
3 replies 0 retweets 3 likes -
Replying to @slightlylate @hashseed and
I think we've seen pretty clearly that if it weren't for other engines existing (and even with them), Chrome will kind of ignore the W3C and just do whatever the hell it wants. Monopolies are bad for the web. Always.
2 replies 0 retweets 1 like -
Replying to @ChrisFerdinandi @hashseed and
First, I run standards for Chrome, so I can say categorically that we hold ourselves to a process that is the opposite of "do whatever you want". Next, who do you think the W3C *is*? At TPAC 2 weeks ago, Google sent more engineers and PMs than any two other engines *combined*.
2 replies 0 retweets 1 like
Our process is documented here: https://www.chromium.org/blink/launching-features … It *doesn't* gate things on the idea that things have to be standards to be worth adding, but it is more careful in every way about adding risky (new) features than any competing project's process -- *which we all do*.
-
-
Replying to @slightlylate @ChrisFerdinandi and
If nobody leads, we never go forward. Chromium imposes a high structural tax on leadership to ensure community feedback is at the center of the process, and that risks are low. The WebVR/XR saga show this process at work.
1 reply 0 retweets 1 like -
Replying to @slightlylate @ChrisFerdinandi and
There was consensus in the WG circa '17 that the then-current spec would need to be overhauled and wasn't going to be the thing to standardise. Other vendors shipped it anyway!
1 reply 0 retweets 0 likes - 8 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.