#1870944: [Meta] Mobile friendly admin pages

Problem/Motivation

For Browser Resolution below 400px,

  1. Scroll appears.
  2. Header and footer area background not appears in scroll area.
  3. Textbox width extends causing scroll
  4. Primary Tabs get collapsed.

URL : user/login
user/register
user/password

Proposed resolution

To be determined.

Remaining tasks

To be determined.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Shyamala’s picture

Title: Page Get Collapsed in small screens » User login, register, forgot password in NARROW Screens
Category: bug » task
Issue tags: +Usability, +mobile, +Responsive Design, +d8mux, +d8mux-admin

Edited title
+tags

echoz’s picture

Status: Active » Needs review
FileSize
34.47 KB
34.77 KB
49.44 KB
33.07 KB
31.21 KB
45.96 KB
607 bytes

#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.

rteijeiro’s picture

Status: Needs review » Reviewed & tested by the community

Hi, 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 ;)

webchick’s picture

Status: Reviewed & tested by the community » Needs review
Issue tags: +Needs themer review

So 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.

echoz’s picture

Issue tags: +Bartik

I 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.

jwilson3’s picture

I 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.

echoz’s picture

This 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.

hansrossel’s picture

FileSize
24.98 KB

I 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.

jwilson3’s picture

I 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.

echoz’s picture

FileSize
539 bytes

I'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.

echoz’s picture

Title: User login, register, forgot password in NARROW Screens » User login, register, forgot password in viewport or column
echoz’s picture

FileSize
37.75 KB
36.95 KB

Screenshots in #2 are identical for viewports narrower than the form element's size attribute, here's screenshots for viewports wider than the form elements.

jwilson3’s picture

Technically 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?

echoz’s picture

@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.

jwilson3’s picture

ah, ok. thanks for setting me straight and actually testing it out ;)

echoz’s picture

Status: Needs review » Closed (duplicate)

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?

You'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.

jwilson3’s picture

Yeah! 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.

jwilson3’s picture

Issue summary: View changes

Added link to meta issue