(Re-)investigating potential use of the rel attribute

Hi all,

There will be at least a couple of these emails, where I document what I found whilst looking in to various technical issues for upcoming specs (not symbols—that's pretty-much ready for CR).

With respect to the the @rel attribute, there were a couple of questions:

1. Could we use the existing @rel attribute for this?

2. Are there any existing @rel attribute values that overlap with any of our attributes/values?

3. Bonus section: well-known URL(s).

Here is what I found...


// 1. Can we use @rel for our needs?

In theory, we _could_ use it for _some_ stuff, such as @destination. The @rel attribute is only valid on certain types of elements (linky ones, and forms). I am not sure if it's valid on elements that have been given a @role of "link".

Setting aside the [role="link"] issue, this does seem to closely match our @destination attribute in terms of what it's for: indicating the relationship of a linked document to the present one.

This has the advantage that the semantics of @rel are relatively well known and authors would really see it as something relating to links. Our @destination attribute, by contrast, being newer and not strictly defined in terms of validation, lacks those advantages.


// 2. Are there existing rel attribute values we could use?

There is a core set of de facto accepted @rel values, these are the ones recognise by browsers. There is also an official page on the Microformats wiki that acts as a registry for valid @rel attribute values - the HTML spec links to it [1]. Registering a @rel value doesn't mean browsers will implement it; it only sets out our semantic stall. At first, we would expect our UAs/ATs to be browser extensions, so this sort of arrangement would be fine for prototyping, but it isn't a very formal way of defining values. We could take the approach of prototyping via browser extensions, and then asking to get popular values added to the HTML spec, so they would appear within the spec at the appropriate place [2].

It seems like adopting @rel could be appropriate use of an existing attribute to achieve what we set out to achieve, and there is an existing mechanism to tell the world about values, though it is not as formal a process as that followed by W3C. If we're keen on keeping the semantics of destination distinct from action and purpose, then using @rel would certainly make that clearer.

The TF may feel it's preferable to specify our destination values within our own spec, so we could more directly control versioning. But there is a trade-off in doing that: we'd gain a bit more control over the spec, but (as our spec was written before the recent symbol re-focusing) we would lose control over the elements to which our @destination attribute might be applied by authors (because we aren't being strict on validation), which is something to consider.

[1] https://html.spec.whatwg.org/multipage/links.html#concept-rel-extensions

[2] https://html.spec.whatwg.org/multipage/links.html#linkTypes



// 3. Bonus section: Well-known URLs

As articulated in a previous message, I think there's a great opportunity for us to extend the existing well-known URL spec to include other well-known URLs, and those should probably use the same tokens as our proposed @destination (and maybe some @action?) attributes.

[3] https://lists.w3.org/Archives/Public/public-adapt/2022Oct/0005.html



// Conclusion

It's worth discussing whether we want to benefit from the clear semantics afforded by the @rel attribute. If we don't, we can carry on as we are. If we do, then we should check up about whether elements with a @role of "link" would be included.

Either way, I think we should be working on well-known URLs to mirror whatever we're doing with @rel or @destination.

best regards,


Matthew

[1] https://html.spec.whatwg.org/multipage/links.html#concept-rel-extensions

[2] https://html.spec.whatwg.org/multipage/links.html#linkTypes
[3] https://lists.w3.org/Archives/Public/public-adapt/2022Oct/0005.html

-- 
Matthew Tylee Atkinson (he/him)
--
Principal Accessibility Engineer
TPG Interactive
https://www.tpgi.com

A Vispero Company
https://www.vispero.com

--
This message is intended to be confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, please delete this message from your system and notify us immediately.
Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful.

Received on Wednesday, 2 November 2022 16:26:06 UTC