Update well-known destinations explainer in accordance with TPAC 2024 #279
Conversation
| <head> | ||
| . . . | ||
| <link rel="accessibility-statement" href="/accessibility-statement"> | ||
| <link rel="help" href="/support"> |
There was a problem hiding this comment.
The User Agent will show image and title for navigation. Will it coming from title and icon attributes? Will title be in user locale?
If yes, can we enhance explainer to capture these?
There was a problem hiding this comment.
My understanding is that the UA won't render <link>s in the <head>—are there times when these will be surfaced to users?
|
|
||
| The UA will know if this link points to the root of the well-known destination (e.g. the "Help" landing page, vs "Help on logging in") becuase it knows the URL of the root of the well-known destination, via the discovery process above. | ||
| ```html | ||
| <p>For more details, consult the <a href="/help/signing-in" rel="help">help section on signing in to your account</a>.</p> |
There was a problem hiding this comment.
- Will UA parse all the anchor tags ?
- If yes, how will it know that is anchor is relevant for Well-known-destination?
- Does this also mean that UA will show union of result from anchor and link tags?
|
|
||
| * A single Well-known URI from which the linkset would be served; and | ||
| ## Previous iteration: Linksets |
There was a problem hiding this comment.
This section doesn't capture, why we are not using this approach?
There was a problem hiding this comment.
Agree; this needs to be documented in the 'alternatives considered' section.
I have some ideas about how to move it there; will try them out in a future commit shortly.
|
|
||
| We first explored using [Well-known URIs](https://datatracker.ietf.org/doc/html/rfc8615), which provide a number of useful features. However, there were some important limitations: | ||
|
|
||
| * Well-known URIs are linked to an _origin_ which means it's not possible to demarcate sub-sites. |
There was a problem hiding this comment.
We can have different well-known URLs for sub-sites. I think the issue is with sub-pages.
There was a problem hiding this comment.
I think we are in agreement, but I'm using the following (possibly wrong) definitions:
- site: a collection of web pages, hosted at a domain or sub-domain.
- sub-site: part of the collection of pages found in a site (i.e. hosted on the same domain or sub-domain. The different with a sub-site is only noticeable by the content of the pages.
- sub-page: I'm not sure what this would be, but I would imagine it could be some content on a specific page (like the content of a tab panel pane, for example).
Does that make sense?
I am not sure if I'm using definitions that would be considered standard. We should first of all check with you, and also check for consistency with other W3C specs, like WCAG, etc.
| @@ -388,6 +392,9 @@ It does not seem like a good fit to try to extend the format of sitemaps to acco | |||
|
|
|||
| ### Using `rel` attribute values alone | |||
|
|
|||
| > [!WARNING] | |||
There was a problem hiding this comment.
This section looks confusing. We can discuss and possibly re-phrase it.
There was a problem hiding this comment.
Yes, you're right, it ties back to your questions about parsing, above (to which I need to come back). For now I will try to shorten it and leave it as a placeholder, but we need to discuss it—a discussion thread may be good for that.
Preview: https://github.com/w3c/adapt/blob/explainers-post-tpac-2024/explainers/well-known-destinations.md