[webkit-dev] beforeload & link (esp rel prefetch)

[Gavin Peters (蓋文彼德斯)]

Thanks for your message, Maciej!

On 14 January 2011 13:53, Maciej Stachowiak <mjs at 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 insurmountable?  Currently the bug up for
> review, bug 51941 doesn't remove beforeload handling from anything that had
> it.  The semantics of beforeload handlers for link headers wrt extensions
> bear some thought, but I suspect these can be solved: can we create another
> bug for adding this suppo
>
> It's not obvious how it could work, since a load triggered by a Link header
> has no associated element, and in fact starts before any elements exist. So
> there is nothing that can act as the event target. If you think it can be
> done, how about a proposal?
>

Certainly immediately, the first thing that comes to mind is that we
continue, as WebKit has for as long as it's had the rel types dns-prefetch,
prefetch & icon, to not issue beforeload events on these elements.  That's
the behaviour now, and it's been acceptable to date.  Are you convinced it
was a mistake to omit these rel types from beforeload now?  That question
seems independent of the Link header that's also been discussed in this
thread, but if I'm wrong I'm totally open to hearing why it's a blocker now.

If we decide to issue them, particularly on the header, I concur that it's
tricky.  I don't have a great proposal now for handling beforeload in link
headers, and I'm not sure the ideas I do have are developed enough to really
share, I suspect they're all both obvious and naive given the problem.  But,
counter balancing this problem, I'd like to continue to experiment with this
feature and learn what benefits it has to offer.  What's the way forward on
that?

- Gavin

>
>
>
> On 13 January 2011 12:48, Alexey Proskuryakov <ap at webkit.org> wrote:
>
>>
>> 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 discussed in this thread, we'd break some browser
>> extensions like Incognito if resource loading could bypass onbeforeload. As
>> another example, we'd break<base> element.
>> >
>> > Well, there are document types where you *can't* inline the metadata.
>>
>>
>> Indeed, and I don't have anything against metadata as long as it doesn't
>> directly modify actual data. For example, Last-Modified and Cache-Control
>> are quite obvious example of what can be in HTTP headers. Despite the
>> practical/historical difficulties that I mentioned with Content-Type, it's
>> arguably a valid example of metadata, too.
>>
>> Subresource references on the other hand are a part of a document, not of
>> its metadata. Am I just missing a reason why one would want to prefetch
>> subresources for a JPEG image?
>>
>> > We should distinguish between the act of declaring the link, and the
>> moment where a potential fetch actually happens (it doesn't always happen,
>> after all).
>> >
>> > I agree that stuffing things just to get a fetch to happen "earlier"
>> maybe a premature optimization.
>>
>>
>> Optimizing prefetch to start before actual document data arrives is highly
>> controversial, but I believe that it's the primary reason why we're
>> considering the Link header implementation.
>>
>> - WBR, Alexey Proskuryakov
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110114/7d1c8c42/attachment.html>