- From: Philip Jägenstedt <philipj@opera.com>
- Date: Mon, 21 Feb 2011 22:48:59 +0100
- To: public-html@w3.org
On Mon, 21 Feb 2011 21:14:20 +0100, Maciej Stachowiak <mjs@apple.com> wrote: > > On Feb 21, 2011, at 2:09 AM, Philip Jägenstedt wrote: > >> On Mon, 21 Feb 2011 09:42:51 +0100, Julian Reschke >> <julian.reschke@gmx.de> wrote: >> >>> In the poll results, Philip Jägenstedt writes >>> (<http>://www.w3.org/2002/09/wbs/40318/issue-124-objection-poll/results>): >>> >>>> Finally, the change proposal doesn't specify how to handle >>>> conflicting information like this in a page: >>>> >>>> <link rel="stylesheet noreferrer" href="foo.css"> >>>> <link rel="stylesheet nofollow" href="foo.css"> >>>> >>>> Is the effective set of keywords "noreferrer", "nofollow" or >>>> "noreferrer nofollow"? Presumably both browsers and search engines >>>> would be clever enough to only issue one request, but should the >>>> search engine consider "that the link is not endorsed by the original >>>> author or publisher of the page" and should a browser "not include a >>>> Referer (sic) HTTP header"? >>> >>> That's a good question but I don't see how this is specific to these >>> link relations. >>> >>> The spec should have generic statements about how to combine multiple >>> link/@rel elements. If this is a serious problem (*), a bug should be >>> opened independently of this issue. >> >> To avoid confusion, this is about ISSUE-124 rel-limits, not ISSUE-125. >> >> At first I agreed that this should be defined more generally and tried >> to formulate the problem, but failed: >> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12145 >> >> I actually agree that nofollow isn't much different from most other >> link types, but AFAICT no existing keyword type has the problem that >> allowing noreferrer on <link> introduces, namely that the order changes >> browser behavior: >> >> <link rel="stylesheet" href="foo.css"> >> <!-- potential network lag here --> >> <link rel="stylesheet noreferrer" href="foo.css"> >> >> Is the HTTP Referer header sent when fetching foo.css? Unless there >> already exists link types where this problem arises for (browser) >> imlpementations, I'd argue that the CP that introduces the problem >> should also fix it. > > It seems like the issue here is: > > - Some <link> types (e.g. stylesheet, icon) can passively trigger loads, > which are combined when loading the same resource. > - <a> links only load something when explicitly activated by the user, > so there is no issue of combining loads. > - noreferrer alters loading behavior. > > As a result, noreferrer has clear behavior on <a>, but not necessarily > on <link>. Yes, that is precisely the problem I am describing. -- Philip Jägenstedt Core Developer Opera Software
Received on Monday, 21 February 2011 21:49:36 UTC