From fdf79eb90a8028afa13de85ea1ecf2e112b26fd2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marcos=20C=C3=A1ceres?= <marcos@marcosc.com>
Date: Thu, 15 Jan 2026 21:55:25 +1100
Subject: [PATCH 1/3] Revise codec registration entry requirements

Updated registration entry requirements for codec strings and specifications.
---
 codec_registry.src.html | 77 +++++++++++++++++++++++------------------
 1 file changed, 43 insertions(+), 34 deletions(-)

diff --git a/codec_registry.src.html b/codec_registry.src.html
index afb5c1a5..f1848cf4 100644
--- a/codec_registry.src.html
+++ b/codec_registry.src.html
@@ -45,12 +45,26 @@
 Registration Entry Requirements {#registration-entry-requirements}
 ==================================================================
 
-1. Each entry must include a unique <a>codec string</a>, a common name string, and a
-    link to the codec's specification.
-2. The <a>codec string</a> must be crafted as follows:
+To register an entry, file an issue in the
+[WebCodecs GitHub issue tracker](https://github.com/w3c/webcodecs/issues/)
+so it can be discussed and evaluated for compliance before being added to
+the registry. 
+
+The Media Working Group might seek expertise from outside the
+Working Group as part of its evaluation, e.g., from the codec specification
+editors or relevant standards group. If the codec specification is not
+publicly available, it must be made available to the Working Group for
+evaluation. For the entry to be included, there needs
+to be interest from at least one implementer in the Working Group. If the Working Group 
+reaches consensus to accept the candidate entry, send a pull request (either by editors
+or by the part requesting the candidate registration) that meets the following requirements:
+
+1. A unique <a>codec string</a>, a common name string, and a
+    link to the codec's public <dfn>registration specification</dfn>.
+2. The <a>codec string</a> requirements are as follows:
     1. If the <a>codec string</a> contains a fixed prefix with variable suffix values,
         the suffix must be represented by an asterisk and the registration's
-        public specification must describe how to fully qualify the variable
+        public specification needs to describe how to fully qualify the variable
         portion of the string.
     2. Otherwise, if the codec is recognized by multiple strings, a single
         preferred string should be listed and the registration's specification
@@ -58,41 +72,34 @@
     3. Otherwise, the codec is identified by a simple fixed string.
 3. Each registration's specification must include a sequence of sections
     describing:
-    1. Recognized codec strings
-    2. {{EncodedAudioChunk}} or {{EncodedVideoChunk}} internal data
-    3. {{AudioDecoderConfig}} or {{VideoDecoderConfig}} description bytes
+    1. Recognized codec strings.
+    2. {{EncodedAudioChunk}} or {{EncodedVideoChunk}} internal data.
+    3. {{AudioDecoderConfig}} or {{VideoDecoderConfig}} description bytes.
     4. Expectations for {{EncodedAudioChunk}} or {{EncodedVideoChunk}}
-        {{EncodedVideoChunk/[[type]]}}
+        {{EncodedVideoChunk/[[type]]}}.
 4. Where applicable, a registration specification may include a section
     describing extensions to {{VideoEncoderConfig}} or {{AudioEncoderConfig}}
     dictionaries.
-5. Candidate entries must be announced by filing an issue in the
-    [WebCodecs GitHub issue tracker](https://github.com/w3c/webcodecs/issues/)
-    so they can be discussed and evaluated for compliance before being added to
-    the registry. The Media Working Group may seek expertise from outside the
-    Working Group as part of its evaluation, e.g., from the codec specification
-    editors or relevant standards group. If the codec specification is not
-    publicly available, it must be made available to the Working Group for
-    evaluation. If the Working Group reaches consensus to accept the candidate,
-    a pull request should be drafted (either by editors or by the party
-    requesting the candidate registration) to register the candidate.
-    The registry editors will review and merge the pull request.
-6. Existing entries cannot be deleted or deprecated. They may be changed after
-    being published through the same process as candidate entries. Possible
-    changes include expansion of the <a>codec string</a> to better qualify the codec,
-    adjustments to the codec name string, and modification of the link to the
-    codec's specification.
 
+Once consensus is reached by the Working Group, the registry editors will review and merge the pull request.
+
+Existing entries cannot be deleted or deprecated. They may be changed after
+being published through the same process as candidate entries. Possible
+changes include expansion of the <a>codec string</a> to better qualify the codec,
+adjustments to the codec name string, and modification of the link to the
+codec's specification.
 
 Audio Codec Registry {#audio-codec-registry}
 ============================================
 
 <table class='data'>
-  <tr>
-    <td>**codec string**</td>
-    <td>**common name**</td>
-    <td>**public specification**</td>
-  </tr>
+  <thead>
+    <tr>
+      <th>Codec string</th>
+      <th>Common name</th>
+      <th>Registration specification</th>
+    </tr>
+  </thead>
   <tr>
     <td>flac</td>
     <td>Flac</td>
@@ -153,11 +160,13 @@
 ============================================
 
 <table class='data'>
-  <tr>
-    <td>**codec string**</td>
-    <td>**common name**</td>
-    <td>**specification**</td>
-  </tr>
+  <thead>
+    <tr>
+      <th>Codec string</th>
+      <th>Common name</th>
+      <th>Registration specification</th>
+    </tr>
+  </thead>
   <tr>
     <td>av01.\*</td>
     <td>AV1</td>

From a882e6e617048949d801871a4cdba1e09dd46c07 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marcos=20C=C3=A1ceres?= <marcos@marcosc.com>
Date: Thu, 15 Jan 2026 21:58:00 +1100
Subject: [PATCH 2/3] Apply suggestion from @Copilot

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
---
 codec_registry.src.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/codec_registry.src.html b/codec_registry.src.html
index f1848cf4..f684a62e 100644
--- a/codec_registry.src.html
+++ b/codec_registry.src.html
@@ -57,7 +57,7 @@
 evaluation. For the entry to be included, there needs
 to be interest from at least one implementer in the Working Group. If the Working Group 
 reaches consensus to accept the candidate entry, send a pull request (either by editors
-or by the part requesting the candidate registration) that meets the following requirements:
+or by the party requesting the candidate registration) that meets the following requirements:
 
 1. A unique <a>codec string</a>, a common name string, and a
     link to the codec's public <dfn>registration specification</dfn>.

From de230505f6b8706eca1217b63cb2f4d1c35d0f12 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marcos=20C=C3=A1ceres?= <marcos@marcosc.com>
Date: Thu, 15 Jan 2026 21:58:45 +1100
Subject: [PATCH 3/3] Apply suggestion from @marcoscaceres

---
 codec_registry.src.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/codec_registry.src.html b/codec_registry.src.html
index f684a62e..789664a8 100644
--- a/codec_registry.src.html
+++ b/codec_registry.src.html
@@ -64,7 +64,7 @@
 2. The <a>codec string</a> requirements are as follows:
     1. If the <a>codec string</a> contains a fixed prefix with variable suffix values,
         the suffix must be represented by an asterisk and the registration's
-        public specification needs to describe how to fully qualify the variable
+        public specification must describe how to fully qualify the variable
         portion of the string.
     2. Otherwise, if the codec is recognized by multiple strings, a single
         preferred string should be listed and the registration's specification