Re: [w3c/ServiceWorker] Editorial: Fix broken links/fragments (PR #1760)

@yoshisatoyanagisawa commented on this pull request.

Thanks for the fixes.

> @@ -88,7 +88,7 @@ spec: ecma-262; urlPrefix: http://tc39.github.io/ecma262/
             text: statement
             text: declaration
 
-spec: page-visibility; urlPrefix: https://www.w3.org/TR/page-visibility/
+spec: page-visibility; urlPrefix: https://html.spec.whatwg.org/multipage/interaction.html#page-visibility
     type: enum; text: VisibilityState; url: VisibilityState

I guess the link broken?
Since we set urlPrefix to "https://html.spec.whatwg.org/multipage/interaction.html#page-visibility", the generated URL might be "https://html.spec.whatwg.org/multipage/interaction.html#page-visibilityVisibilityState", which might not exist.

> @@ -161,9 +161,9 @@ spec: storage; urlPrefix: https://storage.spec.whatwg.org/
 
   Web developers familiar with previous attempts to solve the offline problem have reported a deficit of flexibility in those solutions. As a result, the [=/service worker=] is highly procedural, providing a maximum of flexibility at the price of additional complexity for developers. Part of this complexity arises from the need to keep [=/service workers=] responsive in the face of a single-threaded execution model. As a result, APIs exposed by [=/service workers=] are almost entirely asynchronous, a pattern familiar in other JavaScript contexts but accentuated here by the need to avoid blocking document and resource loading.
 
-  Developers using the <a href="https://developer.mozilla.org/docs/Web/API/Window/applicationCache">HTML5 Application Cache</a> have also <a href="http://alistapart.com/article/application-cache-is-a-douchebag">reported that several attributes</a> of the design contribute to <a href="http://alistapart.com/article/application-cache-is-a-douchebag#section6">unrecoverable errors</a>. A key design principle of the [=/service worker=] is that errors should *always* be recoverable. Many details of the update process of [=/service workers=] are designed to avoid these hazards.

Here, "#section6" after "http://alistapart.com/article/application-cache-is-a-douchebag" has been removed.  Is it intentional?

>  
-  [=/Service workers=] are started and kept alive by their relationship to events, not documents. This design borrows heavily from developer and vendor experience with [[HTML#shared-workers-and-the-sharedworker-interface|shared workers]] and <a href="https://developer.chrome.com/extensions/background_pages">Chrome Background Pages</a>. A key lesson from these systems is the necessity to time-limit the execution of background processing contexts, both to conserve resources and to ensure that background context loss and restart is top-of-mind for developers. As a result, [=/service workers=] bear more than a passing resemblance to <a href="https://developer.chrome.com/extensions/event_pages">Chrome Event Pages</a>, the successor to Background Pages. [=/Service workers=] may be started by user agents *without an attached document* and may be killed by the user agent at nearly any time. Conceptually, [=/service workers=] can be thought of as Shared Workers that can start, process events, and die without ever handling messages from documents. Developers are advised to keep in mind that [=/service workers=] may be started and killed many times a second.
+  [=/Service workers=] are started and kept alive by their relationship to events, not documents. This design borrows heavily from developer and vendor experience with [[HTML#shared-workers-and-the-sharedworker-interface|shared workers]] and <a href="https://developer.chrome.com/docs/extensions/mv2/background-pages">Chrome Background Pages</a>. A key lesson from these systems is the necessity to time-limit the execution of background processing contexts, both to conserve resources and to ensure that background context loss and restart is top-of-mind for developers. As a result, [=/service workers=] bear more than a passing resemblance to <a href="https://developer.chrome.com/docs/extensions/mv2/background-pages">Chrome Event Pages</a>, the successor to Background Pages. [=/Service workers=] may be started by user agents *without an attached document* and may be killed by the user agent at nearly any time. Conceptually, [=/service workers=] can be thought of as Shared Workers that can start, process events, and die without ever handling messages from documents. Developers are advised to keep in mind that [=/service workers=] may be started and killed many times a second.

I assume the correct link to the event page is https://developer.chrome.com/docs/apps/event_pages.  Since the Chrome Extension manifest version 2 has been deprecated, I understand both of them are grave-marks.

> @@ -88,7 +88,7 @@ spec: ecma-262; urlPrefix: http://tc39.github.io/ecma262/
             text: statement
             text: declaration
 
-spec: page-visibility; urlPrefix: https://www.w3.org/TR/page-visibility/
+spec: page-visibility; urlPrefix: https://html.spec.whatwg.org/multipage/interaction.html#page-visibility
     type: enum; text: VisibilityState; url: VisibilityState

Also, you can merge this with L95, which starts with "spec: html; urlPrefix: https://html.spec.whatwg.org/multipage/"

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1760#pullrequestreview-2696696662
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1760/review/2696696662@github.com>