Bold text does stand out significantly from the regular text

src/guide/component-attrs.md

@@ -78,7 +78,7 @@ const app = Vue.createApp({
 
 ## Disabling Attribute Inheritance
 
-If you do **not** want a component to automatically inherit attributes, you can set `inheritAttrs: false` in the component's options.
+If you do <b>not</b> want a component to automatically inherit attributes, you can set `inheritAttrs: false` in the component's options.
 
 The common scenario for disabling an attribute inheritance is when attributes need to be applied to other elements besides the root node.
 

src/guide/component-edge-cases.md

@@ -18,7 +18,7 @@ However, if you've ruled out the above and find yourself in this extremely rare
 
 ### Cheap Static Components with `v-once`
 
-Rendering plain HTML elements is very fast in Vue, but sometimes you might have a component that contains **a lot** of static content. In these cases, you can ensure that it's only evaluated once and then cached by adding the `v-once` directive to the root element, like this:
+Rendering plain HTML elements is very fast in Vue, but sometimes you might have a component that contains <b>a lot</b> of static content. In these cases, you can ensure that it's only evaluated once and then cached by adding the `v-once` directive to the root element, like this:
 
 ```js
 app.component('terms-of-service', {

src/guide/component-props.md

@@ -123,13 +123,13 @@ Will be equivalent to:
 
 ## One-Way Data Flow
 
-All props form a **one-way-down binding** between the child property and the parent one: when the parent property updates, it will flow down to the child, but not the other way around. This prevents child components from accidentally mutating the parent's state, which can make your app's data flow harder to understand.
+All props form a <b>one-way-down binding</b> between the child property and the parent one: when the parent property updates, it will flow down to the child, but not the other way around. This prevents child components from accidentally mutating the parent's state, which can make your app's data flow harder to understand.
 
-In addition, every time the parent component is updated, all props in the child component will be refreshed with the latest value. This means you should **not** attempt to mutate a prop inside a child component. If you do, Vue will warn you in the console.
+In addition, every time the parent component is updated, all props in the child component will be refreshed with the latest value. This means you should <b>not</b> attempt to mutate a prop inside a child component. If you do, Vue will warn you in the console.
 
 There are usually two cases where it's tempting to mutate a prop:
 
-1. **The prop is used to pass in an initial value; the child component wants to use it as a local data property afterwards.** In this case, it's best to define a local data property that uses the prop as its initial value:
+1. <b>The prop is used to pass in an initial value; the child component wants to use it as a local data property afterwards.</b> In this case, it's best to define a local data property that uses the prop as its initial value:
 
 ```js
 props: ['initialCounter'],
@@ -140,7 +140,7 @@ data() {
 }
 ```
 
-2. **The prop is passed in as a raw value that needs to be transformed.** In this case, it's best to define a computed property using the prop's value:
+2. <b>The prop is passed in as a raw value that needs to be transformed.</b> In this case, it's best to define a computed property using the prop's value:
 
 ```js
 props: ['size'],
@@ -152,7 +152,7 @@ computed: {
 ```
 
 ::: tip Note
-Note that objects and arrays in JavaScript are passed by reference, so if the prop is an array or object, mutating the object or array itself inside the child component **will** affect parent state.
+Note that objects and arrays in JavaScript are passed by reference, so if the prop is an array or object, mutating the object or array itself inside the child component <b>will</b> affect parent state.
 :::
 
 ## Prop Validation
@@ -209,7 +209,7 @@ app.component('my-component', {
 When prop validation fails, Vue will produce a console warning (if using the development build).
 
 ::: tip Note
-Note that props are validated **before** a component instance is created, so instance properties (e.g. `data`, `computed`, etc) will not be available inside `default` or `validator` functions.
+Note that props are validated <b>before</b> a component instance is created, so instance properties (e.g. `data`, `computed`, etc) will not be available inside `default` or `validator` functions.
 :::
 
 ### Type Checks

src/guide/component-registration.md

@@ -59,7 +59,7 @@ Vue.createApp({...}).component('my-component-name', {
 })
 ```
 
-These components are **globally registered** for the application. That means they can be used in the template of any component instance within this application:
+These components are <b>globally registered</b> for the application. That means they can be used in the template of any component instance within this application:
 
 ```js
 const app = Vue.createApp({})
@@ -118,7 +118,7 @@ const app = Vue.createApp({
 
 For each property in the `components` object, the key will be the name of the custom element, while the value will contain the options object for the component.
 
-Note that **locally registered components are _not_ also available in subcomponents**. For example, if you wanted `ComponentA` to be available in `ComponentB`, you'd have to use:
+Note that <b>locally registered components are _not_ also available in subcomponents</b>. For example, if you wanted `ComponentA` to be available in `ComponentB`, you'd have to use:
 
 ```js
 const ComponentA = {

src/guide/component-slots.md

@@ -52,7 +52,7 @@ Or even other components:
 </todo-button>
 ```
 
-If `<todo-button>`'s template did **not** contain a `<slot>` element, any content provided between its opening and closing tag would be discarded.
+If `<todo-button>`'s template did <b>not</b> contain a `<slot>` element, any content provided between its opening and closing tag would be discarded.
 
 ```html
 <!-- todo-button component template -->
@@ -83,7 +83,7 @@ That slot has access to the same instance properties (i.e. the same "scope") as
 
 <img src="/images/slot.png" width="447" height="auto" style="display: block; margin: 0 auto; max-width: 100%" loading="lazy" alt="Slot explanation diagram">
 
-The slot does **not** have access to `<todo-button>`'s scope. For example, trying to access `action` would not work:
+The slot does <b>not</b> have access to `<todo-button>`'s scope. For example, trying to access `action` would not work:
 
 ```html
 <todo-button action="delete">
@@ -222,7 +222,7 @@ The rendered HTML will be:
 </div>
 ```
 
-Note that **`v-slot` can only be added to a `<template>`** (with [one exception](#abbreviated-syntax-for-lone-default-slots))
+Note that <b>`v-slot` can only be added to a `<template>`</b> (with [one exception](#abbreviated-syntax-for-lone-default-slots))
 
 ## Scoped Slots
 
@@ -278,7 +278,7 @@ You can bind as many attributes to the `slot` as you need:
 </ul>
 ```
 
-Attributes bound to a `<slot>` element are called **slot props**. Now, in the parent scope, we can use `v-slot` with a value to define a name for the slot props we've been provided:
+Attributes bound to a `<slot>` element are called <b>slot props</b>. Now, in the parent scope, we can use `v-slot` with a value to define a name for the slot props we've been provided:
 
 ```html
 <todo-list>
@@ -313,7 +313,7 @@ This can be shortened even further. Just as non-specified content is assumed to
 </todo-list>
 ```
 
-Note that the abbreviated syntax for default slot **cannot** be mixed with named slots, as it would lead to scope ambiguity:
+Note that the abbreviated syntax for default slot <b>cannot</b> be mixed with named slots, as it would lead to scope ambiguity:
 
 ```html
 <!-- INVALID, will result in warning -->

src/guide/composition-api-introduction.md

@@ -55,28 +55,28 @@ This component has several responsibilities:
 2. Searching for repositories using a `searchQuery` string
 3. Filtering repositories using a `filters` object
 
-Organizing logics with component's options (`data`, `computed`, `methods`, `watch`) works in most cases. However, when our components get bigger, the list of **logical concerns** also grows. This can lead to components that are hard to read and understand, especially for people who didn't write them in the first place.
+Organizing logics with component's options (`data`, `computed`, `methods`, `watch`) works in most cases. However, when our components get bigger, the list of <b>logical concerns</b> also grows. This can lead to components that are hard to read and understand, especially for people who didn't write them in the first place.
 
 ![Vue Options API: Code grouped by option type](/images/options-api.png)
 
-Example presenting a large component where its **logical concerns** are grouped by colors.
+Example presenting a large component where its <b>logical concerns</b> are grouped by colors.
 
 Such fragmentation is what makes it difficult to understand and maintain a complex component. The separation of options obscures the underlying logical concerns. In addition, when working on a single logical concern, we have to constantly "jump" around option blocks for the relevant code.
 
 It would be much nicer if we could collocate code related to the same logical concern. And this is exactly what the Composition API enables us to do.
 
 ## Basics of Composition API
 
-Now that we know the **why** we can get to the **how**. To start working with the Composition API we first need a place where we can actually use it. In a Vue component, we call this place the `setup`.
+Now that we know the <b>why</b> we can get to the <b>how</b>. To start working with the Composition API we first need a place where we can actually use it. In a Vue component, we call this place the `setup`.
 
 ### `setup` Component Option
 
 <VideoLesson href="https://www.vuemastery.com/courses/vue-3-essentials/setup-and-reactive-references" title="Learn how setup works with Vue Mastery">Watch a free video on setup on Vue Mastery</VideoLesson>
 
-The new `setup` component option is executed **before** the component is created, once the `props` are resolved, and serves as the entry point for composition API's.
+The new `setup` component option is executed <b>before</b> the component is created, once the `props` are resolved, and serves as the entry point for composition API's.
 
 ::: warning
-Because the component instance is not yet created when `setup` is executed, there is no `this` inside a `setup` option. This means, with the exception of `props`, you won't be able to access any properties declared in the component – **local state**, **computed properties** or **methods**.
+Because the component instance is not yet created when `setup` is executed, there is no `this` inside a `setup` option. This means, with the exception of `props`, you won't be able to access any properties declared in the component – <b>local state</b>, <b>computed properties</b> or <b>methods</b>.
 :::
 
 The `setup` option should be a function that accepts `props` and `context` which we will talk about [later](composition-api-setup.html#arguments). Additionally, everything that we return from `setup` will be exposed to the rest of our component (computed properties, methods, lifecycle hooks and so on) as well as to the component's template.
@@ -164,7 +164,7 @@ Wrapping values inside an object might seem unnecessary but is required to keep
 Having a wrapper object around any value allows us to safely pass it across our whole app without worrying about losing its reactivity somewhere along the way.
 
 ::: tip Note
-In other words, `ref` creates a **Reactive Reference** to our value. The concept of working with **References** will be used often throughout the Composition API.
+In other words, `ref` creates a <b>Reactive Reference</b> to our value. The concept of working with <b>References</b> will be used often throughout the Composition API.
 :::
 
 Back to our example, let's create a reactive `repositories` variable:
@@ -275,11 +275,11 @@ Now we need to react to the changes made to the `user` prop. For that we will us
 
 Just like how we set up a watcher on the `user` property inside our component using the `watch` option, we can do the same using the `watch` function imported from Vue. It accepts 3 arguments:
 
-- A **Reactive Reference** or getter function that we want to watch
+- A <b>Reactive Reference</b> or getter function that we want to watch
 - A callback
 - Optional configuration options
 
-**Here’s a quick look at how it works.**
+<b>Here’s a quick look at how it works.</b>
 
 ```js
 import { ref, watch } from 'vue'
@@ -292,7 +292,7 @@ watch(counter, (newValue, oldValue) => {
 
 Whenever `counter` is modified, for example `counter.value = 5`, the watch will trigger and execute the callback (second argument) which in this case will log `'The new counter value is: 5'` into our console.
 
-**Below is the Options API equivalent:**
+<b>Below is the Options API equivalent:</b>
 
 ```js
 export default {
@@ -311,7 +311,7 @@ export default {
 
 For more details on `watch`, refer to our [in-depth guide](reactivity-computed-watchers.md#watch).
 
-**Let’s now apply it to our example:**
+<b>Let’s now apply it to our example:</b>
 
 ```js
 // src/components/UserRepositories.vue `setup` function
@@ -360,7 +360,7 @@ console.log(counter.value) // 1
 console.log(twiceTheCounter.value) // 2
 ```
 
-Here, the `computed` function returns a _read-only_ **Reactive Reference** to the output of the getter-like callback passed as the first argument to `computed`. In order to access the **value** of the newly-created computed variable, we need to use the `.value` property just like with `ref`.
+Here, the `computed` function returns a _read-only_ <b>Reactive Reference</b> to the output of the getter-like callback passed as the first argument to `computed`. In order to access the <b>value</b> of the newly-created computed variable, we need to use the `.value` property just like with `ref`.
 
 Let’s move our search functionality into `setup`:
 
@@ -401,7 +401,7 @@ setup (props) {
 }
 ```
 
-We could do the same for other **logical concerns** but you might be already asking the question – _Isn’t this just moving the code to the `setup` option and making it extremely big?_ Well, that’s true. That’s why before moving on with the other responsibilities, we will first extract the above code into a standalone **composition function**. Let's start with creating `useUserRepositories`:
+We could do the same for other <b>logical concerns</b> but you might be already asking the question – _Isn’t this just moving the code to the `setup` option and making it extremely big?_ Well, that’s true. That’s why before moving on with the other responsibilities, we will first extract the above code into a standalone <b>composition function</b>. Let's start with creating `useUserRepositories`:
 
 ```js
 // src/composables/useUserRepositories.js
@@ -447,7 +447,7 @@ export default function useRepositoryNameSearch(repositories) {
 }
 ```
 
-**Now having those two functionalities in separate files, we can start using them in our component. Here’s how this can be done:**
+<b>Now having those two functionalities in separate files, we can start using them in our component. Here’s how this can be done:</b>
 
 ```js
 // src/components/UserRepositories.vue

src/guide/computed.md

@@ -32,7 +32,7 @@ And we want to display different messages depending on if `author` already has s
 
 At this point, the template is no longer simple and declarative. You have to look at it for a second before realizing that it performs a calculation depending on `author.books`. The problem is made worse when you want to include this calculation in your template more than once.
 
-That's why for complex logic that includes reactive data, you should use a **computed property**.
+That's why for complex logic that includes reactive data, you should use a <b>computed property</b>.
 
 ### Basic Example
 
@@ -94,7 +94,7 @@ methods: {
 }
 ```
 
-Instead of a computed property, we can define the same function as a method. For the end result, the two approaches are indeed exactly the same. However, the difference is that **computed properties are cached based on their reactive dependencies.** A computed property will only re-evaluate when some of its reactive dependencies have changed. This means as long as `author.books` has not changed, multiple access to the `publishedBooksMessage` computed property will immediately return the previously computed result without having to run the function again.
+Instead of a computed property, we can define the same function as a method. For the end result, the two approaches are indeed exactly the same. However, the difference is that <b>computed properties are cached based on their reactive dependencies.</b> A computed property will only re-evaluate when some of its reactive dependencies have changed. This means as long as `author.books` has not changed, multiple access to the `publishedBooksMessage` computed property will immediately return the previously computed result without having to run the function again.
 
 This also means the following computed property will never update, because `Date.now()` is not a reactive dependency:
 
@@ -106,7 +106,7 @@ computed: {
 }
 ```
 
-In comparison, a method invocation will **always** run the function whenever a re-render happens.
+In comparison, a method invocation will <b>always</b> run the function whenever a re-render happens.
 
 Why do we need caching? Imagine we have an expensive computed property `list`, which requires looping through a huge array and doing a lot of computations. Then we may have other computed properties that in turn depend on `list`. Without caching, we would be executing `list`’s getter many more times than necessary! In cases where you do not want caching, use a `method` instead.
 
@@ -200,7 +200,7 @@ In addition to the `watch` option, you can also use the imperative [vm.$watch AP
 
 ### Computed vs Watched Property
 
-Vue does provide a more generic way to observe and react to data changes on a current active instance: **watch properties**. When you have some data that needs to change based on some other data, it is tempting to overuse `watch` - especially if you are coming from an AngularJS background. However, it is often a better idea to use a computed property rather than an imperative `watch` callback. Consider this example:
+Vue does provide a more generic way to observe and react to data changes on a current active instance: <b>watch properties</b>. When you have some data that needs to change based on some other data, it is tempting to overuse `watch` - especially if you are coming from an AngularJS background. However, it is often a better idea to use a computed property rather than an imperative `watch` callback. Consider this example:
 
 ```html
 <div id="demo">{{ fullName }}</div>

src/guide/conditional.md

@@ -79,7 +79,7 @@ The difference is that an element with `v-show` will always be rendered and rema
 
 `v-if` is "real" conditional rendering because it ensures that event listeners and child components inside the conditional block are properly destroyed and re-created during toggles.
 
-`v-if` is also **lazy**: if the condition is false on initial render, it will not do anything - the conditional block won't be rendered until the condition becomes true for the first time.
+`v-if` is also <b>lazy</b>: if the condition is false on initial render, it will not do anything - the conditional block won't be rendered until the condition becomes true for the first time.
 
 In comparison, `v-show` is much simpler - the element is always rendered regardless of initial condition, with CSS-based toggling.
 
@@ -88,7 +88,7 @@ Generally speaking, `v-if` has higher toggle costs while `v-show` has higher ini
 ## `v-if` with `v-for`
 
 ::: tip Note
-Using `v-if` and `v-for` together is **not recommended**. See the [style guide](../style-guide/#avoid-v-if-with-v-for-essential) for further information.
+Using `v-if` and `v-for` together is <b>not recommended</b>. See the [style guide](../style-guide/#avoid-v-if-with-v-for-essential) for further information.
 :::
 
 When `v-if` and `v-for` are both used on the same element, `v-if` will be evaluated first. See the [list rendering guide](list#v-for-with-v-if) for details.