Along with some of the relative paths needing a fix, there's a typo in the favicon which will cause it to fail to load. - <img src="assets//images/icon-star.svg" alt="star icon" />
- two /
in a row in the path, which will be interpreted as "assets/". The dev console (Ctrl/Cmd + Shift + i or F12) should mention this if you load the page in it.
I don't know if any self-closing elements still require the trailing />
nowadays, and I don't know if they ever were required on some of these elements. Self-closing are when the tag and all it's data are contained entirely between the opening and closing brackets <...>
.
The CSS and JS file are fine in the root folder alongside the HTML file in small projects. If you're more comfortable having them split off though, that won't hurt anybody.
An h1
tag is required for accessibility purposes. If you scroll to the bottom of your solution on FM it should have an element showing an accessibility report that mentions this. There's also a HTML report if you hit the button to switch between the two tabs.
While div does work great in so many situations, HTML is more readable in general for developers with more use of semantic markup. Like heading, paragraph, button, etc, along with class names which can help identify the content and the containing element at once.
Media queries only apply when the rule is met, so currently it's only effective on screens that are 320-800px wide (>= 320 and <= 800). Since the media query seems to be mobile-only it would be best to make it only run on either 799 or 800px or less, like @media screen and (width < 800px)
for 799, or <= 800
for 800. This way it will still take effect on screens less than 320px wide, which must be tiny older smartphones and flip phones because it's pretty small.
That JS is beautiful; nice work! Minimal code to accomplish the goal and very easily understandable. Could use some whitespace for formatting between const declaration and loop and then between the two functions, but that's a nitpick (doesn't really matter, more personal preference than industry standards).
A lint tool should be able to automate checking for many of the above issues. In an IDE it may be built-in to the app, or available as an extension, and there are of course a ton of tools for this which run in NodeJS and many other languages. I'm using VSCode and the HTML linter seems to be included, but not CSS or JS. CSS I'm trying Stylelint currently, but I'd be just as willing to try the other popular options. For JS I have used StandardJS for years now, but ESLint is another great option - so much so that Standard uses it behind the scenes, lol.