I think that adding beforeload to META-based prefetch and icon types makes a
lot of sense. For subresource rel type, we may want to register it first, as
mentioned by Julian.
Steps 3-5 obviously depend on whether we want to proceed with adding support
for the Link header field, which I'm not
2011/2/23 Alexey Proskuryakov a...@webkit.org:
I think that adding beforeload to META-based prefetch and icon types makes a
lot of sense. For subresource rel type, we may want to register it first, as
mentioned by Julian.
Looks like Gavin already registered it on 5 November 2010, so we're
23.02.2011, в 17:06, Adam Barth написал(а):
I think that adding beforeload to META-based prefetch and icon types makes a
lot of sense. For subresource rel type, we may want to register it first, as
mentioned by Julian.
Looks like Gavin already registered it on 5 November 2010, so we're
2011/2/23 Alexey Proskuryakov a...@webkit.org:
23.02.2011, в 17:06, Adam Barth написал(а):
I think that adding beforeload to META-based prefetch and icon types makes
a lot of sense. For subresource rel type, we may want to register it first,
as mentioned by Julian.
Looks like Gavin already
Hi!
I'm returning to this work now, and I see that folks have been quiet about
this since I posted my plan. Here's how I'm going to proceed:
Step 1: I will add beforeload to prefetch icon rel types. Expect a CL for
this soon.
Step 2: I will add a new subresource rel type, which will have
2011/1/20 Gavin Peters (蓋文彼德斯) gav...@chromium.org:
I also have thought about how we can go forward, I'd like folks
comments on this:
Step 1: Land bug 51941, a refactoring of the HTMLLinkPrefetch element
which pulls out loading for rel types prefetch, icon and dns-prefetch.
That sounds like
Folks,
I want to thank everyone who contributed to this thread on beforeload,
the link element, and the HTTP link header. The consensus was that it
was a mistake to add rel=prefetch without beforeload handlers, and
that it's a mistake to permit link headers to launch resource requests
before an
On Jan 20, 2011, at 5:52 PM, Gavin Peters (蓋文彼德斯) wrote:
[2] I just installed Incognito mode in a local Safari, and sniffed it. I can
confirm requests to blocked domains go straight through; with cookies,
everything. The only place you won't see them is in the document, the DOM
the Safari
2011/1/20 Darin Adler da...@apple.com:
On Jan 20, 2011, at 5:52 PM, Gavin Peters (蓋文彼德斯) wrote:
[2] I just installed Incognito mode in a local Safari, and sniffed it. I can
confirm requests to blocked domains go straight through; with cookies,
everything. The only place you won't see them is
My apologies for the confusion: I did indeed mean the Safari extension
incognito that Adam linked to, and not a mode.
Alexey brought up this extension earlier in the thread as an example of a
use of beforeload that should be permitted.
- Gavin
On Jan 20, 2011 8:55 PM, Darin Adler da...@apple.com
On Jan 13, 2011, at 2:49 PM, Gavin Peters (蓋文彼德斯) wrote:
Thanks everyone for your replies on link headers and rel types.
Mike Belshe from Chrome team put together a spec for these as part of Server
Hints for SPDY. His server hint information is at:
2011/1/14 Maciej Stachowiak m...@apple.com
On Jan 13, 2011, at 2:49 PM, Gavin Peters (蓋文彼德斯) wrote:
Thanks everyone for your replies on link headers and rel types.
Mike Belshe from Chrome team put together a spec for these as part of
Server Hints for SPDY. His server hint information is
Thanks for your message, Maciej!
On 14 January 2011 13:53, Maciej Stachowiak m...@apple.com wrote:
I agree that beforeload support could be more pervasive than it is today.
The exclusion of prefetch, icon and dns-prefetch from beforeload events
bears revisiting. But are these
On 13.01.2011 07:42, Darin Fisher wrote:
Firefox definitely supports rel=prefetch in HTTP Link headers. I believe
it also supports other rel types, like stylesheet. The rel=subresource
bit is something new.
Yes, stylesheet is supported.
For subresource, I *really* would like to see a proper
12.01.2011, в 22:42, Darin Fisher написал(а):
Supporting the Link header enables web servers to inject link tags without
modifying the document, which can be useful, especially for intermediaries.
I'm wondering what the use cases are. To me, adding a way for metadata to
change document
On 13.01.2011 18:02, Alexey Proskuryakov wrote:
12.01.2011, в 22:42, Darin Fisher написал(а):
Supporting the Link header enables web servers to injectlink tags without
modifying the document, which can be useful, especially for intermediaries.
I'm wondering what the use cases are. To me,
13.01.2011, в 09:14, Julian Reschke написал(а):
I'm wondering what the use cases are. To me, adding a way for metadata to
change document behavior sounds like a misfeature - it adds significant
complexity to the system, while taking away existing functionality. As a
specific example
On Thursday 13 January 2011 17:02:15 Alexey Proskuryakov wrote:
As a specific example discussed in this thread, we'd
break some browser extensions like Incognito if resource loading could
bypass onbeforeload.
Could you elaborate on this a bit? I don't understand the potential
breakage.
13.01.2011, в 11:34, Robert Hogan написал(а):
As a specific example discussed in this thread, we'd
break some browser extensions like Incognito if resource loading could
bypass onbeforeload.
Could you elaborate on this a bit? I don't understand the potential
breakage.
Privacy
2011/1/13 Darin Fisher da...@chromium.org:
Supporting the Link header enables web servers to inject link tags without
modifying the document, which can be useful, especially for intermediaries.
That sounds like a great reason not to support this feature. Why would
we want to make the web more
Thanks everyone for your replies on link headers and rel types.
Mike Belshe from Chrome team put together a spec for these as part of Server
Hints for SPDY. His server hint information is at:
https://sites.google.com/a/chromium.org/dev/spdy/link-headers-and-server-hint,
and link rel=subresource
Folks,
Right now in WebKit, beforeload events are not universally sent for link
elements. In particular, link elements with the rel type icon, dns-prefetch
and prefetch do not generate beforeload events. In a recent review of bug
51941, ap raised the question that perhaps they should be sent.
On Wed, Jan 12, 2011 at 8:05 AM, Gavin Peters (蓋文彼德斯)
gav...@chromium.orgwrote:
1. Should HTML Link rel=prefetch have beforeload events?
2. How about rel=icon and rel=dns-prefetch ?
I don't see why these wouldn't fire beforeload. They are resource requests
like any others. I don't know
Chromium-specific note:
link rel=icon is loaded externally to WebKit, which will likely complicate
matters here.
-Darin
On Wed, Jan 12, 2011 at 8:52 AM, Ojan Vafai o...@chromium.org wrote:
On Wed, Jan 12, 2011 at 8:05 AM, Gavin Peters (蓋文彼德斯) gav...@chromium.org
wrote:
1. Should HTML
On 12.01.2011 17:05, Gavin Peters (蓋文彼德斯) wrote:
...
As background, I'm right now refactoring the HTMLLinkElement to pull out
the loader that handles the abovementioned three rel types. I'm doing
this in preparation for adding Link header support, initially for these
three rel types, as they
12.01.2011, в 10:26, Julian Reschke написал(а):
they are not so controversial as for instance
putting rel=stylesheet in the HTTP headers.
...
Out of curiosity: what's controversial about that?
Some of the discussion is written down in
https://bugs.webkit.org/show_bug.cgi?id=20018.
Do other browsers support these values in the HTTP Link header? Do Web sites
use them? I think the idea of triggering subresource loads from HTTP headers
instead of the HTML itself is problematic. We should support it only to the
degree required for Web compatibility.
Regards,
Maciej
On Jan
Firefox definitely supports rel=prefetch in HTTP Link headers. I believe it
also supports other rel types, like stylesheet. The rel=subresource bit is
something new.
Supporting the Link header enables web servers to inject link tags without
modifying the document, which can be useful,
28 matches
Mail list logo
