Question: The following classes in are unused and should be removed: .help-modal .help-modal-heading .btn-lgRemove the above classes from Test and confirm that the modal displays properly after the changes

text-align: left; } <del> @media screen and (max-width: 767px) { .help-modal .btn-lg { font-size: 16px; } } </del> .help-text-warning { text-align: left; }


Question:
Timeout limits are too aggressive on this problem and blocking users from computing the correct answer. Verified via , the code above produces the correct number of semiprimes for 1, 10, ..., . However, for , we have a timeout. This code could probably be a bit more efficient, but even if I just cut it down to finding all primes < , it times out, indicating that it is not possible for campers to complete this exercise with the current infinite loop protections on this problem. All?
Seems like a good challenge to just remove the loop protect from entirely.
Seems like a reasonable fix to me

"order": 1, "superBlock": "project-euler", "disableLoopProtectTests": true, <ins> "disableLoopProtectPreview": true, </ins> "challengeOrder": [ { "id": "5900f3d21000cf542c50fee4",


Question:
On step 89 and 90 of the Pyramid generator there is this misterious error that appear, it can be confusing for campers. !
Error is coming from the function, specifically one of the string repeats. Depending on the and , when or will be , calling method of string will show that error. Edit: When condition is there's no such issue.
Yep. I think reworking the lessons so we never leave the learner with broken code (or at least never unexplained broken code) is the way to go.
I'm not sure if it was even intended to have broken code, description is suggesting everything should work fine. Step 91 asks for two changes, one of which specifically makes this error appear (second change fixes the issue).
Yeah, it's a bit confusing. Probably not intentional, though. On 91 there's this: the only time I don't see the error is when I've followed all the instructions on step 91.
Is this not enough to clear up any doubts? Cuz after following the instructions in step 91, there's nothing mysterious about the error anymore.
I don't think so. Step 89, where error is introduced, doesn't mention it. Neither does 90. It's only when you reach 91 that the error is mentioned and the text is which is incorrect. Changing to has no effect on the error. It's only the combination of that and adjusting the conditional that finally removes the error. The main issue with this is that it breaks the feedback loop between learner's actions and the code's behaviour. Speaking for myself, everything gets harder when the results of my actions are essentially invisible. I know we run tests to check you re doing it right, but that's not really a substitute for them seeing how your actions impact the program.
Okay. We need to at least note the possibility of an unexpected error to the camper. I'm thinking on step 89 now.
Just for posterity, the steps got shifted. Error is introduced by completing step 95 Error is resolved by completing step 96 What should be changed here: Step 95 should: Introduce and explain the error Ask the campers to change the comparison to Step 96 should: No longer ask campers to change the to Not mention that creates a

Arrays have a special `length` property that allows you to see how many values, or <dfn>elements</dfn>, are in the array. You would access this property using syntax like `myArray.length`. <del> Update your condition to check if `rows.length` is less than or equal to `count`. </del> <ins> Note that `rows.length` in the `padRow` call would give you an off-by-one error, because `done` is incremented *before* the call. Update your condition to check if `rows.length` is less than `count`. </ins> # --hints-- <del> Your `while` loop should check if `rows.length` is less than or equal to `count`. </del> <ins> Your `while` loop should check if `rows.length` is less than `count`. </ins> ```js <del> assert.match(__helpers.removeJSComments(code), /whiles*(s*rows.lengths*<=s*counts*)/); </del> <ins> assert.match(__helpers.removeJSComments(code), /whiles*(s*rows.lengths*<s*counts*)/); </ins> ``` # --seed--


Question:
On step 89 and 90 of the Pyramid generator there is this misterious error that appear, it can be confusing for campers. !
Error is coming from the function, specifically one of the string repeats. Depending on the and , when or will be , calling method of string will show that error. Edit: When condition is there's no such issue.
Yep. I think reworking the lessons so we never leave the learner with broken code (or at least never unexplained broken code) is the way to go.
I'm not sure if it was even intended to have broken code, description is suggesting everything should work fine. Step 91 asks for two changes, one of which specifically makes this error appear (second change fixes the issue).
Yeah, it's a bit confusing. Probably not intentional, though. On 91 there's this: the only time I don't see the error is when I've followed all the instructions on step 91.
Is this not enough to clear up any doubts? Cuz after following the instructions in step 91, there's nothing mysterious about the error anymore.
I don't think so. Step 89, where error is introduced, doesn't mention it. Neither does 90. It's only when you reach 91 that the error is mentioned and the text is which is incorrect. Changing to has no effect on the error. It's only the combination of that and adjusting the conditional that finally removes the error. The main issue with this is that it breaks the feedback loop between learner's actions and the code's behaviour. Speaking for myself, everything gets harder when the results of my actions are essentially invisible. I know we run tests to check you re doing it right, but that's not really a substitute for them seeing how your actions impact the program.
Okay. We need to at least note the possibility of an unexpected error to the camper. I'm thinking on step 89 now.
Just for posterity, the steps got shifted. Error is introduced by completing step 95 Error is resolved by completing step 96 What should be changed here: Step 95 should: Introduce and explain the error Ask the campers to change the comparison to Step 96 should: No longer ask campers to change the to Not mention that creates a

# --description-- <del> You can also replace the `done` reference in your `padRow` call. Note that `rows.length` here would give you an off-by-one error, because `done` is incremented *before* the call. So you'll need to replace `done` here with `rows.length + 1`. When you do this, you may see a `Range Error`, because we've created another off-by-one error. You'll need to change the `while` condition to use the less than operator, instead of the less than or equal operator. </del> <ins> Replace the `done` reference in your `padRow` call with `rows.length + 1`. </ins> # --hints--


Question:
On step 89 and 90 of the Pyramid generator there is this misterious error that appear, it can be confusing for campers. !
Error is coming from the function, specifically one of the string repeats. Depending on the and , when or will be , calling method of string will show that error. Edit: When condition is there's no such issue.
Yep. I think reworking the lessons so we never leave the learner with broken code (or at least never unexplained broken code) is the way to go.
I'm not sure if it was even intended to have broken code, description is suggesting everything should work fine. Step 91 asks for two changes, one of which specifically makes this error appear (second change fixes the issue).
Yeah, it's a bit confusing. Probably not intentional, though. On 91 there's this: the only time I don't see the error is when I've followed all the instructions on step 91.
Is this not enough to clear up any doubts? Cuz after following the instructions in step 91, there's nothing mysterious about the error anymore.
I don't think so. Step 89, where error is introduced, doesn't mention it. Neither does 90. It's only when you reach 91 that the error is mentioned and the text is which is incorrect. Changing to has no effect on the error. It's only the combination of that and adjusting the conditional that finally removes the error. The main issue with this is that it breaks the feedback loop between learner's actions and the code's behaviour. Speaking for myself, everything gets harder when the results of my actions are essentially invisible. I know we run tests to check you re doing it right, but that's not really a substitute for them seeing how your actions impact the program.
Okay. We need to at least note the possibility of an unexpected error to the camper. I'm thinking on step 89 now.
Just for posterity, the steps got shifted. Error is introduced by completing step 95 Error is resolved by completing step 96 What should be changed here: Step 95 should: Introduce and explain the error Ask the campers to change the comparison to Step 96 should: No longer ask campers to change the to Not mention that creates a

assert.match(__helpers.removeJSComments(code), /rows.push(padRows*(s*rows.lengths*+s*1/); ``` <del> Your `while` loop should run while `rows.length` is less than `count`. ```js assert.match(__helpers.removeJSComments(code), /whiles*(s*rows.lengths*<s*count)/); ``` </del> # --seed-- ## --seed-contents--


Question:
On step 89 and 90 of the Pyramid generator there is this misterious error that appear, it can be confusing for campers. !
Error is coming from the function, specifically one of the string repeats. Depending on the and , when or will be , calling method of string will show that error. Edit: When condition is there's no such issue.
Yep. I think reworking the lessons so we never leave the learner with broken code (or at least never unexplained broken code) is the way to go.
I'm not sure if it was even intended to have broken code, description is suggesting everything should work fine. Step 91 asks for two changes, one of which specifically makes this error appear (second change fixes the issue).
Yeah, it's a bit confusing. Probably not intentional, though. On 91 there's this: the only time I don't see the error is when I've followed all the instructions on step 91.
Is this not enough to clear up any doubts? Cuz after following the instructions in step 91, there's nothing mysterious about the error anymore.
I don't think so. Step 89, where error is introduced, doesn't mention it. Neither does 90. It's only when you reach 91 that the error is mentioned and the text is which is incorrect. Changing to has no effect on the error. It's only the combination of that and adjusting the conditional that finally removes the error. The main issue with this is that it breaks the feedback loop between learner's actions and the code's behaviour. Speaking for myself, everything gets harder when the results of my actions are essentially invisible. I know we run tests to check you re doing it right, but that's not really a substitute for them seeing how your actions impact the program.
Okay. We need to at least note the possibility of an unexpected error to the camper. I'm thinking on step 89 now.
Just for posterity, the steps got shifted. Error is introduced by completing step 95 Error is resolved by completing step 96 What should be changed here: Step 95 should: Introduce and explain the error Ask the campers to change the comparison to Step 96 should: No longer ask campers to change the to Not mention that creates a

--fcc-editable-region-- let done = 0; <del> while (rows.length <= count) { </del> <ins> while (rows.length < count) { </ins> done++; rows.push(padRow(done, count)); }


Question:
I encountered an issue while completing a task (Step 11) on freeCodeCamp. The test involves using the method to determine whether a task already exists in an array and then either updating it or adding a new task. The problem appears to be related to the comparison order in the arrow function passed to . When I change the comparison order, the code works without any issues: ! ! and No response Device: [e.g. iPhone 6, Laptop] OS: [e.g. iOS 14, Windows 10, Ubuntu 20.04] Browser: [e.g. Chrome, Safari] Version: [e.g. 22] No response
You didn't mention the error caused.

Your arrow function callback should check if `item.id === currentTask.id`. ```js <del> assert.match(code, /consts+dataArrIndexs*=s*taskData.findIndex(s*((s*items*)|item)s*=>s*item.ids*===s*currentTask.ids*)s*;?/) </del> <ins> assert.match(code, /consts+dataArrIndexs*=s*taskData.findIndex(s*((s*items*)|item)s*=>s*(?:item.ids*===s*currentTask.id|currentTask.ids*===s*item.id)s*)s*;?/) </ins> ``` # --seed--


Question:
When the blanks in a fill in a blank challenge overlap vertically, the top selection box gets cut off: <img width="767" alt="Screenshot 2024-06-17 at 5 39 59 PM" src=""^ See the two blanks in the sentence are above and below one another. When you click the first blank, the blue selection box is cut off - presumably because the input below is in front of the first input. to on the first blank in the sentence the blank get cut off The box to be visible We could adjust the spacing so the input doesn't get cut off, or move the z-index of the input to the front when it's selected.
I think changing the z-index on select makes sense.
We might also consider increasing the . The lines are pretty close together. Not sure why we are using for the unit, usually is set using unitless values, which would make the we have on the elements work much better. Also, the font-size is set using for whatever reason (unlike most if not all other font styles I have seen in our CSS). Not that changing it to does anything (currently at least).

.fill-in-the-blank-wrap > p { margin: 0; <del> font-size: 1.25em; </del> <ins> font-size: 1.25rem; line-height: 1.5; </ins> } .fill-in-the-blank-input {


Question:
When the blanks in a fill in a blank challenge overlap vertically, the top selection box gets cut off: <img width="767" alt="Screenshot 2024-06-17 at 5 39 59 PM" src=""^ See the two blanks in the sentence are above and below one another. When you click the first blank, the blue selection box is cut off - presumably because the input below is in front of the first input. to on the first blank in the sentence the blank get cut off The box to be visible We could adjust the spacing so the input doesn't get cut off, or move the z-index of the input to the front when it's selected.
I think changing the z-index on select makes sense.
We might also consider increasing the . The lines are pretty close together. Not sure why we are using for the unit, usually is set using unitless values, which would make the we have on the elements work much better. Also, the font-size is set using for whatever reason (unlike most if not all other font styles I have seen in our CSS). Not that changing it to does anything (currently at least).

background-color: var(--primary-background); border-radius: 0; overflow-wrap: anywhere; <del> line-height: 1.5rem; </del> <ins> line-height: 1.5; </ins> z-index: 1; position: relative; border-left: none;


Question:
When the blanks in a fill in a blank challenge overlap vertically, the top selection box gets cut off: <img width="767" alt="Screenshot 2024-06-17 at 5 39 59 PM" src=""^ See the two blanks in the sentence are above and below one another. When you click the first blank, the blue selection box is cut off - presumably because the input below is in front of the first input. to on the first blank in the sentence the blank get cut off The box to be visible We could adjust the spacing so the input doesn't get cut off, or move the z-index of the input to the front when it's selected.
I think changing the z-index on select makes sense.
We might also consider increasing the . The lines are pretty close together. Not sure why we are using for the unit, usually is set using unitless values, which would make the we have on the elements work much better. Also, the font-size is set using for whatever reason (unlike most if not all other font styles I have seen in our CSS). Not that changing it to does anything (currently at least).

border-bottom-color: var(--gray-45) !important; } <ins> .fill-in-the-blank-input:focus { z-index: 2; } </ins> .code-tag code { font-size: 100%; z-index: 0;


Question:
Thanks for opening this issue. This looks like something that can be fixed by "first-time" code contributors to this repository. Here are the files that you should be looking at to work on a fix: Please make sure you read our , we prioritize contributors following the instructions in our guides. Join us in our or our if you need help contributing; our moderators will guide you through this. Sometimes we may get more than one pull request. We typically accept the most quality contribution followed by the one that is made first. Happy contributing.
I have fixed in my PR

To begin, we will discuss a particular type of tree, the binary tree. In fact, we will actually discuss a particular binary tree, a binary search tree. Let's describe what this means. While the tree data structure can have any number of branches at a single node, a binary tree can only have two branches for every node. Furthermore, a binary search tree is ordered with respect to the child subtrees, such that the value of each node in the left subtree is less than or equal to the value of the parent node, and the value of each node in the right subtree is greater than or equal to the value of the parent node. It's very helpful to visualize this relationship in order to understand it better:

  Now this ordered relationship is very easy to see. Note that every value to the left of 8, the root node, is less than 8, and every value to the right is greater than 8. Also notice that this relationship applies to each of the subtrees as well. For example, the first left child is a subtree. 3 is the parent node, and it has exactly two child nodes — by the rules governing binary search trees, we know without even looking that the left child of this node (and any of its children) will be less than 3, and the right child (and any of its children) will be greater than 3 (but also less than the structure's root value), and so on.


Question:
I followed Step 4 instructions. As I finished typing out the element, by habit I press + , and noticed that it accepted it, even though it shouldn't have as I was still missing the element It should have failed, as it's still missing the that Step 4 asked for ! Device: PC OS: Window 11 Version 23H2 Browser: Firefox 127.0.2 (64-bit) No response
This seem to also happen in other parts of the same course, such as Step 7 ! As you can see, it is missing its closing tag As well as Step 11 ! It's missing its closing tag yet the Step still validate it
Can you please open a new issue for the form element. I'm guessing the browser is auto closing it, and we don't have a regex test for it. It should result in a valid form element, because the browser will close it. However, the element technically does not have any "Tag omission" so it should have an end tag in the HTML (even if it gets to the DOM by the browser).
Done

# --description-- <del> Add a `title` and a `meta` element to the `head`. Give your project a title of `Registration Form`, and give a `charset` attribute with a value of `UTF-8` to your `meta` element. </del> <ins> Add a `title` and `meta` element inside the `head` element. Give your project a title of `Registration Form`, and add the `charset` attribute with a value of `utf-8` to your `meta` element. </ins> # --hints--


Question:
I followed Step 4 instructions. As I finished typing out the element, by habit I press + , and noticed that it accepted it, even though it shouldn't have as I was still missing the element It should have failed, as it's still missing the that Step 4 asked for ! Device: PC OS: Window 11 Version 23H2 Browser: Firefox 127.0.2 (64-bit) No response
This seem to also happen in other parts of the same course, such as Step 7 ! As you can see, it is missing its closing tag As well as Step 11 ! It's missing its closing tag yet the Step still validate it
Can you please open a new issue for the form element. I'm guessing the browser is auto closing it, and we don't have a regex test for it. It should result in a valid form element, because the browser will close it. However, the element technically does not have any "Tag omission" so it should have an end tag in the HTML (even if it gets to the DOM by the browser).
Done

assert.exists(title); ``` <del> The `title` element should be within the `head` element. </del> <ins> Your `title` element should be within the `head` element. </ins> ```js assert.exists(document.querySelector('head > title')); ``` <del> Your project should have a title of `Registration Form`. </del> <ins> Your project should have a title of `Registration Form`. Remember, the casing and spelling matters for the title. </ins> ```js const title = document.querySelector('title'); <del> assert.equal(title.text.toLowerCase(), 'registration form') </del> <ins> assert.equal(title.text, 'Registration Form'); </ins> ``` <del> Remember, the casing and spelling matters for the title. </del> <ins> You should create a `meta` element within the `head` element. </ins> ```js <del> const title = document.querySelector('title'); assert.equal(title.text, 'Registration Form'); </del> <ins> assert.exists(document.querySelector('head > meta')); ``` You should give the `meta` element a `charset` attribute with the value of `utf-8`. ```js assert.equal(document.querySelector('head > meta')?.getAttribute('charset')?.toLowerCase(), 'utf-8'); ``` Your `meta` element should be a void element, it does not have an end tag `</meta>`. ```js assert.notMatch(code, /</metas*>?/i); </ins> ``` # --seed--


Question:
The keyword should be wrapped in a pair of backticks.
This issue is open to first-time code contributors to this repository. The file that you should be updating is: We typically do not assign issues. Instead, we accept the most quality contribution followed by the one that is made first. Please make sure you read our as well as our , we prioritize contributors following the instructions in our guides. Join us in our or our if you need help contributing; our moderators will guide you through this. Happy contributing.
Hi! I'm a first timer and would love to contribute to this project and fix this typo. :)
Hey We typically do not assign issues. Instead, we accept the first pull request that comprehensively solves the issue. Issues labelled with or are open for contributions. Please make sure you read . We prioritize contributors following the instructions in our guide. Join us in or if you need help contributing - our community will be happy to assist you.
can i work on this issue if it still open

The <dfn>HSL</dfn> color model, or hue, saturation, and lightness, is another way to represent colors. <del> The CSS hsl function accepts 3 values: a number from 0 to 360 for hue, a percentage from 0 to 100 for saturation, and a percentage from 0 to 100 for lightness. </del> <ins> The CSS `hsl` function accepts 3 values: a number from 0 to 360 for hue, a percentage from 0 to 100 for saturation, and a percentage from 0 to 100 for lightness. </ins> If you imagine a color wheel, the hue red is at 0 degrees, green is at 120 degrees, and blue is at 240 degrees.


Question: in step 98 of the platformer game, there are a couple of small issues that can be fixed. 1- the check is too strict for spaces because it doesn't accept this code: Note the extra space between the word draw and the parenthesis. Without the extra space, the code is accepted. For the second issue, the wording used in the step "add a fillStyle property to the ctx object" is not what I would expect given that fillStyle is a property of the canvas object and not something we 'add' to it. I would suggest a rewrite to "set the fillStyle property of the ctx object" instead. As seen above. slight wording change needed and a looser check to allow a space between the word draw and the parenthesis. No response N/A No response

Now you need to create a `draw` method for the `CheckPoint` class. <del> Inside the `draw` method, add a `fillStyle` property to the `ctx` object and set it to `"#f1be32"`. </del> <ins> Inside the `draw` method, assign the `fillStyle` property on the `ctx` object the hex color `"#f1be32"`. </ins> Below the `fillStyle` property, use the `fillRect` method on the `ctx` object and pass in the `x`, `y`, `width`, and `height` properties as arguments.


Question: in step 98 of the platformer game, there are a couple of small issues that can be fixed. 1- the check is too strict for spaces because it doesn't accept this code: Note the extra space between the word draw and the parenthesis. Without the extra space, the code is accepted. For the second issue, the wording used in the step "add a fillStyle property to the ctx object" is not what I would expect given that fillStyle is a property of the canvas object and not something we 'add' to it. I would suggest a rewrite to "set the fillStyle property of the ctx object" instead. As seen above. slight wording change needed and a looser check to allow a space between the word draw and the parenthesis. No response N/A No response

Your `CheckPoint` class should have a `draw` method. ```js <del> const splitter = code.split("ctx.fillRect(this.position.x, this.position.y, this.width, this.height)") assert.match(splitter[2], /draw(s*)s*{/); </del> <ins> const splitter = code.split("ctx.fillRect(this.position.x, this.position.y, this.width, this.height)"); assert.match(splitter[2], /draws*(s*)s*{/); </ins> ``` <del> Your `draw` method should have a `fillStyle` property added to the `ctx` object. </del> <ins> Your `draw` method should assign a value to the `fillStyle` property on the `ctx` object. </ins> ```js <del> const splitter = code.split("ctx.fillRect(this.position.x, this.position.y, this.width, this.height)") assert.match(splitter[2], /draw(s*)s*{s*ctx.fillStyle/); </del> <ins> const splitter = code.split("ctx.fillRect(this.position.x, this.position.y, this.width, this.height)"); assert.match(splitter[2], /draws*(s*)s*{s*ctx.fillStyles*=/); </ins> ``` <del> You should assign `"#f1be32"` to the `ctx.fillStyle` property. </del> <ins> You should assign the hex color `"#f1be32"` to the `fillStyle` property on the `ctx` object. </ins> ```js <del> const splitter = code.split("ctx.fillRect(this.position.x, this.position.y, this.width, this.height)") assert.match(splitter[2], /draw(s*)s*{s*ctx.fillStyles*=s*('|")#f1be321s*;?/); </del> <ins> const splitter = code.split("ctx.fillRect(this.position.x, this.position.y, this.width, this.height)"); assert.match(splitter[2], /draws*(s*)s*{s*ctx.fillStyles*=s*('|")#f1be321s*;?/); </ins> ``` Your `draw` method should invoke the `fillRect` method on the `ctx` object. ```js <del> const splitter = code.split('#f1be32') </del> <ins> const splitter = code.split('#f1be32'); </ins> assert.match(splitter[1], /ctx.fillRect(/); ``` <del> When invoking `ctx.fillRect` you should pass in the `x`, `y`, `width`, and `height` properties as arguments. Don't forget the `this` keyword. </del> <ins> When invoking `ctx.fillRect` you should pass in the `position.x`, `position.y`, `width`, and `height` properties as arguments. Don't forget the `this` keyword. </ins> ```js <del> const splitter = code.split('#f1be32') </del> <ins> const splitter = code.split('#f1be32'); </ins> assert.match(splitter[1], /ctx.fillRect(s*this.position.xs*,s*this.position.ys*,s*this.widths*,s*this.heights*)s*;?/); ```


Question:
"an checkbox input" should be changed to "a checkbox input". Fix the typo in the following files:
This issue is open for contribution. The file that you should be updating is linked in the original post. We typically do not assign issues. Instead, we accept the most quality contribution followed by the one that is made first. Please make sure you read our as well as our , we prioritize contributors following the instructions in our guides. Join us in our or our if you need help contributing; our moderators will guide you through this. Happy contributing.

assert(document.querySelector("fieldset:nth-of-type(3) input:nth-of-type(5)[type='checkbox']")); ``` <del> You should have an checkbox input with an `id` of `"price"`. </del> <ins> You should have a checkbox input with an `id` of `"price"`. </ins> ```js assert.strictEqual(document.querySelectorAll("fieldset:nth-of-type(3) input[type='checkbox']")[4].getAttribute('id'), 'price');


Question:
"an checkbox input" should be changed to "a checkbox input". Fix the typo in the following files:
This issue is open for contribution. The file that you should be updating is linked in the original post. We typically do not assign issues. Instead, we accept the most quality contribution followed by the one that is made first. Please make sure you read our as well as our , we prioritize contributors following the instructions in our guides. Join us in our or our if you need help contributing; our moderators will guide you through this. Happy contributing.

# --description-- <del> To make an checkbox input checked by default, you can add the `checked` attribute. </del> <ins> To make a checkbox input checked by default, you can add the `checked` attribute. </ins> Here is an example of using the `checked` attribute: