[Webkit-unassigned] [Bug 51941] refactor HTMLLinkElement to allow Link header implementation

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=51941





--- Comment #28 from Gavin Peters <gavinp at chromium.org>  2011-01-07 13:12:51 PST ---
Thanks for your comments Alexey.  I've uploaded another patch, this one incorporates what you've said to date: I remove the extraneous test, and I move the clearOwnerNode() call to the proper destructor.

(In reply to comment #24)
> Link prefetch doesn't parse a style sheet, or load stylesheets that it imports, so a CSSStyleSheet makes no sense in LinkLoader.
> 
> Bug 51940 is about the less controversial parts of Link header field, and rel=stylesheet is definitely not one of those.

Definitely not.  I included it in this refactoring because I didn't want to close that option to us in the future; but I am right now among the skeptical that rel=stylesheet will make sense.  That having been said, the HTMLLinkElement had a lot of logic that felt like it was more connected to resource loading than HTML parsing in it, and so I moved that out as I did.

> > I brought this up in WebKit-dev, and the suggestions came back to try to keep as much code in common as possible between the two paths
> 
> Yes, that makes good sense. What are the common parts between the two forms of link prefetch?

It's all in the ::process() method now for both, and the rel type parser.  As well, since a link can have multiple rel types, any HTMLLinkElement can be both a stylesheet and a preload, for instance.

> Firing beforeload is probably one of those, but it means that loads initiated from HTTP headers need to be delayed until after a beforeload handler has a chance to be installed. Is that something that's going to be implemented?

Probably not.

> On the other hand, linkLoaded() and linkError() seem unclear. What's the use for those for a prefetch load initialed from an HTTP header? HTMLLinkElement::linkLoaded() only dispatches an event, but there is no target to dispatch this event for an HTTP header field.

I doubt that we'll put javascript in HTTP headers; that seems like a bad plan.  The default implementation for those methods in LinkLoaderClient foreshadows this: the intention is that in the header case we'll just use the default implementation for these methods.

- Gavin

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.