Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
#1870944: [Meta] Mobile friendly admin pages
Problem/Motivation
For Browser Resolution below 400px,
- Scroll appears.
- Header and footer area background not appears in scroll area.
- Textbox width extends causing scroll
- Primary Tabs get collapsed.
URL : user/login
user/register
user/password
Proposed resolution
To be determined.
Remaining tasks
To be determined.
Comment | File | Size | Author |
---|---|---|---|
#12 | stark_wide.png | 36.95 KB | echoz |
#12 | bartik_wide.png | 37.75 KB | echoz |
#10 | user-form-1879966-10.patch | 539 bytes | echoz |
#8 | login.png | 24.98 KB | hansrossel |
#2 | user-form-1879966-2.patch | 607 bytes | echoz |
Comments
Comment #1
Shyamala CreditAttribution: Shyamala commentedEdited title
+tags
Comment #2
echoz CreditAttribution: echoz commented#1192044: Convert Bartik's layout to mobile-first and responsive is closed/fixed and tabs were left to wrap, so I left them that way and the same for Stark. We could make them stack, more design decisions would have to be made for Bartik.
This patch addresses the text fields. I used a breakpoint to accommodate Stark's sidebar too.
Screenshots show no horizontal scrollbar at 320px width for Stark and Bartik.
Comment #3
rteijeiro CreditAttribution: rteijeiro commentedHi, tested the patch with Bartik and Stark and everything looks okay in Chrome, Firefox, Safari, Opera and also in iPhone.
I think this issue should be considered as RTBC ;)
Comment #4
webchickSo this definitely looks *light years* better. Thanks a ton.
I'm a little bit worried though about putting this in system.theme.css because I've been bludgeoned in the face a few times about putting assumptions in that file that themers then have to override (while swearing, usually ;)).
So I'd love to get one more +1 from someone who is aware of those issues and can validate that this is indeed the right place to be putting this code. It seems logical to me, since it fixes it in all themes, but just want to be safe.
Not sure how well this tag is followed, but trying it.
Comment #5
echoz CreditAttribution: echoz commentedI can agree with media queries being theme specific and separating this into Stark + Bartik. If I were writing it for Bartik, I would match their breakpoint of 460px (where the main menu changes) which didn't work for Stark which still has the sidebar when the form breaks.
Comment #6
jwilson3I solved the issue of the form inputs using simply
max-width: 100%;
on a recent project. Could that not work here, and in general, for all form elements, so they resize down properly, or is it too far reaching?To me, setting max-width globally (no media query) is less offensive than a) adding media queries that then also have to be added in the theme to override the style appropriately and b) setting form-text to 100% width, which will affect all inputs including the search form, that someone's mobile design may not want to specifically change to 100% wide on mobile by default. But, it would be good to get some other peoples input too.
Comment #7
echoz CreditAttribution: echoz commentedThis is following the UI used up to this point where form elements stack at 100% width on narrow viewports, I assume for a larger touch target. Also gives a consistent look where otherwise text inputs and textareas would be the width of their cols attribute when less than the viewport. I get your points, and agree it would be great to get input from where these UI decisions started.
Comment #8
hansrossel CreditAttribution: hansrossel commentedI checked in in Bartik and looks good to me. I also prefer the width:100% method + box-sizing as proposed in the patch, its a very common method for input fields where you have a combination of %width and padding in px. With max-width the width will not be always stretch the full width of the one column layout in mobile.
Comment #9
jwilson3I still feel this is overreaching CSS, and will have the effect that ALL text fields, even those designed to be specifically shorter than others for the purpose of a visual queue, such as date fields and zip-code fields will stretch to the full width. any input with a small size eg
<input name="pin" maxlength="4" size="4">
will be streched to the full width of the screen.There is also still the question of the arbitrary choice of 500 pixels, as opposed to 460 or some other number. The HTC Desire HD has a width of 533px in landscape mode. This document suggests using max-device-width:569px for smartphones.
Comment #10
echoz CreditAttribution: echoz commentedI'm now with @jwilson3. My point in #7 is following UI in admin (used in Seven) rather than the site theme. This patch puts max-width: 100%; on those form fields, at any width viewport. This will also keep the fields from breaking if in a narrow column. Still in system.theme.css.
Comment #11
echoz CreditAttribution: echoz commentedComment #12
echoz CreditAttribution: echoz commentedScreenshots in #2 are identical for viewports narrower than the form element's size attribute, here's screenshots for viewports wider than the form elements.
Comment #13
jwilson3Technically speaking, now that we've removed the width:100%, we don't need the box-sizing: border-box; anymore either, since that was used to ensure extra padding+border dont expand the 100% width element beyond the bounds of its containing element.
On the other hand, I think its generally a great idea to introduce box-sizing, but not just for these couple elements, but for all form elements. Maybe should be a separate issue, that can be tested on its own?
Comment #14
echoz CreditAttribution: echoz commented@jwilson3, when the viewport is less than the text field (mobile), the box-sizing does make a difference, since then it is being constrained to 100%. I have compared and without box-sizing: border-box; the text field pushes out into the margin.
Comment #15
jwilson3ah, ok. thanks for setting me straight and actually testing it out ;)
Comment #16
echoz CreditAttribution: echoz commentedYou're right! Over at #1880368: Form elements can break out of their bounding divs and whatnot there's a pending patch that puts the same css on the input element and does it in system.base.css. Let's get that one committed.
Comment #17
jwilson3Yeah! nice find there! Glad you found that before two things got committed that did the same thing. This is the risk with such atomic commits.
Comment #17.0
jwilson3Added link to meta issue