removed <span> elements for concepts, guides and api reference

content/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection.mdx

@@ -388,8 +388,8 @@ Prisma's data model is a declarative representation of your database schema and
 
 Right now, there's a few minor "issues" with the data model:
 
-- The `User` relation field is uppercased and therefore doesn't adhere to Prisma's [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions-1) <span class="api"></span>. To express more "semantics", it would also be nice if this field was called `author` to _describe_ the relationship between `User` and `Post` better.
-- The `Post` and `Profile` relation fields on `User` as well as the `User` relation field on `Profile` are all uppercased. To adhere to Prisma's [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions-1) <span class="api"></span>, both fields should be lowercased to `post`, `profile` and `user`.
+- The `User` relation field is uppercased and therefore doesn't adhere to Prisma's [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions-1) . To express more "semantics", it would also be nice if this field was called `author` to _describe_ the relationship between `User` and `Post` better.
+- The `Post` and `Profile` relation fields on `User` as well as the `User` relation field on `Profile` are all uppercased. To adhere to Prisma's [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions-1) , both fields should be lowercased to `post`, `profile` and `user`.
 - Even after lowercasing, the `post` field on `User` is still slightly misnamed. That's because it actually refers to a [list](/concepts/components/prisma-schema/data-model#type-modifiers) of posts – a better name therefore would be the plural form: `posts`.
 
 These changes are relevant for the generated Prisma Client API where using lowercased relation fields `author`, `posts`, `profile` and `user` will feel more natural and idiomatic to JavaScript/TypeScript developers. You can therefore [configure your Prisma Client API](/concepts/components/prisma-client/working-with-prismaclient/use-custom-model-and-field-names).
@@ -423,7 +423,7 @@ model User {
 }
 ```
 
-In this example, the database schema did follow the [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions) <span class="api"></span> for Prisma models (only the virtual relation fields that were generated from introspection did not adhere to them and needed adjustment). This optimizes the ergonomics of the generated Prisma Client API.
+In this example, the database schema did follow the [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions)  for Prisma models (only the virtual relation fields that were generated from introspection did not adhere to them and needed adjustment). This optimizes the ergonomics of the generated Prisma Client API.
 
 <details>
 <summary> Using custom model and field names </summary>
@@ -529,16 +529,16 @@ model User {
 
 <Admonition>
 
-Refer to the [Prisma schema reference](/reference/api-reference/prisma-schema-reference) <span class="api"></span> for detailed information about the schema definition.
+Refer to the [Prisma schema reference](/reference/api-reference/prisma-schema-reference)  for detailed information about the schema definition.
 
 </Admonition>
 
 Prisma's data model is a declarative representation of your database schema and serves as the foundation for the generated Prisma Client library. Your Prisma Client instance will expose queries that are _tailored_ to these models.
 
 Right now, there's a few minor "issues" with the data model:
 
-- The `User` relation field is uppercased and therefore doesn't adhere to Prisma's [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions-1) <span class="api"></span>. To express more "semantics", it would also be nice if this field was called `author` to _describe_ the relationship between `User` and `Post` better.
-- The `Post` and `Profile` relation fields on `User` as well as the `User` relation field on `Profile` are all uppercased. To adhere to Prisma's [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions-1) <span class="api"></span>, both fields should be lowercased to `post`, `profile` and `user`.
+- The `User` relation field is uppercased and therefore doesn't adhere to Prisma's [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions-1) . To express more "semantics", it would also be nice if this field was called `author` to _describe_ the relationship between `User` and `Post` better.
+- The `Post` and `Profile` relation fields on `User` as well as the `User` relation field on `Profile` are all uppercased. To adhere to Prisma's [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions-1) , both fields should be lowercased to `post`, `profile` and `user`.
 - Even after lowercasing, the `post` field on `User` is still slightly misnamed. That's because it actually refers to a [list](/concepts/components/prisma-schema/data-model#type-modifiers) of posts – a better name therefore would be the plural form: `posts`.
 
 These changes are relevant for the generated Prisma Client API where using lowercased relation fields `author`, `posts`, `profile` and `user` will feel more natural and idiomatic to JavaScript/TypeScript developers. You can therefore [configure your Prisma Client API](/concepts/components/prisma-client/working-with-prismaclient/use-custom-model-and-field-names).
@@ -574,7 +574,7 @@ model User {
 }
 ```
 
-In this example, the database schema did follow the [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions) <span class="api"></span> for Prisma models (only the virtual relation fields that were generated from introspection did not adhere to them and needed adjustment). This optimizes the ergonomics of the generated Prisma Client API.
+In this example, the database schema did follow the [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions)  for Prisma models (only the virtual relation fields that were generated from introspection did not adhere to them and needed adjustment). This optimizes the ergonomics of the generated Prisma Client API.
 
 Sometimes though, you may want to make additional changes to the names of the columns and tables that are exposed in the Prisma Client API. A common example is to translate _snake_case_ notation which is often used in database schemas into _PascalCase_ and _camelCase_ notations which feel more natural for JavaScript/TypeScript developers.
 
@@ -675,8 +675,8 @@ Prisma's data model is a declarative representation of your database schema and
 
 Right now, there's a few minor "issues" with the data model:
 
-- The `User` relation field is uppercased and therefore doesn't adhere to Prisma's [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions-1) <span class="api"></span>. To express more "semantics", it would also be nice if this field was called `author` to _describe_ the relationship between `User` and `Post` better.
-- The `Post` and `Profile` relation fields on `User` as well as the `User` relation field on `Profile` are all uppercased. To adhere to Prisma's [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions-1) <span class="api"></span>, both fields should be lowercased to `post`, `profile` and `user`.
+- The `User` relation field is uppercased and therefore doesn't adhere to Prisma's [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions-1) . To express more "semantics", it would also be nice if this field was called `author` to _describe_ the relationship between `User` and `Post` better.
+- The `Post` and `Profile` relation fields on `User` as well as the `User` relation field on `Profile` are all uppercased. To adhere to Prisma's [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions-1) , both fields should be lowercased to `post`, `profile` and `user`.
 - Even after lowercasing, the `post` field on `User` is still slightly misnamed. That's because it actually refers to a [list](/concepts/components/prisma-schema/data-model#type-modifiers) of posts – a better name therefore would be the plural form: `posts`.
 
 These changes are relevant for the generated Prisma Client API where using lowercased relation fields `author`, `posts`, `profile` and `user` will feel more natural and idiomatic to JavaScript/TypeScript developers. You can therefore [configure your Prisma Client API](/concepts/components/prisma-client/working-with-prismaclient/use-custom-model-and-field-names).
@@ -710,7 +710,7 @@ model User {
 }
 ```
 
-In this example, the database schema did follow the [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions) <span class="api"></span> for Prisma models (only the virtual relation fields that were generated from introspection did not adhere to them and needed adjustment). This optimizes the ergonomics of the generated Prisma Client API.
+In this example, the database schema did follow the [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions)  for Prisma models (only the virtual relation fields that were generated from introspection did not adhere to them and needed adjustment). This optimizes the ergonomics of the generated Prisma Client API.
 
 <details>
 <summary> Using custom model and field names </summary>
@@ -815,7 +815,7 @@ model User {
 
 <Admonition>
 
-Refer to the [Prisma schema reference](/reference/api-reference/prisma-schema-reference) <span class="api"></span> for detailed information about the schema definition.
+Refer to the [Prisma schema reference](/reference/api-reference/prisma-schema-reference)  for detailed information about the schema definition.
 
 </Admonition>
 
@@ -865,7 +865,7 @@ Prisma Migrate will now keep the manually added relation fields.
 
 Because relation fields are _virtual_ (i.e. they _do not directly manifest in the database_), you can manually rename them in your Prisma schema without touching the database.
 
-In this example, the database schema follows the [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions) <span class="api"></span> for Prisma models. This optimizes the ergonomics of the generated Prisma Client API.
+In this example, the database schema follows the [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions)  for Prisma models. This optimizes the ergonomics of the generated Prisma Client API.
 
 <details>
 <summary> Using custom model and field names </summary>
@@ -971,8 +971,8 @@ Prisma's data model is a declarative representation of your database schema and
 
 Right now, there's a few minor "issues" with the data model:
 
-- The `User` relation field is uppercased and therefore doesn't adhere to Prisma's [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions-1) <span class="api"></span>. To express more "semantics", it would also be nice if this field was called `author` to _describe_ the relationship between `User` and `Post` better.
-- The `Post` and `Profile` relation fields on `User` as well as the `User` relation field on `Profile` are all uppercased. To adhere to Prisma's [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions-1) <span class="api"></span>, both fields should be lowercased to `post`, `profile` and `user`.
+- The `User` relation field is uppercased and therefore doesn't adhere to Prisma's [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions-1) . To express more "semantics", it would also be nice if this field was called `author` to _describe_ the relationship between `User` and `Post` better.
+- The `Post` and `Profile` relation fields on `User` as well as the `User` relation field on `Profile` are all uppercased. To adhere to Prisma's [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions-1) , both fields should be lowercased to `post`, `profile` and `user`.
 - Even after lowercasing, the `post` field on `User` is still slightly misnamed. That's because it actually refers to a [list](/concepts/components/prisma-schema/data-model#type-modifiers) of posts – a better name therefore would be the plural form: `posts`.
 
 These changes are relevant for the generated Prisma Client API where using lowercased relation fields `author`, `posts`, `profile` and `user` will feel more natural and idiomatic to JavaScript/TypeScript developers. You can therefore [configure your Prisma Client API](/concepts/components/prisma-client/working-with-prismaclient/use-custom-model-and-field-names).
@@ -1006,7 +1006,7 @@ model User {
 }
 ```
 
-In this example, the database schema did follow the [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions) <span class="api"></span> for Prisma models (only the virtual relation fields that were generated from introspection did not adhere to them and needed adjustment). This optimizes the ergonomics of the generated Prisma Client API.
+In this example, the database schema did follow the [naming conventions](/reference/api-reference/prisma-schema-reference#naming-conventions)  for Prisma models (only the virtual relation fields that were generated from introspection did not adhere to them and needed adjustment). This optimizes the ergonomics of the generated Prisma Client API.
 
 <details>
 <summary> Using custom model and field names </summary>

content/200-orm/050-overview/100-introduction/500-databases/01-database-drivers.mdx

@@ -7,7 +7,7 @@ tocDepth: 4
 
 ## Default built-in drivers
 
-One of Prisma Client's components is the [Query Engine](./prisma-engines/query-engine) <span class="concept"></span>. The Query Engine is responsible for transforming Prisma Client queries to SQL statements. The Query Engine connects to your database using the included drivers that don't require additional setup. The built-in drivers use TCP connections to connect to the database.
+One of Prisma Client's components is the [Query Engine](./prisma-engines/query-engine) . The Query Engine is responsible for transforming Prisma Client queries to SQL statements. The Query Engine connects to your database using the included drivers that don't require additional setup. The built-in drivers use TCP connections to connect to the database.
 
 ![Query flow from the user application to the database with Prisma Client](./images/drivers/qe-query-execution-flow.png)
 

content/200-orm/050-overview/100-introduction/500-databases/03-postgresql.mdx

@@ -9,7 +9,7 @@ tocDepth: 3
 
 The PostgreSQL data source connector connects Prisma to a [PostgreSQL](https://www.postgresql.org/) database server.
 
-By default, the PostgreSQL connector contains a database driver responsible for connecting to your database. You can use a [driver adapter](/concepts/components/database-drivers#driver-adapters) <span class="concept"></span> (Preview) to connect to your database using a JavaScript database driver from Prisma Client.
+By default, the PostgreSQL connector contains a database driver responsible for connecting to your database. You can use a [driver adapter](/concepts/components/database-drivers#driver-adapters)  (Preview) to connect to your database using a JavaScript database driver from Prisma Client.
 
 </TopBlock>
 
@@ -210,7 +210,7 @@ The PostgreSQL connector maps the [scalar types](/concepts/components/prisma-sch
 | Composite types                             |  Not yet  | n/a           |                                          |                                                                                                                                                                                    |
 | Domain types                                |  Not yet  | n/a           |                                          |                                                                                                                                                                                    |
 
-[Introspection](/concepts/components/introspection) adds native database types that are **not yet supported** as [`Unsupported`](/reference/api-reference/prisma-schema-reference#unsupported) <span class="api"></span> fields:
+[Introspection](/concepts/components/introspection) adds native database types that are **not yet supported** as [`Unsupported`](/reference/api-reference/prisma-schema-reference#unsupported)  fields:
 
 ```prisma file=schema.prisma
 model Device {

content/200-orm/050-overview/100-introduction/500-databases/04-mysql.mdx

@@ -9,7 +9,7 @@ tocDepth: 3
 
 The MySQL data source connector connects Prisma to a [MySQL](https://www.mysql.com/) database server.
 
-By default, the MySQL connector contains a database driver responsible for connecting to your database. You can use a [driver adapter](/concepts/components/database-drivers#driver-adapters) <span class="concept"></span> (Preview) to connect to your database using a JavaScript database driver from Prisma Client.
+By default, the MySQL connector contains a database driver responsible for connecting to your database. You can use a [driver adapter](/concepts/components/database-drivers#driver-adapters)  (Preview) to connect to your database using a JavaScript database driver from Prisma Client.
 
 </TopBlock>
 
@@ -191,7 +191,7 @@ When introspecting a MySQL database, the database types are mapped to Prisma acc
 | `multipolygon`            | `Unsupported` | Not yet   |                                                |
 | `geometrycollection`      | `Unsupported` | Not yet   |                                                |
 
-[Introspection](/concepts/components/introspection) adds native database types that are **not yet supported** as [`Unsupported`](/reference/api-reference/prisma-schema-reference#unsupported) <span class="api"></span> fields:
+[Introspection](/concepts/components/introspection) adds native database types that are **not yet supported** as [`Unsupported`](/reference/api-reference/prisma-schema-reference#unsupported)  fields:
 
 ```prisma file=schema.prisma
 model Device {

content/200-orm/050-overview/100-introduction/500-databases/05-sqlite.mdx

@@ -9,7 +9,7 @@ tocDepth: 3
 
 The SQLite data source connector connects Prisma to a [SQLite](https://www.sqlite.org/) database file. These files always have the file ending `.db` (e.g.: `dev.db`).
 
-By default, the SQLite connector contains a database driver responsible for connecting to your database. You can use a [driver adapter](/concepts/components/database-drivers#driver-adapters) <span class="concept"></span> (Preview) to connect to your database using a JavaScript database driver from Prisma Client.
+By default, the SQLite connector contains a database driver responsible for connecting to your database. You can use a [driver adapter](/concepts/components/database-drivers#driver-adapters)  (Preview) to connect to your database using a JavaScript database driver from Prisma Client.
 
 </TopBlock>
 

content/200-orm/050-overview/100-introduction/500-databases/07-mongodb.mdx

@@ -564,7 +564,7 @@ When introspecting a MongoDB database, Prisma uses the relevant [scalar types](/
 | ------------------------- | -------- | :-------: | :----------------------------- | :---- |
 | `objectId`                | `String` |    ✔️     | `@db.ObjectId`                 |       |
 
-[Introspection](/concepts/components/introspection) adds native database types that are **not yet supported** as [`Unsupported`](/reference/api-reference/prisma-schema-reference#unsupported) <span class="api"></span> fields:
+[Introspection](/concepts/components/introspection) adds native database types that are **not yet supported** as [`Unsupported`](/reference/api-reference/prisma-schema-reference#unsupported)  fields:
 
 ```prisma file=schema.prisma
 model Example {