link rel=prev not documented as valid token when used with the link element

[schalkneethling]

While the next token is documented to be a valid token[https://html.spec.whatwg.org/#attr-link-rel] when used as the value of the rel attribute on link, prev is not.

The prev token is documented here though https://html.spec.whatwg.org/#link-type-prev. Was this an oversight or has prev been deprecated?

[sideshowbarker]

It’s an oversight.

IMHO maybe the best fix for this would be to drop the entire sentence at https://html.spec.whatwg.org/#the-link-element:concept-supported-tokens-2, as well as the sentence which immediately follows it.

The reason is, the first sentence in that paragraph already fully states the relevant normative requirements; that is, this sentence:

rel's supported tokens are the keywords defined in HTML link types which are allowed on link elements, impact the processing model, and are supported by the user agent.

The two sentences which follow in that paragraph are simply restating the requirements already given in that first sentence.

So I think maybe the best fix would be to do this:

diff --git a/source b/source
index d76ca234..507bc391 100644
--- a/source
+++ b/source
@@ -13057,23 +13057,7 @@ <h4 data-dfn-type="element" data-lt="link">The <dfn><code>link</code></dfn> elem
   <p><code data-x="attr-link-rel">rel</code>'s
   <span data-x="concept-supported-tokens">supported tokens</span> are the keywords defined in
   <a href="#linkTypes">HTML link types</a> which are allowed on <code>link</code> elements, impact
-  the processing model, and are supported by the user agent. The possible <span
-  data-x="concept-supported-tokens">supported tokens</span> are
-  <code data-x="rel-alternate">alternate</code>,
-  <code data-x="rel-dns-prefetch">dns-prefetch</code>,
-  <code data-x="rel-icon">icon</code>,
-  <code data-x="rel-modulepreload">modulepreload</code>,
-  <code data-x="rel-next">next</code>,
-  <code data-x="rel-pingback">pingback</code>,
-  <code data-x="rel-preconnect">preconnect</code>,
-  <code data-x="rel-prefetch">prefetch</code>,
-  <code data-x="rel-preload">preload</code>,
-  <code data-x="rel-prerender">prerender</code>,
-  <code data-x="rel-search">search</code>, and
-  <code data-x="rel-stylesheet">stylesheet</code>.
-  <code data-x="attr-link-rel">rel</code>'s <span data-x="concept-supported-tokens">supported
-  tokens</span> must only include the tokens from this list that the user agent implements the
-  processing model for.</p>
+  the processing model, and are supported by the user agent.</p>

   <p class="note">Theoretically a user agent could support the processing model for the <code
   data-x="rel-canonical">canonical</code> keyword — if it were a search engine that executed

[schalkneethling]

@sideshowbarker Thank you for the feedback. This makes total sense to me. These oversights happen so easily and so quickly when one try to maintain essentially the same information in two places.

I am happy to make this change.

[domenic]

I'm not sure I agree with @sideshowbarker's assessment. In particular, the intent of explicitly listing those was to explain which types impact the processing model.

Note that next does have a potential impact on the processing model, per https://html.spec.whatwg.org/multipage/links.html#link-type-next :

When the next keyword is used with a link element, user agents should implement one of the processing models described in Resource Hints, i.e. should process such links as if they were using one of the dns-prefetch, preconnect, prefetch, or prerender keywords. Which resource hint the user agent wishes to use is implementation-dependent; for example, a user agent may wish to use the less-costly preconnect hint when trying to conserve data, battery power, or processing power, or may wish to pick a resource hint depending on heuristic analysis of past user behavior in similar scenarios.

Whereas prev has no such processing model.

So I think in fact the confusion in this thread exhibits why the explicit list is helpful; otherwise someone might think that prev should be treated the same as next, whereas in fact they should not be.

[sideshowbarker]

I'm not sure I agree with @sideshowbarker's assessment. In particular, the intent of explicitly listing those was to explain which types impact the processing model.

I wonder if that could maybe be better and more clearly achieved by adding explicit “This link type impacts the processing model” and “This link type does not impact the processing model” to the actual descriptions of each link type in the "Link types” section of the spec.

So I think in fact the confusion in this thread exhibits why the explicit list is helpful;

I think maybe the confusion in this thread arises from the spec as currently written being the cause of the confusion, not the alleviation for the confusion.

otherwise someone might think that prev should be treated the same as next, whereas in fact they should not be

I would think that adding explicit “This link type impacts the processing model” and “This link type does not impact the processing model” statements to each description of each link type in the “Link types” section could make that much more clear.

[domenic]

I suppose we could add something explicitly, but I think the spec is already pretty clear in giving processing models or not? E.g. prev does not have one, but next does? Adding explicit sentences saying "The following paragraph is a processing model" doesn't seem like it'd be that helpful...

[sideshowbarker]

I dunno what would be best here. Your explanation in #5591 (comment) made me remember that I already knew this. I vaguely recall us having a related discussion about this at some time when either I was adding a new link type myself, or I was reviewing an addition that somebody else had made. In spite of having already known it previously, I forgot it until it came up again in this discussion now. So I guess it’s hard for me to agree that I think it’s clear

Certainly I don’t think it’s likely to be clear to a normal web developer reading the spec — at least not as clear as it could be.

[annevk]

Perhaps "processing model" could be a dfn that's null by default and then some types set it to something?

And then the requirement for supports() is that it a) has a non-null processing model and b) that processing model is supported by the user agent.

[brennanyoung]

Perhaps I am misunderstanding something.

Why would prev never affect the processing? Maybe that resource has not been visited yet.

e.g. If you enter the site for the first time on page 5 and from there's a prev link to page 4, you might very well want the page 4 resource to be prefetched.

Is there an assumption here that all browsing is done in page-order? I would challenge that.

[domenic]

"processing model" means "things the browser does", not "things the user does". The browser does nothing in reaction to rel="prev" or rel="next" or rel="invalid-value", so none of them have processing models.

[brennanyoung]

Isn't the point that rel="next" cues the browser to prepare the resource (according to various heuristics like network speed or battery life), since it is likely to be needed 'soon'?

And the same may be true of "prev", for those who browse 'backwards' no?

[domenic]

The same is not true for prev.

[brennanyoung]

Why would we not want the browser to prepare the 'adjacent' resource in both directions? Why only 'forwards'?