I'm not seeing the principled reason for your objection to the capability.
-
-
Because the user pays for data received and not asked for
1 reply 0 retweets 1 like -
that's already the case: server sends response with arbitrary data and subresource cascades.
1 reply 0 retweets 4 likes -
The user agent requests the sub resources
2 replies 0 retweets 1 like -
User-agent != User. Also, there is still the response payload, with arbitrary inlined content.
1 reply 0 retweets 1 like -
Sure, but that’s visible and somewhat comprehensible for the user. Background push isn’t.
2 replies 0 retweets 1 like -
how is an uncompressed, or unused resource comprehensible to the user today? it's not. via tooling, sure, and we show push there as well.
1 reply 0 retweets 1 like -
So you argument is that because something is bad, it doesn’t matter if we make things worse?
1 reply 0 retweets 1 like -
no, I'm saying we're placing undue constraints on what could be a useful and powerful feature to deliver better experiences. :)
1 reply 0 retweets 2 likes -
Anything more than one RTT?
1 reply 0 retweets 1 like
I'm so confused. Are you also opposed to WebSockets? How about SSE? Or multipart mime? What about trailers?
-
-
Those are all in response to a request I can choose not to make
1 reply 0 retweets 1 like -
Who is "I"? A browser?
0 replies 0 retweets 0 likes
End of conversation
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.