Change:
assert(code.match(/htmls*>/gi)); ``` <del> Your `html` element should be below the `DOCTYPE` declaration. </del> <ins> Your `DOCTYPE` declaration should be at the beginning of your HTML. </ins> ```js <del> assert(code.match(/(?<!<htmls*>)<!DOCTYPEs+htmls*>/gi)); </del> <ins> assert(__helpers.removeHtmlComments(code).match(/^s*<!DOCTYPEs+htmls*>/i)); </ins> ``` Your `html` element should have an opening tag.

Discussion:
Several. One example is The hint for this step seems to indicate that the user must add the element below the (there must be at least one new line separating them). Hint: "Your element should be below the declaration.:" So the expected behavior would be that the user will not pass this step until they add the element below the . <!-- Please complete the following information. --- Device: Desktop OS: Linux/Fedora 34 Browser: Firefox Version: [e.g. 22] This is happening for several courses. The regex used for this test is not enforcing the newline between the elements. If this requirement is important enough to be enforced then we should probably come up with one regex that enforces this requirement and use it for all courses.
One possible regex I am using as a solution for this is:
Affected pages: : js 57 assert((/^s<!DOCTYPEs+htmls[sS]<shtmls/gi)); 58 : js 55 assert((/(?&lt;!&lt;htmls)&lt;!DOCTYPEs+htmls/gi)); 56 : js 53 assert((/(?<!<htmls)<!DOCTYPEs+htmls/gi)); 54 : js 55 assert((/(?&lt;!&lt;htmls)&lt;!DOCTYPEs+htmls/gi)); 56 : js 17 assert((/(?<!<htmls)<!DOCTYPEs+htmls/gi)); 18 : js 17 assert((/(?&lt;!&lt;htmls)&lt;!DOCTYPEs+htmls/gi)); 18 : js 41 assert((/(?<!<htmls)<!DOCTYPEs+htmls/gi)); 42 : js 53 assert((/(?&lt;!&lt;htmls)&lt;!DOCTYPEs+htmls*/gi)); 54
If the regex from is the way we want to go, I'd be happy to start working on it in the pages linked by .
I was eventually going to get around to updating these but please, feel free to step in. My solution above was officially merged into main so I'm assuming that's acceptable to use for these as well.
I'm beginning to wonder if we should even have a requirement that the DOCTYPE be on its own separate line?

I can't seem to find any documentation that says this is required and the W3C HTML validator accepts it without being on a new line. Also, we don't seem to be enforcing separate lines for other types of tags. But the DOCTYPE does need to be the first element on the page, which I don't think we are currently testing for, so I propose we test for that instead and get rid of the separate line requirement.
As far as the tests go, I suggest we stick with this: If the HTML spec can parse it, it is valid, and should be accepted, unless the instructions specifically say, for example, "add a semi-colon at the end of the value" So, as I can see in the spec, there is no requirement for the DOCTYPE and the element to be on separate lines:
Would you agree with me then that instead of testing for DOCTYPE being on a separate line we should be testing that the DOCTYPE is the first element on the page? This brings us back to another I found in which there are JS comments in the code string before the HTML begins: Not impossible to work around, just wanted to make whoever ultimately works on this aware of it.
It wouldnt surprise me if that's the why the test was written that way, because if doctype isnt the first element, how else would you check it's current placement? It would be in relation to the html tag, right?
Ideally, yes. As I mentioned below, we do have a solution to the comment thing, but it is a work-in-progress.
I have submitted a that fixes the source of this issue (css comments before the html in the code string) which if approved will allow us to easily test that the DOCTYPE declaration is the first element in the HTML.
should i close my initial pull request since you said in your pull request that you were going to fix the others once yours gets approved and merged? I dont mind helping update the other docs with the new test once it's approved if you want me to. either way, just let me know !
We've had a couple of reports in the support inbox that the negative lookbehind used in some of these tests is failing in Safari, so it's great that either or (pending update) will take care of that as well. At the moment seems more flexible, and allows valid code to pass without forcing a particular style.

It'll also be good to move away from regex for this type of test.
If __helpers.removeHtmlComments(code) is preferred, we could modify in that direction or accept alternatively.
Yes, is the final PR to put this issue to rest. I did an initial PR for just one course and it has already been merged. is using the same solution, just updating the remaining courses that need it.