- From: Yoshisato Yanagisawa <notifications@github.com>
- Date: Wed, 02 Apr 2025 22:15:08 -0700
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/issues/1763/2774515316@github.com>
yoshisatoyanagisawa left a comment (w3c/ServiceWorker#1763) My take away is different. I understand it is recommended to explicitly export definitions in W3C specs. Therefore, I thought what @mkruisselbrink concerned in https://github.com/w3c/ServiceWorker/pull/1762#discussion_r2012635371 was that we are adding definitions for W3C specs in the anchor section. Therefore, definitions that cannot be in the autolinking database might be fine to be shown up in the anchor section. (Yeah, we will send PRs to specs to export definitions the ServiceWorker spec uses beforehand to make them stored in the autolinking database) Then, I thought our steps might be: 1. make definitions in W3C specs exported when we use them. At the same time, we remove them from the anchor section. 2. if there is ambiguity for autolinking, use link-defaults to clarify. 3. if definitions cannot be exported, we write them down in the "anchors" block. 4. if it is not definitions, maybe directly link there. (Do we prefer a mark-down style (`[word](https://example.com/)`) to an HTML style (`<a href="https://example.com/">word</a>`) ?) We should be sure that bikeshed won't warn for broken link made by 3. and 4. What do you think? -- Reply to this email directly or view it on GitHub: https://github.com/w3c/ServiceWorker/issues/1763#issuecomment-2774515316 You are receiving this because you are subscribed to this thread. Message ID: <w3c/ServiceWorker/issues/1763/2774515316@github.com>
Received on Thursday, 3 April 2025 05:15:12 UTC