W3C home > Mailing lists > Public > public-html@w3.org > February 2011

Re: combining relations from multiple link elements, Re: ISSUE-125: charset-vs-quotes - Straw Poll for Objections

From: Philip Jägenstedt <philipj@opera.com>
Date: Mon, 21 Feb 2011 22:48:59 +0100
To: public-html@w3.org
Message-ID: <op.vq9v7tdzsr6mfa@nog>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:22 GMT