Form items should be wider on narrow screen sizes

How wide, and for what viewport range?

The simplest solution would just have go with width: 100% for all input[type=text] etc. below a certain viewport size, but there is a reasonable use case for letting form elements retain their HTML-specificed width, eg. numeric fields that have specific length requirements spanning 100% of a div might break the visual indication for length.

I've used some of Lewis's styles from Seven with the addition of min-heights on the form elements. Screenshots below:

The attached patch applies larger form element styles to the Login, Registration, and Password Reset forms for device widths below the Bartik mobile breakpoint.

#5: bartik-mobile-form-styles-1955268-5.patch queued for re-testing.

Bartik is using unecessary qualified selectors, so besides in need of a cleanup, the ID selectors needed here raise the specificity enough to not need qualifying with the input element, and for the button, we also have a single class to target.

Thanks echoz! Also, aren't we removing vendor prefixes per #1422614: Drop Firefox 3.6 support in Drupal core? I think both the -moz and -webkit prefixes should go, so a new patch is attached. Also, I reordered the properties to group all the box-model ones together.

On vendor prefixes, I just submitted #2005520: Remove remaining prefixed border-radius and box-shadow from core but not dropping them for box-sizing.
http://caniuse.com/css3-boxsizing

OK I'll take another pass at this to address both those comments.

Okay, took a stab at this since BrightBold hasn't touched it in a while. :)

• Added -moz -box-sizing property.
• Email fields are consistently styled with username and password fields now.
• Put a little bit of vertical padding on the 'create account' and 'request password' links, as per LewisNyman's suggestion.

Looks good. This is the first time afaik that we are omitting the webkit prefix with box-sizing, and that seems ok. http://caniuse.com/#feat=css3-boxsizing

Thanks Lewis, blank line deleted.

Why only the user login form?

Apologies for failing to follow up with this. Thanks @eatings!

+++ b/core/themes/bartik/css/style.css
@@ -1777,6 +1777,34 @@ div.admin-panel .description {
+  #user-login-form .form-text,
+  #user-register-form .form-text,
+  #user-register-form .form-email,
+  #user-pass .form-text {

Hm. How will this work with a module that adds extra text-ish fields (e.g. tel) to these forms via hook_form_alter()? Is there any way of making these selectors more general?

Regarding #2, does CSS have some way to write a rule that's like:

"Do 100% width on all form elements, unless they specify a size attribute"

...because if so, I think that'd address the problem.

Feel free to mark back to RTBC once these questions are addressed.

#16 working fine for the theme .

Back to needs review, because I don't know what Lewis's "hm" means. :) Does that mean we should adjust the patch here to add them?

I also am really concerned about how brittle this is due to the specificity. Can we get a cross-link here to the issue to add a way to style form elements consistently and probably add a @todo and/or postponed on that?

This seemed to need a quick reroll, so here's an updated patch for starters...

Seems like a reasonable approach, although the more generic targeting of form elements has not been addressed (but perhaps it doesn't need to be).

Knocking this back to Needs Work.
A patch with new work needs to be created based of the updated issue summary and what was discussed in #29.

Patch submitted. Narrow viewport image attached.

Thanks @mherchel, this is certainly a move in the right direction!

1. +++ b/core/themes/bartik/css/components/form.css
   @@ -102,6 +102,29 @@ select.form-select {
   +  input.form-submit {
   +    float: none;
   

   input.form-submit has no float by default, so this attribute can be removed.

2. The approach is very similar to Seven, but Bartik has more styling for common UI elements, for example the search form in the header. Let's make sure this styling at least looks decent. This is a before/after screencap for a search form in the header:

   

We also need to make sure we are not distorting the buttons and links too much.

The button needs to keep the round corners and the dotted underline needs to stay close to the text.
 

Nice catch, is this the only form element we should be looking at. What about the content creation page, people have that in bartik all the time.

Hey Everyone,

I tested the block forms(i.e login block, custom form block) after applying the patch.

Here are my 2cents on this:
1. This patch fixed the user login block theming.
2. This patch distorted the custom form block which was created for the testing purpose.

This patch should be changed so that it works site wide and we should not only focus to the login blocks.

Please add if you feel I missed on something. Hoping that my comment helps.

Thank You

Reviewed the patch 1955268-wider-form-fields-mobile-34.patch mentioned in #43.
Steps for Testing:
1. Navigate to Login page and verify the page on Mobile device.
2. Verify the font sizes.
3. Apply the patch.
4. Repeat steps 1 and 2.

Font sizes are not consistent across Login, Create new Account and Reset Password pages and also varies across iPhone5, iPhone6 and Nexus10. Screenshots are attached for reference.

Hmm @swati_qa I'm a bit confused you said it's not consistent then set to RTBC? Can you explain your reasoning more?

@wafer can you please explain your approach? Also there is a white space error introduced, there needs to be a blank line at the end of the file per https://www.drupal.org/coding-standards#indenting.

Sorry, got confused with status, it should be "Needs Work", Thanks for updating.

@swati_qa no worries thanks for clarifying :)

i fixed patch but found more issues with it. Search form broken and checkbox goes 100% width

1) fixed checkboxes using :not() http://caniuse.com/#search=%3Anot
2) pretty crazy fix for search form:) i'm not sure hot exactly it should look

1) fixed checkboxes using :not() http://caniuse.com/#search=%3Anot
2) pretty crazy fix for search form:) i'm not sure hot exactly it should look

@finnsky: I tried to apply the patches mentioned in #50 and #51, but both these failed to apply.
Please see the attached screenshots for reference.

@swati_qa I can't reproduce that, for me it applies to 8.0.x, 8.1.x, and 8.2.x. Perhaps your branch is out of date.

I have verified patch :1955268-51.patch on multiple devices like Iphone5, Iphone 6, Iphone 6s, Nexus7, Ipad, HTC- One X etc and still there are issues exist. Please find the attachments for sake reference.

Thanks
Jaspreet singh

I checked all bugs from #56 and fixed issue with too wide selectboxes on small screens. Now should be ok on all devices (check screens before&after). About another bugs - i guess here is an issue, that related to specific devices. We have mobile styles, that was added in #51 by @finnsky for the width of screen less than 400px, but all tablets and in particular iphone 6s (i have this device and had tested this issue from my phone) has screens more than 400px. That's why we can't see mobile styles on those devices. But on iphone5 (1st bug) - no questions. I can reproduce it on iphone 5, anyway 1st bug is fixed.

So the question now is about what exactly breakpoint we need to use? For now it's 400px as i said, but better to increase it a bit, what do you think? Or any ways?

before

after

@kostyashupenko, I am getting error while applying your patch : form_items_should_be-1955268-57.patch.
For sake reference, please find the attachment.

Thanks
Jaspreet singh

@jaspreetsingh31, please re-test it. On my side all is ok. Use 8.0.x branch

@kostyashupenko, I am sorry to say but i am still getting error while applying patch.
Please have a look to the screenshot.

Thanks

Tried to apply patch form_items_should_be-1955268-57.patch as mentioned in #57.
Patch failed to apply for me too.
Please refer screenshot.

Able to apply the patch successfully and tested the scroll bar and drop-down issue in iPhone 5 ,iPhone 5s , iPhone 6 ,iPhone 6 Plus and Nexus 5X. Attached the screen print for the reference. The issue is tested and its fixed.However found that when the device is turned form vertical view to Horizontal view after changing the value in drop-down, the layout breaks ( Issue_Horizontal_view.png).

looks good now. issue resolved.

Thanks. Based on #57 and looking at the intent of the issue summary, most current devices have screens larger than 400px wide so to me it doesn't make sense to limit this better UX to <400px.

Based on a quick test it looks like Seven uses ~600px as the cut-off for full-width form elements, and that seems reasonable to me.

The full-width search button looks a bit funny to me, that's probably something I'd like @emma.maria's opinion on.

it is a good approach to make use of dimensions breakpoints to display mobile styles, but it would be better if you combine it with orientation breakpoints (orientation: portrait ) and (max-width: 600) seems like a good combination.

@Cottser, i've checked too seven theme and there is 600px breakpoint. So i've changed breakpoint for bartik from 400 to 600px too.

new 600px breakpoint

About fullscreen search button - waiting for the offer

Sorry, wrong patch and interdiff in #69. Re-added new

I will be working on this during the sprint.

About fullscreen search button - waiting for the offer

Not sure what "waiting for the offer" means. I confirmed this works in 8.1.x, however it does not work in 8.2.x. See screenshot.

Also noticed that on the iPad the search box and button are not full screen on 8.1.x. This may be more subjective, but related to the original issue. Is this a common practice on tablets? Regardless, it looks a bit strange to have the search box not lining up with the other text fields.

Thanks for working on this during the sprint @shaune.

I'm adding a related issue to the search input. #2207717: Add a search/input group component

Tested on 8.8.5, the issue with the search field and search button still exists. A similar issue can be reproducible on 9.1.x.

Also, I tried to apply the patch given in #70 but it's failing for 8.8.5.

I have added an updated screenshot of the current state to the IS but also tagging for issue summary update, as it needs more clarity around what is being proposed and how to achieve it.

Removing the screenshot and testing tags as that won't be needed until there is an actionable plan and a patch.

Tested on 8.8.5, the issue with the search field and search button still exists. A similar issue can be reproducible on 9.1.x. - Done.

Review the patch attached screenshot for the reference.

Hi komalkolekar,

Patch is applied successfully, Thank for give valuable time.

Thanks for the patch!

The issue summary needs an update to explain the approach behind the changes. It’s also not clear that the CSS has been reviewed, as the RTBC comment just says the patch applies, but there’s more to it than that.

Once the summary is updated the tag can be removed and set this back to needs review for a check of the CSS.

I applied patch #90 and rerolled the patch with screen shorts.
So we can change the status of the issue.

Please review the patch and share feedback.

Thanks!

Patch #98 Applied successfully on Drupal 9.4.x and form-Items also looks larger in the UI.

Before patch:

After Patch:

Applied the patch #98 in the drupal version 9.5 successfully and its working fine.
Refer to screenshot.
Thank you

Patch is applied successfully and working good LGTM so moving to RTBC

Moving to contrib since this is specific to Bartik, which has been removed from core in D10.