Hi Chris, I'm one of the point people for making Google sure sites aren't (or don't stay) Chrome only. LMK if you see new ones. That said, a frequent cause is lack of useable features in other browsers when trying to do ambitious things. I ask teams to publish these lists.
-
-
Replying to @slightlylate @cwiiis
We (Chrome) do not want a Chrome or Chromium-only world. It's harder to make progress on this when other browser teams under-fund engine development, tho. Puts well-meaning teams in a tough bind.
1 reply 0 retweets 2 likes -
Replying to @slightlylate
Yes, true - though there's definitely a responsibility for a company with as vast resources as Google not to just muscle through.
2 replies 0 retweets 2 likes -
Replying to @cwiiis
This isn't abstract; it's about shipped bits we don't control. A quick example: Service Workers on Google's biggest properties. These are *hugely* latency sensitive services. If rollout of a feature slows things down, that can block a launch. Enter Navigation Preload.
1 reply 0 retweets 1 like -
Replying to @slightlylate @cwiiis
Nav Preload is a feature we designed in collaboration with Facebook and the Site Isolation team as they were looking into the latency impacts of Service Workers. It gets things started much sooner, allowing us to avoid blocking network fetches on (potentially slow) disk.
1 reply 0 retweets 1 like -
Replying to @slightlylate @cwiiis
Google's highest-traffic sites need nav preload to be able to enable Service Workers. This has been communicated to other vendors for a long, long time now. And yet (see the bottom):https://developer.mozilla.org/en-US/docs/Web/API/NavigationPreloadManager …
1 reply 0 retweets 1 like -
Replying to @slightlylate @cwiiis
The result is other vendors telling us how unfair it is that we don't offer these features to their browser. Except we can't. It'd be a worse experience for users if we did! Unlocking progress means both sides need to deliver.
1 reply 0 retweets 1 like -
Replying to @slightlylate
That line of argumentation doesn't fly though, other browsers don't not implement it out of malice for Google's users. There are good reasons others don't just drop everything they're doing to service Google's needs (which is essentially what is being asked for here)
1 reply 0 retweets 0 likes -
Replying to @cwiiis
Nobody needs to be acting with malice here. It only requires a genuine disagreement about priorities and goals to get into the situation I described.
1 reply 0 retweets 2 likes -
Replying to @slightlylate @cwiiis
And it isn't just Google sites. There's a generalized difficulty about listening to customer.
1 reply 0 retweets 1 like
Adding features to browsers isn't just about writing code. Each OSS browser has it's own hierarchy of planning, process, and reviewership. We tried getting new features into WebKit when we were contributing >50% of patches, and it didn't work (hence Blink).
-
-
Replying to @slightlylate @cwiiis
So, for the set of features that are uncontroversial (no matter how that happened), just writing code can be a meaningful improvement. But that doesn't describe situations like Nav Preload where some engines don't prioritize no matter how many huge sites tell them they need it.
1 reply 0 retweets 1 like -
Replying to @slightlylate @cwiiis
And, so we're clear, some fraction of this *is* teams not prioritizing the way I'd prefer. I'll advocate to those teams to do better if/when they're pointed out to me; we have org support to make this situation not suck to the extent the issue isn't missing essential features.
2 replies 0 retweets 1 like - 4 more replies
New conversation -
-
This Tweet is unavailable.
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.