Fix problems with table rendering (#1145)

* Fix problems with table rendering

* update markdown-to-jsx dependency to 7.7.3

* Remove unnecessary linebreaks for the code editor to work properly

Author: benjagm

package.json

@@ -38,7 +38,7 @@
     "js-yaml": "^4.1.0",
     "jsonpath": "^1.1.1",
     "jszip": "^3.10.1",
-    "markdown-to-jsx": "^7.6.2",
+    "markdown-to-jsx": "^7.7.3",
     "moment": "2.30.1",
     "next": "14.2.14",
     "next-sitemap": "^4.2.3",

pages/draft-06/json-hyper-schema-release-notes.md

@@ -31,8 +31,8 @@ While we knew that there were still major gaps in draft-06, we felt that it was
 
 #### Changes from draft-04 to draft-05
 
-keyword | change | consequence
----- | ---- | ----
+| keyword | change | consequence
+| ---- | ---- | ----
 `"base"` | replaces looking up the nearest "self" link to determine the base URI for `"href"` | if you were relying on "self" links to change the base, set `"base"` explicitly
 `"rel"` | "full" relation removed | use ["item"](https://github.com/json-schema-org/json-schema-spec/issues/295)
 `"rel"` | "instances" and "create" relations removed | use ["collection"](https://github.com/json-schema-org/json-schema-spec/issues/295)
@@ -43,8 +43,8 @@ keyword | change | consequence
 
 #### Changes from draft-05 to draft-06
 
-keyword | change | consequence
----- | ---- | ----
+| keyword | change | consequence
+| ---- | ---- | ----
 `"method"` | *removed* | for HTTP method proposals, see issues [#73](https://github.com/json-schema-org/json-schema-spec/issues/73) and [#296](https://github.com/json-schema-org/json-schema-spec/issues/296) (use either `"method"` or `"allow"` as an extension keyword if needed); indication of how to use `"schema"` and `"encType"` no longer necessary
 `"schema"` | *removed* | use `"hrefSchema"`, `"submissionSchema"`,  or `"targetSchema"` |
 `"encType"` | *removed* | use `"submissionEncType"` for request bodies; no longer needed for URI query strings

pages/draft-06/json-schema-release-notes.md

@@ -21,8 +21,8 @@ For more information, see that draft's [migration notes](../../draft-07/json-sch
 
 #### Backwards-incompatible changes
 
-keyword | change | consequence
----- | ---- | ----
+| keyword | change | consequence
+| ---- | ---- | ----
 `"id"` | replaced by `"$id"` | no longer easily confused with instance properties named `"id"`
 `"$id"` | replaces `"id"` | behavior is identical, `$` prefix matches the other two core keywords
 `"$ref"` | only allowed where a schema is expected | it is now possible to describe instance properties named `"$ref"`
@@ -31,8 +31,8 @@ keyword | change | consequence
 
 #### Additions and backwards-compatible changes
 
-keyword | change | consequence
----- | ---- | ----
+| keyword | change | consequence
+| ---- | ---- | ----
 booleans as schemas | allowable anywhere, not just `"additionalProperties"` and `"additionalItems"` | `true` is equivalent to `{}`, `false` is equivalent to `{"not": {}}`, but the intent is more clear and implementations can optimize these cases more easily
 `"propertyNames"` | added | takes a schema which validates the *names* of all properties rather than their values
 `"contains"` | added | array keyword that passes validation if its schema validates at least one array item

pages/draft-07/json-schema-release-notes.md

@@ -26,8 +26,8 @@ more clearly than before.
 * No keywords were removed
 * Some keywords were moved from Hyper-Schema, and two of those were renamed
 
-keyword | change | notes
----- | ---- | ----
+| keyword | change | notes
+| ---- | ---- | ----
 [`"$comment"`](../../draft-07/json-schema-core.html#rfc.section.9) | added to Core | Intended for notes to schema maintainers, as opposed to [`"description"`](../../draft-07/json-schema-validation.html#rfc.section.10.1) which is suitable for display to end users
 [`"if"`, `"then"`, `"else"`](../../draft-07/json-schema-validation.html#rfc.section.6.6) | added to Validation | explicit conditional schema evaluation 
 [`"readOnly"`](../../draft-07/json-schema-validation.html#rfc.section.10.3) | moved from Hyper-Schema to Validation | not limited to hypermedia environments
@@ -41,8 +41,8 @@ Note that the `"content*"` keywords do not _require_ validation.
 
 Numerous formats were added, clarified, or restored from older drafts.
 
-format | change | notes
----- | ---- | ----
+| format | change | notes
+| ---- | ---- | ----
 [`"iri"`](../../draft-07/json-schema-validation.html#rfc.section.7.3.5) | added | I18N equivalent of `"uri"`
 [`"iri-reference"`](../../draft-07/json-schema-validation.html#rfc.section.7.3.5) | added | I18N equivalent of `"uri-reference"`
 [`"uri-template"`](../../draft-07/json-schema-validation.html#rfc.section.7.3.6) | noted IRI support | There is no separate IRI Template standard
@@ -102,8 +102,8 @@ that its use for JSON Schema was not correct.  The new guidance for
 [what relations to use](../../draft-07/json-schema-core.html#rfc.section.11.1)
 to link instances to schemas is:
 
-link relation | change | notes
----- | ---- | ----
+| link relation | change | notes
+| ---- | ---- | ----
 "describedBy" | no change | network-accessible URL
 "profile" | removed; use "schema" | opaque identifying URI
 "schema" | added | opaque identifying URI

pages/draft/2019-09/release-notes.md

@@ -55,8 +55,8 @@ All keywords have now been organized into [vocabularies](../../draft/2019-09/jso
 
 [Core Specification, Section 8](../../draft/2019-09/json-schema-core.html#rfc.section.8)
 
-keyword | change | notes
----- | ---- | ----
+| keyword | change | notes
+| ---- | ---- | ----
 [`$anchor`](../../draft/2019-09/json-schema-core.html#rfc.section.8.2.3) | **new** | Replaces the `#plain-name` form of `$id`, with a different syntax and approach
 [`$defs` (renamed from `definitions`)](../../draft/2019-09/json-schema-core.html#rfc.section.8.2.5) | **renamed** | Note that the standard meta-schema still reserves `definitions` for backwards compatibility
 [`$id`](../../draft/2019-09/json-schema-core.html#rfc.section.8.2.2) | **changed** | Only URI-references without fragments are allowed; see `$anchor` for a replacement for plain-name fragments; all other fragments in `$id` had undefined behavior previously
@@ -70,8 +70,8 @@ keyword | change | notes
 
 These keywords were formerly found in the Validation Specification.
 
-keyword | change | notes
----- | ---- | ----
+| keyword | change | notes
+| ---- | ---- | ----
 [`dependentSchemas` (split from `dependencies`)](../../draft/2019-09/json-schema-core.html#rfc.section.9.2.2.4) | **split** | This is the schema form of `dependencies`; note that the standard meta-schema still reserves `dependencies` for backwards compatibility
 [`unevaluatedItems`](../../draft/2019-09/json-schema-core.html#rfc.section.9.3.1.3) | **new** | Similar to `additionalItems`, but can "see" into subschemas and across references
 [`unevaluatedProperties`](../../draft/2019-09/json-schema-core.html#rfc.section.9.3.2.4) | **new** | Similar to `additionalProperties`, but can "see" into subschemas and across references
@@ -82,8 +82,8 @@ The other applicator vocabulary keywords are `items`, `additionalItems`, `proper
 
 [Validation Specification, Section 6](../../draft/2019-09/json-schema-validation.html#rfc.section.6)
 
-keyword | change | notes
----- | ---- | ----
+| keyword | change | notes
+| ---- | ---- | ----
 [`dependentRequired` (split from `dependencies`)](../../draft/2019-09/json-schema-validation.html#rfc.section.6.5.4) | **split** | This is the string array form of `dependencies`; note that the standard meta-schema still reserves `dependencies` for backwards compatibility
 [`maxContains` and `minContains`](../../draft/2019-09/json-schema-validation.html#rfc.section.6.4.4) | **new** | Assertion for controlling how many times a subschema must be matched within an array
 
@@ -102,11 +102,11 @@ In the following charts, the "supported" column refers to whether and (for `2019
 
 **Summary of draft-07 behavior**
 
-supported   | configuration | outcome 
------------ | ------------- | -------------
-no          | n/a           | not validated
-yes         | _default_ (on)| inconsistently validated
-yes         | off           | not validated
+| supported   | configuration | outcome 
+| ----------- | ------------- | -------------
+| no          | n/a           | not validated
+| yes         | _default_ (on)| inconsistently validated
+| yes         | off           | not validated
 
 Obviously, each implementation will behave consistently from schema to schema, although some formats may be supported more thoroughly than others despite the wording in the specification.  However, complex formats are, in practice, supported to different degrees in each implementation.  If they are supported at all.
 
@@ -120,28 +120,28 @@ The goal with this draft is to make the default behavior predictable, with the i
 
 * An outcome of _vocabulary error_ means that the implementation will refuse to process the schema as it cannot satisfy the vocabulary requirement.
 
-supported   | configuration  | vocabulary    | outcome 
------------ | -------------- | ------------- | -------------
-no          | n/a            | false         | not validated
-no          | n/a            | true          | _vocabulary error_
-best effort | _default_ (off)| false         | not validated
-best effort | _default_ (off)| true          | _vocabulary error_
-best effort | on             | false         | best effort validation
-best effort | on             | true          | _vocabulary error_
-full syntax | _default_ (off)| false         | not validated
-full syntax | _default_ (off)| true          | full syntax validation
-full syntax | on             | false         | full syntax validation
-full syntax | on             | true          | full syntax validation
+| supported   | configuration  | vocabulary    | outcome 
+| ----------- | -------------- | ------------- | -------------
+| no          | n/a            | false         | not validated
+| no          | n/a            | true          | _vocabulary error_
+| best effort | _default_ (off)| false         | not validated
+| best effort | _default_ (off)| true          | _vocabulary error_
+| best effort | on             | false         | best effort validation
+| best effort | on             | true          | _vocabulary error_
+| full syntax | _default_ (off)| false         | not validated
+| full syntax | _default_ (off)| true          | full syntax validation
+| full syntax | on             | false         | full syntax validation
+| full syntax | on             | true          | full syntax validation
 
 Note that, given that almost no draft-07 or earlier implementations have offered strict and complete validation of every single format, it seems unlikely that any implementations will support option 3 option in practice.  
 
 Additionally, two new formats were added, and a specification reference was updated:
 
-format | change | notes
----- | ---- | ----
-[`"duration"`](../../draft/2019-09/json-schema-validation.html#rfc.section.7.3.1) | **added** | The duration format is from the ISO 8601 ABNF as given in Appendix A of RFC 3339
-[`"hostname"` and `"idn-hostname"`](../../draft/2019-09/json-schema-validation.html#rfc.section.7.3.3) | **updated** | Use RFC 1123 instead of RFC 1034; this allows for a leading digit
-[`"uuid"`](../../draft/2019-09/json-schema-validation.html#rfc.section.7.3.5) | **added** | A string instance is valid against this attribute if it is a valid string representation of a UUID, according to RFC4122
+|format | change | notes
+| ---- | ---- | ----
+| [`"duration"`](../../draft/2019-09/json-schema-validation.html#rfc.section.7.3.1) | **added** | The duration format is from the ISO 8601 ABNF as given in Appendix A of RFC 3339
+| [`"hostname"` and `"idn-hostname"`](../../draft/2019-09/json-schema-validation.html#rfc.section.7.3.3) | **updated** | Use RFC 1123 instead of RFC 1034; this allows for a leading digit
+| [`"uuid"`](../../draft/2019-09/json-schema-validation.html#rfc.section.7.3.5) | **added** | A string instance is valid against this attribute if it is a valid string representation of a UUID, according to RFC4122
 
 
 #### Content Vocabulary
@@ -150,23 +150,23 @@ format | change | notes
 
 These keywords are now specified purely as annotations, and never assertions.  Some guidance is provided around how an implementation can optionally offer further automatic processing of this information outside of the validation process.
 
-keyword | change | notes
----- | ---- | ----
-[`contentEncoding`](../../draft/2019-09/json-schema-validation.html#rfc.section.8.3) | **updated** | Encodings from RFC 4648 are now allowed, and take precedence over RFC 2045 when there is a difference
-[`contentSchema`](../../draft/2019-09/json-schema-validation.html#rfc.section.8.5) | **added** | Schema for use with the decoded content string; note that it is _not_ automatically applied as not all content media types can be understood in advance
+| keyword | change | notes
+| ---- | ---- | ----
+| [`contentEncoding`](../../draft/2019-09/json-schema-validation.html#rfc.section.8.3) | **updated** | Encodings from RFC 4648 are now allowed, and take precedence over RFC 2045 when there is a difference
+| [`contentSchema`](../../draft/2019-09/json-schema-validation.html#rfc.section.8.5) | **added** | Schema for use with the decoded content string; note that it is _not_ automatically applied as not all content media types can be understood in advance
 
 #### Meta-Data Vocabulary
 
 [Validation Specification, Section 9](../../draft/2019-09/json-schema-validation.html#rfc.section.9)
 
-keyword | change | notes
----- | ---- | ----
-[`deprecated`](../../draft/2019-09/json-schema-validation.html#rfc.section.9.3) | **added** | Used to indicate that a field is deprecated in some application-specific manner
+| keyword | change | notes
+| ---- | ---- | ----
+| [`deprecated`](../../draft/2019-09/json-schema-validation.html#rfc.section.9.3) | **added** | Used to indicate that a field is deprecated in some application-specific manner
 
 #### Hyper-Schema Vocabulary
 
 [Hyper-Schema Specification, Sections 5 and 6](../../draft/2019-09/json-schema-hypermedia.html#rfc.section.5)
 
-keyword | change | notes
----- | ---- | ----
-[`rel`](../../draft/2019-09/json-schema-hypermedia.html#rfc.section.6.2.1) | **changed** | Can now be an array of values instead of just a string
+| keyword | change | notes
+| ---- | ---- | ----
+| [`rel`](../../draft/2019-09/json-schema-hypermedia.html#rfc.section.6.2.1) | **changed** | Can now be an array of values instead of just a string

pages/draft/2020-12/release-notes.md

@@ -162,7 +162,6 @@ Here's how you would covert a schema using `$recursiveRef` to use `$dynamicRef`.
   </tr>
   <tr>
     <td>
-
 ```jsonc
 // tree schema, extensible
 {
@@ -189,7 +188,6 @@ Here's how you would covert a schema using `$recursiveRef` to use `$dynamicRef`.
 ```
   </td>
     <td>
-
 ```jsonc
 // tree schema, extensible
 {

yarn.lock

@@ -8342,7 +8342,7 @@ __metadata:
     js-yaml: "npm:^4.1.0"
     jsonpath: "npm:^1.1.1"
     jszip: "npm:^3.10.1"
-    markdown-to-jsx: "npm:^7.6.2"
+    markdown-to-jsx: "npm:^7.7.3"
     moment: "npm:2.30.1"
     next: "npm:14.2.14"
     next-sitemap: "npm:^4.2.3"
@@ -8763,12 +8763,12 @@ __metadata:
   languageName: node
   linkType: hard
 
-"markdown-to-jsx@npm:^7.6.2":
-  version: 7.6.2
-  resolution: "markdown-to-jsx@npm:7.6.2"
+"markdown-to-jsx@npm:^7.7.3":
+  version: 7.7.3
+  resolution: "markdown-to-jsx@npm:7.7.3"
   peerDependencies:
     react: ">= 0.14.0"
-  checksum: 10c0/e4c63c45d860a7fc0b07531bd058e9806ab61dba22c629ef7fc94dda438b35ea351284ea20850726fb5ef8cdfceb0aabbfa05696375d94d0c996cb691706c912
+  checksum: 10c0/85b1c91a8d3ae03cfe828c6b76309702a913e681dad5a7e3a5324ec97153d89313be00a0ee423ab1c0bd61781ed181d76d4a54840d715b67756734da24211cf5
   languageName: node
   linkType: hard