Use markdown instead of HTML in activities.yml

CONTRIBUTING.md

@@ -147,7 +147,7 @@ python3 activities.py add 1234 --rationale "..."
 
 ...where 1234 is the GitHub issue number. Optionally also add `--description "..."` to add a description of the feature or specification.
 
-Alternatively, edit `activities.yml` directly.
+Alternatively, edit `activities.yml` directly. The `description` and `rationale` fields support a subset of markdown: inline code and links (URL must start with `#` or `https://`).
 
 Then submit a pull request with the changes.
 

activities.yml

@@ -1,12 +1,12 @@
 <link>'s imagesrcset and imagesizes attributes:
   bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1515760
   description: |
-    Adds imagesrcset and imagesizes attributes to &lt;link> which correspond to the srcset and sizes attributes of &lt;img> respectively, for the purposes of preloading.
+    Adds `imagesrcset` and `imagesizes` attributes to `<link>` which correspond to the `srcset` and `sizes` attributes of `<img>` respectively, for the purposes of preloading.
   id: image-preload
   issue: 130
   position: positive
   rationale: |
-    A relevant aspect of &lt;link rel=preload> support.
+    A relevant aspect of `<link rel=preload>` support.
   url: https://html.spec.whatwg.org/multipage/semantics.html#attr-link-imagesrcset
   venues:
   - WHATWG
@@ -163,7 +163,7 @@ Bundled HTTP Exchanges:
 Byte Streams:
   caniuse: https://caniuse.com/streams
   description: |
-    Byte streams are a specialization of <a href="#streams">Streams</a> that are designed to deal with raw bytes.
+    Byte streams are a specialization of [Streams](#streams) that are designed to deal with raw bytes.
   id: byte-streams
   issue: 457
   mdn:
@@ -291,7 +291,7 @@ CSS Painting API:
   bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1302328
   caniuse: https://caniuse.com/css-paint-api
   description: |
-    An API for allowing web developers to define a custom CSS &lt;image> with javascript, which will respond to style and size changes.
+    An API for allowing web developers to define a custom CSS `<image>` with javascript, which will respond to style and size changes.
   id: css-paint-api
   issue: 1089
   mdn: https://developer.mozilla.org/en-US/docs/Web/API/CSS_Painting_API
@@ -493,7 +493,7 @@ Cookie Store API:
   issue: 94
   position: positive
   rationale: |
-    This API provides better access to cookies. We are positive for a subset of this API which only exposes the same information available through document.cookie. At this time we're not ready to expose ServiceWorkerRegistration.cookies or implement the CookieStoreManager as proposed; we will discuss this along with the subset proposal in the appropriate standards group. See <a href="https://github.com/WICG/cookie-store/issues/241">WICG/cookie-store issue #241</a>.
+    This API provides better access to cookies. We are positive for a subset of this API which only exposes the same information available through document.cookie. At this time we're not ready to expose ServiceWorkerRegistration.cookies or implement the CookieStoreManager as proposed; we will discuss this along with the subset proposal in the appropriate standards group. See [WICG/cookie-store issue #241](https://github.com/WICG/cookie-store/issues/241).
   url: https://wicg.github.io/cookie-store/
   venues:
   - Proposal
@@ -541,7 +541,7 @@ Cross-Origin Read Blocking (CORB):
   issue: 81
   position: neutral
   rationale: |
-    While this is an important aspect of a robust Spectre-defense, we would like to see a safelist-based approach pursued, e.g., <a href="https://github.com/annevk/orb">Opaque Response Blocking</a>.
+    While this is an important aspect of a robust Spectre-defense, we would like to see a safelist-based approach pursued, e.g., [Opaque Response Blocking](https://github.com/annevk/orb).
   url:
     https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md
   venues:
@@ -706,7 +706,7 @@ First-Party Sets:
   issue: 350
   position: negative
   rationale: |
-    We believe the definition of first party should be clear and understandable to users, web developers, and publishers, and thus ideally it should be based only on the top-level URL.  While we can't quite do that today because it isn't compatible with all sites, we'd like to move towards doing that, rather than standardizing a mechanism that moves away from that.  See <a href="https://github.com/privacycg/proposals/issues/17#issuecomment-641687052">more details</a>.
+    We believe the definition of first party should be clear and understandable to users, web developers, and publishers, and thus ideally it should be based only on the top-level URL.  While we can't quite do that today because it isn't compatible with all sites, we'd like to move towards doing that, rather than standardizing a mechanism that moves away from that.  See [more details](https://github.com/privacycg/proposals/issues/17#issuecomment-641687052).
   url: https://github.com/WICG/first-party-sets
   venues:
   - Proposal
@@ -729,7 +729,7 @@ Fragmention:
   issue: 234
   position: positive
   rationale: |
-    We feel that some of the use cases this proposal addresses are very important to address, but worry about the lack of a clear processing model and about possible compat constraints that may need implementation experience to fully understand.  More details are in the position issue.  See also the <a href="#scroll-to-text-fragment">position on Scroll to Text Fragment</a>, which aims to address similar use cases.
+    We feel that some of the use cases this proposal addresses are very important to address, but worry about the lack of a clear processing model and about possible compat constraints that may need implementation experience to fully understand.  More details are in the position issue.  See also the [position on Scroll to Text Fragment](#scroll-to-text-fragment), which aims to address similar use cases.
   url: https://indieweb.org/fragmention
   venues:
   - Proposal
@@ -806,7 +806,7 @@ HTML Modules:
 HTML autofocus attribute overhaul:
   bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1574435
   description: |
-    Overhaul the <code>autofocus</code> processing model to better match browser behavior, fit better within the specification ecosystem, and avoid bad results for users.
+    Overhaul the `autofocus` processing model to better match browser behavior, fit better within the specification ecosystem, and avoid bad results for users.
   id: autofocus-overhaul
   issue: 195
   position: positive
@@ -817,7 +817,7 @@ HTMLVideoElement.requestVideoFrameCallback():
   bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1800882
   caniuse: https://caniuse.com/mdn-api_htmlvideoelement_requestvideoframecallback
   description: |
-    &lt;video>.requestVideoFrameCallback() allows web authors to be notified when a frame has been presented for composition.
+    `<video>.requestVideoFrameCallback()` allows web authors to be notified when a frame has been presented for composition.
   id: requestVideoFrameCallback
   issue: 250
   position: positive
@@ -847,7 +847,7 @@ HTTP Client Hints:
   mdn: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Client_hints
   position: neutral
   rationale: |
-    Architecturally, Mozilla prefers client-side solutions for retrieving alternate versions of content, such as the HTML &lt;picture> tag. Despite these architectural preferences, we find that Client-Hints do not present a concrete harm to the web or to its users.
+    Architecturally, Mozilla prefers client-side solutions for retrieving alternate versions of content, such as the HTML `<picture>` tag. Despite these architectural preferences, we find that Client-Hints do not present a concrete harm to the web or to its users.
   url: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-client-hints
   venues:
   - IETF
@@ -858,7 +858,7 @@ Idle Detection API:
   issue: 453
   position: negative
   rationale: |
-    We are concerned about the user-surveillance, user-manipulation, and abuse of user resources potential of this API, despite the required 60 second mitigation. Additionally it seems to be an unnecessarily powerful approach for the motivating use-cases, which themselves are not even clear they are worth solving, as pointed out in <a href="https://lists.webkit.org/pipermail/webkit-dev/2020-October/031562.html">https://lists.webkit.org/pipermail/webkit-dev/2020-October/031562.html</a>
+    We are concerned about the user-surveillance, user-manipulation, and abuse of user resources potential of this API, despite the required 60 second mitigation. Additionally it seems to be an unnecessarily powerful approach for the motivating use-cases, which themselves are not even clear they are worth solving, as pointed out in [this message](https://lists.webkit.org/pipermail/webkit-dev/2020-October/031562.html).
   url: https://wicg.github.io/idle-detection/
   venues:
   - Proposal
@@ -1066,7 +1066,7 @@ Media Feeds:
   issue: 370
   position: negative
   rationale: |
-    Media feeds uses harmful technologies to amplify a harmful feature. Many of the capabilities this enables are available to sites in other ways. For those capabilities that are not, extensions to the <a href="https://w3c.github.io/mediasession/">Media Session API</a> would be preferable.
+    Media feeds uses harmful technologies to amplify a harmful feature. Many of the capabilities this enables are available to sites in other ways. For those capabilities that are not, extensions to the [Media Session API](https://w3c.github.io/mediasession/) would be preferable.
   url: https://wicg.github.io/media-feeds/
   venues:
   - Proposal
@@ -1268,7 +1268,7 @@ Portals:
   issue: 157
   position: defer
   rationale: |
-    While we are deferring evaluation of this proposal, because per <a href="https://github.com/mozilla/standards-positions/issues/157#issuecomment-636217042">Domenic's comment</a> it is in the early stages of development and it is too early to evaluate fully, there are concerns (serious enough to mark it as harmful) that we would like to see addressed as it develops.  Most significantly, it needs to explain its interaction with the Web's storage mechanisms in a way that doesn't contribute to third-party tracking or reduce the effectiveness of proposals designed to mitigate such tracking (such as those that partition storage based on toplevel origins).  It also needs to justify the (still undetermined) amount of complexity that it adds to the web platform with sufficiently valuable use cases to justify that complexity.
+    While we are deferring evaluation of this proposal, because per [Domenic's comment](https://github.com/mozilla/standards-positions/issues/157#issuecomment-636217042) it is in the early stages of development and it is too early to evaluate fully, there are concerns (serious enough to mark it as harmful) that we would like to see addressed as it develops.  Most significantly, it needs to explain its interaction with the Web's storage mechanisms in a way that doesn't contribute to third-party tracking or reduce the effectiveness of proposals designed to mitigate such tracking (such as those that partition storage based on toplevel origins).  It also needs to justify the (still undetermined) amount of complexity that it adds to the web platform with sufficiently valuable use cases to justify that complexity.
   url: https://wicg.github.io/portals/
   venues:
   - Proposal
@@ -1298,7 +1298,7 @@ Priority Hints:
   - Proposal
 Private Access Tokens:
   description: |
-    Private Access Tokens is the name given to the <a href=https://developer.apple.com/news/?id=huqjyh7k>integration</a> of Privacy Pass mechanism into Apple's networking stack.
+    Private Access Tokens is the name given to the [integration](https://developer.apple.com/news/?id=huqjyh7k) of Privacy Pass mechanism into Apple's networking stack.
   id: private-access-tokens
   issue: 954
   position: negative
@@ -1616,7 +1616,7 @@ Text Fragments:
   mdn: https://developer.mozilla.org/en-US/docs/Web/Text_fragments
   position: positive
   rationale: |
-    This is an important use case to address and the proposal does a good job at mitigating the compatibility and security issues. As a result the syntax is a tad inelegant, but workable. (See also the <a href="#fragmention">position on Fragmention</a>, which aims to address similar use cases.)
+    This is an important use case to address and the proposal does a good job at mitigating the compatibility and security issues. As a result the syntax is a tad inelegant, but workable. (See also the [position on Fragmention](#fragmention), which aims to address similar use cases.)
   url: https://wicg.github.io/scroll-to-text-fragment/
   venues:
   - Proposal
@@ -1781,7 +1781,7 @@ Web Bluetooth:
   mdn: https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API
   position: negative
   rationale: |
-    This API provides access to the Generic Attribute Profile (GATT) of Bluetooth, which is not the lowest level of access that the specifications allow, but its generic nature makes it impossible to clearly evaluate. Like <a href="#webusb">WebUSB</a> there is significant uncertainty regarding how well prepared devices are to receive requests from arbitrary sites. The generic nature of the API means that this risk is difficult to manage. The Web Bluetooth CG has opted to only rely on user consent, which we believe is not sufficient protection. This proposal also uses a blocklist, which will require constant and active maintenance so that vulnerable devices aren't exploited. This model is unsustainable and presents a significant risk to users and their devices.
+    This API provides access to the Generic Attribute Profile (GATT) of Bluetooth, which is not the lowest level of access that the specifications allow, but its generic nature makes it impossible to clearly evaluate. Like [WebUSB](#webusb) there is significant uncertainty regarding how well prepared devices are to receive requests from arbitrary sites. The generic nature of the API means that this risk is difficult to manage. The Web Bluetooth CG has opted to only rely on user consent, which we believe is not sufficient protection. This proposal also uses a blocklist, which will require constant and active maintenance so that vulnerable devices aren't exploited. This model is unsustainable and presents a significant risk to users and their devices.
   url: https://webbluetoothcg.github.io/web-bluetooth/
   venues:
   - Proposal
@@ -1949,7 +1949,7 @@ WebHID API:
   mdn: https://developer.mozilla.org/en-US/docs/Web/API/HID
   position: negative
   rationale: |
-    This API, like <a href=#webusb>WebUSB</a>, provides access to generic devices. Though this API is limited to human interface devices (HID), the same concerns apply as WebUSB, namely that devices are generally not designed with access from arbitrary websites in their threat model.
+    This API, like [WebUSB](#webusb), provides access to generic devices. Though this API is limited to human interface devices (HID), the same concerns apply as WebUSB, namely that devices are generally not designed with access from arbitrary websites in their threat model.
   url: https://wicg.github.io/webhid/
   venues:
   - Proposal
@@ -1960,7 +1960,7 @@ WebRTC Encoded Transform:
   issue: 330
   position: positive
   rationale: |
-    This approach provides sites a way to offer a form of end-to-end protection for media, especially in those very common cases where media for group sessions is managed by a central service. The proposed API, together with the SFrame proposal, provides sites the ability to limit the information that is exposed to the central service. Mozilla would prefer to include better key management than this approach proposes, perhaps using <a href="https://datatracker.ietf.org/doc/html/draft-ietf-mls-architecture">MLS</a>, which might guarantee certain security and privacy gains for users. However, we recognize that this is not yet feasible and this API can provide security and privacy gains if carefully applied by sites.
+    This approach provides sites a way to offer a form of end-to-end protection for media, especially in those very common cases where media for group sessions is managed by a central service. The proposed API, together with the SFrame proposal, provides sites the ability to limit the information that is exposed to the central service. Mozilla would prefer to include better key management than this approach proposes, perhaps using [MLS](https://datatracker.ietf.org/doc/html/draft-ietf-mls-architecture), which might guarantee certain security and privacy gains for users. However, we recognize that this is not yet feasible and this API can provide security and privacy gains if carefully applied by sites.
   url: https://w3c.github.io/webrtc-encoded-transform/
   venues:
   - W3C
@@ -2075,9 +2075,9 @@ inert attribute:
   url: https://github.com/whatwg/html/pull/4288
   venues:
   - WHATWG
-output attributes on <input type=file> element:
+output attributes on `<input type=file>` element:
   description: |
-    Proposal to add various output attributes on HTML's &lt;input> elements that would allow developers to declare some conversions the browser could do to, for example, images and videos.
+    Proposal to add various output attributes on HTML's `<input>` elements that would allow developers to declare some conversions the browser could do to, for example, images and videos.
   id: input-file-output-attributes
   issue: 237
   position: neutral
@@ -2095,7 +2095,7 @@ page-orientation descriptor:
   issue: 346
   position: positive
   rationale: |
-    This is a simple addition (to a relatively complex existing feature, <a href="https://drafts.csswg.org/css-page-3/#using-named-pages">named pages</a>) that can improve the experience of producing printed PDF output from web-based word processors or similar systems that largely do their own page layout.
+    This is a simple addition (to a relatively complex existing feature, [named pages](https://drafts.csswg.org/css-page-3/#using-named-pages)) that can improve the experience of producing printed PDF output from web-based word processors or similar systems that largely do their own page layout.
   url: https://drafts.csswg.org/css-page-3/#page-orientation-prop
   venues:
   - W3C