Re: ISSUE-124: rel-limits - Straw Poll for Objections

On 21.02.2011 04:50, Paul Cotton wrote:
> ISSUE-124: rel-limits - Straw Poll for Objections
>
> The poll is available here, and it will run through Monday Feb 28th:
>
> http://www.w3.org/2002/09/wbs/40318/issue-124-objection-poll/
>
> Please read the introductory text before entering your response.
>
> In particular, keep in mind that you don't *have* to reply. You only
> need to do so if you feel your objection to one of the options is truly
> strong, and has not been adequately addressed by a clearly marked
> objection contained within a Change Proposal or by someone else's
> objection. The Chairs will be looking at strength of objections, and
> will not be counting votes.
> ...

Some comments on the poll answers in 
<http://www.w3.org/2002/09/wbs/40318/issue-124-objection-poll/results>:

Philip Jägenstedt writes:

> No use cases are given for allowing noreferrer or nofollow on <link>. The change proposal claims less special-casing as a positive effect, but this is only from a web authors point of view.

Apparently there is disagreement about whether the change would result 
in less or more special-casing. It would be interesting to hear from 
more implementers about how they handle link relations when following 
links, be it using the Link response header, the <link> elements, or <a> 
etc.

> For browsers, it would likely lead to more special-casing (code sprinkled around to handle this), as loading of inline resources (like CSS) via <link> follows rather different code paths than navigating to a new page via <a> or <area>.

Maybe that's a problem, then.

> 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"?

As stated earlier, this is a general problem you get with the concept of 
link relations. It's not specific to this case, and we should treat this 
as a distinct problem.

So, the answer to "how many request" should be the same as for:

<link rel="stylesheet bar" href="foo.css">
<link rel="stylesheet foo" href="foo.css">

...and the answer about the semantics is: those of "noreferrer" and 
"nofollow". If these are in conflict, it's a problem for <a> as well.

Anne van Kestereren writes:

> I object to this proposal on the grounds that it does not state a use case. Making relationships more general is not necessarily a benefit and I do not believe we should strive for generality in general. We should strive to address use cases in the best way possible.

The issue of making relationships more general is related to ISSUE-27, 
which we'll hopefully get to soon. If HTML5 wants to register "nofollow" 
and "noreferrer", it should state the semantics it'll have in a link 
response header field.

(I've seen people put things into response header fields instead of the 
HTML head section for conformance reasons before, so I wouldn't be 
surprised if people start doing this here as well in order to avoid 
validity problems).

Edward O'Connor writes:

> The CP does not state any use cases for this change; it's not clear if allowing authors to specify noreferrer and nofollow on <link> Solves Real Problems <http://www.w3.org/TR/html-design-principles/#solve-real-problems>.

I don't think citing the "design principles" is helpful; in particular 
as we never formally agreed about them.

> As pointed out by Philip, such a change would introduce a race condition in the loading of stylesheets, and thus fails to have Well-defined Behavior <http://www.w3.org/TR/html-design-principles/#well-defined-behavior>. The positive effect claimed ("less special-casing") is appealing, but theoretical purity is at the bottom of our Priority of Constituencies <http://www.w3.org/TR/html-design-principles/#priority-of-constituencies>. This race condition is a potential source of confusion for web authors, and thus this CP puts theoretial purity ahead of web authors, inverting our Priority of Constituencies.

As far as I can tell, Philip didn't point out a "race condition".

David Baron:

> The Referer header provides a useful function to authors: it allows finding the resources that refer to another resource when reference is a sign that an update is needed: for example, use of an obsolete style sheet or image (say, the old version of the company logo). This is the sort of feature that the original author may not believe he's going to need, due to overconfidence... but in the future he (due to failed memory of the distant past) or his replacement may need.
>
> Providing ways to opt out of this sort of feature thus defeats its purpose. If those opt-outs don't have a strong use case, they shouldn't be added.

That's an interesting argument; however, not having a feature just 
because an author *might* regret it to have used it later on doesn't 
seem to be a compelling argument. Also, it applies to <a> as well, and 
thus it would be better idea to explain the potential downsides of 
including it in the spec.

Best regards, Julian

Received on Sunday, 27 February 2011 13:09:34 UTC