Hello! I’ve just finished my product landing page project and was looking for some feedback on it. I used a little bit of JavaScript as well as the usual HTML and CSS.
One question I did have was - there’s a “Submit” button at the top of my page (under the first email input form). It’s supposed to be blue, but on my iPhone it looks grey. I don’t usually view my projects on my iPhone, but just so happen to be using it to post right now. Is this a normal iPhone thing or did I mess up somehow?
Other than that, I did my best to make my page responsive and pretty, so please do let me know what you think, and if there are any technical aspects I can improve on.
Very nice looking site, looks very professional keep up the good work.
Sometimes things will look a little different when in different browsers or like Safari on ios so its totally normal for your button to look different, you can use -webkit-appearance: none; in your button css and it should stop it from changing.
If it is only happening with the submit button for the top form and not the bottom form then I would suggest you try using a button element for the top form just as you are for the bottom form.
Can’t say why the button being an input element on iPhone would cause issues with the background color. I assume it’s in Safari? They might have some rules around setting background colors on input elements that are affecting your button.
I didn’t really pay attention to the fact that it was the product page challenge. I was just curious if the issue you were seeing was because it’s an input element or not?
To be honest, that requirement should be changed. It doesn’t make much sense to require that the submit button has to be an input element. I made a PR for it.
In that case, yes, it has to be because it’s an input element (since the other buttons aren’t having that issue and that’s the only button that is an input element).
I believe they have that in there because of the “form” aspect. I mean, they give you a link to put in the email input action and everything (user stories 8 - 12):
User Story #8: Within the form, there is an input field with id="email" where I can enter an email address.
User Story #9: The #email input field should have placeholder text to let the user know what the field is for.
User Story #10: The #email input field uses HTML5 validation to confirm that the entered text is an email address.
User Story #11: Within the form, there is a submit input with a corresponding id="submit" .
Wow, this looks really nice, especially some of the little touches that we don’t usually see in these projects. I do have a few accessibility enhancements for you to consider.
The keyboard focus indicator could be better, especially around the blue buttons. Firefox does a blue indicator by default so I basically can’t see the focus ring around the buttons when I Tab through them. I always suggest you customize the CSS outline property on the :focus psuedo-class so that the focus indicator stands our more and is styled for the page. This would include the <input>s too.
Your heading semantics are well organized. I don’t think the plans should fall under Frequently Asked Questions though, they should probably have their own <h2>. And the <h3> for each plan should probably be the name of the plan, not the price.
The accordion FAQ is not keyboard accessible. A click event handler on a <div> is not enough to make it work with the keyboard. You might consider using <details>/<summary> instead, which would automatically give you keyboard accessibility. Or you’ll want to follow an accessible pattern for disclosure widgets.
You should really have <label>s on your <input>s. Placeholder text is not considered an accessible replacement for labels.
I’m noticing the “Join Us” button at the top right disappears in a narrow view. I’m not sure what this button is intended to do, but if equivalent functionality isn’t provided elsewhere on the page in narrow view then you need to add it back in.
While in narrow view you have set the font size of the menu items only in vw units, which is not accessible because it won’t allow the user to manually increase the font size. I understand why you did this, but instead forcing a small font size for narrow views you should instead implement a way for the top menu to handle larger text size, such as converting to a hamburger menu.
Related to larger text sizes, I would recommend you not set height on elements that contain text, and especially not in px. The height should be able to grow naturally as the text size increases.
Yes, buttons work. It is one of their main purposes. The button element type attribute will default to be of type submit if no type (or an invalid type) is supplied (MDN: button attributes type). They have quite a few other form-related attributes as well.
Very nice. Well done. My first reaction is that your choice of colors (blue and turquoise) would be really fit for a travel site that is featuring tropical holidays. Otherwise, I find it hard to justify such exuberant colors, especially so in the case of a classic business such as retail, finance, etc. Just my ten cent worth.
