-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Review use of bullet points / styling in contact form #1276
Comments
I'm not sure the form even needs to be rendered as part of the list (#1208 (comment)). |
I'm not sure why we do it like that - perhaps it was for styling (it's been like that since d8df394). If we move the form out of the list, you do gain a slight nuisance, in that the container renders directly off the left-hand side, whereas we'd previously had it in-line with the list elements. I'm agnostic as to which is better, but I do have a slight preference for keeping positioning as it were - as this allows for a logical "flow" and for the user to focus on things in a straight line - e.g. read the list and then the form is neatly rendered for them in the place they expect it to be. |
Yeah nor me and haven't / likely won't have time to really dig in to.
Agreed for same reasoning. Open to contributions on this but unlikely we'll actively look at it until the next time we happen to work on the contact form. |
…tured list. Add similar structure to generic contact form render. Fixes mysociety#1276
I'll stick a PR in with the kludge I'd proposed - I'm sure there's a better solution, but it's so trivial that it doesn't really seem worth pondering much more. |
When the various contact forms on /help/contact are rendered, we are rendering the headline text in bullet points, and then rendering the form itself in another bullet point.
Why is it an issue?
Rendering a bullet point next to the form looks a little peculiar, and slightly less polished than our UX usually is. This is probably nitpicking, and it might purely be an aesthetic complaint, rather than broken functionality.
Possible solution
We already have a css selector which will remove visible bullet points from unstructured lists, but applying this this also removes the padding on the left margin, which makes the form slightly less logical in appearance.
Suggested fix
This is a relatively obscure usage, so if adding to the core stylesheet is deemed to be overkill, a hack would be to apply styling at a local level (e.g.
<li style="list-style-type:none;">
). This would, perhaps, only need to be applied to the list item containing the form itself - so as not to remove the visible bullet from areas where we might wish to retain it.Example:
This isn't necessarily a perfect solution, so I'll open the floor to the design gurus who might have a better idea than me.
The text was updated successfully, but these errors were encountered: