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 higher priority than prefetch, otherwise be the same. Step 3: We land bug 51941, which factors out the cache/LinkLoader.cpp from html/HTMLLinkElement.cpp Step 4: We land the Link header parser directly (bug 51940) Step 5: Add beforeload events to the Link header? Comments? On 24 January 2011 18:10, Adam Barth <[email protected]> wrote: > 2011/1/20 Gavin Peters (蓋文彼德斯) <[email protected]>: > > 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 a reasonable first step if we want to go forward with > Steps 4 and 5. Perhaps it would make sense to delay this work until > we're ready to do Step 4? > > > Step 2: Add beforeload to at least prefetch & icon rel types, and hey, > > why not dns-prefetch too! Do this to fix bug 52577. > > It seems reasonable to add beforeload events to prefetch. Icon is > probably worth doing too. I'm less sure about dns-prefetch because > that doesn't actually generate a "load" so to speak. Maybe leave it > off in the first iteration? > > My slight reservation here is that, from a privacy standpoint, there's > no reasonable way to prevent a web site from leading information back > to its server. However, many privacy extensions take a "best effort" > approach rather than an "airtight" approach. In that sense, > generating these events seems valuable because it improve what these > folks can build. > > > Step 3: Add rel type subresource (same as rel type prefetch, only > > higher priority for in-page resources) (need to create a bug for > > this). > > This seems valuable. My understanding is that subresource is similar > to prefetch, just with a different priority (i.e., "please prefetch > this URL in time for it to be used by a subresource of this page"). > > > Step 4: Add Link header, providing rel types subresource, prefetch & > > dns-prefetch only (currently bug 51940). > > This step also makes sense to me because these headers don't modify > the semantics of the document. Supporting them in headers means that > web sites can optimize their performance using middleware boxes > without hacking up their HTML. > > > Step 5: Add beforeload events to the Link header (as a followup after > > bug 51940). > > This seems somewhat odd to me, but I guess it makes sense. There's > some question about where to fire these events, but presumably firing > them on the document itself would be fine. > > I'm willing to believe that my perspective might be biased because > I've been talking to Gavin about these features for a while. I > certainly don't want us to move forward here if folks don't think this > is a beneficial course of action. > > Adam >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
