Improve visibility of Views UI's smallest font elements

The text sizes smaller than 1em(13px) are:

• dropdown buttons
• settings text on Views display screen
• progress indicator (found this one in the css but doe not know how to test it)

see attached screenshots

created patch

good point @njbarrett

Steps to test text size views progress indicator(see also attached screenshots):

1. open a view
2. add multiple fields, by selecting more than one filed in the add field dialog.
3. See the progress indicator in the upper right corner(in seven)

the dropbutton font size is wrong: i'm going to fix it

@soulsesa is patch #3 not working for you?

@njbarrett OK, i'm on it.

This is an updated patch.

Changing .views-ui-display-tab-bucket .views-display-setting and .views-ui-display-tab-actions .dropbutton-wrapper li a,
.views-ui-display-tab-actions .dropbutton-wrapper input font-size from 12px to 1em.

@njbarrett I don't see why we need to change padding on the button, I think the style is already inline with guideline wich you send…

@njbarrett you are right, the buttons break out, that is probably why the font was set in such a small size in the first place. When looking at other places in core where these buttons are used, you see much more white space around the button. The views admin screen is very dens with settings and buttons, as it is. I enhanced the row height of the settings row and enhanced the padding of the button.

The buttons seem very big now, this might be another issue, since the size of the button now meets the default button size.

Change status to Needs review to run testbot.

This needs to be postponed after #2408525: Rewrite Views UI CSS inline with our CSS standards - Part 1 and this will need to be crosslinked with one of its follow-up issues. (Otherwise this will mean a big manual re-refactoring of views-ui)

Leaving on Needs Review for now, so this can be finetuned.

After some discussion, we decided that we would love to use the default-buttons and remove the CSS from inside the views_ui module so the default classes won't get overridden. We should also make sure that the larger buttons get a tiny bit more spacing.

This is following the logic, a module shouldn't re-define the styles for buttons. As a analogy: /admin/config/media/image-styles/manage/large is using the same buttons (with no extra styling I think)

Ok so now I removed the font-size: 1em entries from all the views_ui styling. Nothing changes as expected, see attached screenshot.

Yes, it should still be postponed after that ticket, because there is a huge refactoring going on there. Re-implementing this ticket instead of that ticket is way more logical.

Open TODO's for this ticket are now: (After a long discussion with a entire frontend-sprintroom)
Make sure Views doesn't have smaller buttons than all the other modules. and style them in a way don't overlap on any titles.

Ok, that's in now, so let's get on with fixing this.

Ok, here's a re-roll.

Worth noting that I nixed

-.js .views-edit-view .dropbutton-wrapper .dropbutton .dropbutton-action > * {

but but the patch in #21 didn't have .views-edit-view and was just:
-.js .dropbutton-wrapper .dropbutton .dropbutton-action > * {

I also assumed that
.view-preview-form .arguments-preview {

was a rehashed version of this fragment from #21:
#views-ui-preview-form .arguments-preview {

This looks good to me, font size is now 13px on views dropdowns and labels, etc.

Marking RTBC.

I notice that the description on the preview pane is 09.em, but I'll open a new ticket for that.
edit - that other issue is fixed here: https://www.drupal.org/files/issues/improve_visibility_of-2045473-104.patch

Can we get a few proper before/after screenshots to review?

Here's a before and after set of screenshots of a section of the views page.

Ok, so we should be good to go back to RTBC now since we have the screenshots.

This is looking good!

I think this should be small dropbuttons? Instead of the big ones - it kind of screws up the alignment. See https://groups.drupal.org/node/283223#Small_Controls

As far as I know these smaller buttons are not yet implemented in Drupal, We tried to use them for this issue back. Creating the smaller drop down button seems to me like a separate (new) issue.

Nope, than we need to implement that first. We should not degrade the UI this late in the game.

@Bojhan: Does an issue exist for the smaller buttons? Should we create a seperate issue and postpone this one?

Also seeing another issue at some screen widths (see image). This appears to be due to the button/dropdown being positioned absolutely, and subsequently text flowing underneath it. I did some styling tests locally, but, of course, there are edge cases where this can break.

Hi,

I'm on DrupalCon Vienna and working on this.

This patch is extending the #29 patch. We had to also apply the same changes to stable in order to work.

Sorry, on #47 we switched the interdiff with the patch. Please consider these files instead.

I'm not sure this is helpful, but we ran into the same problem with the Views UI in Backdrop CMS. We have two possible fixes in mind:
1) We thought to change the Views UI to a two column layout instead of keeping it at 3 columns on smaller screen sizes
2) we thought we could change the positioning of drop-buttons in the Views UI to float right instead of using position: absolute, though that will require some reworking of the markup to get the buttons in the right place on the page.

Current work on this issue is going on here

Patch #48 failed to apply on 9.2.x.
Re-rolled the patch.

Attached screenshot for reference.
Review the patch.

Applied patch #58.The patch is working fine for desktop.But it is showing some issues in mobile.Adding screenshots after applying this patch.

Desktop:

Mobile:

Updated patch.

#61 patch applied. The patch is working fine for mobile please refer the screenshot.

Test case are green. Moving to Need review.

When I was patch # 61, I saw that when the view name is big, it is over the action button on the mobile. And the display name is also not being displayed.

Shouldn't this be corrected?

I couldn't insert the image in the text, I'm sending it now

overlapping of view name have fixed

Fixed custom command issue of patch #68.

Before Patch

After Patch

#70 Created patch Please verify it

Fixed custom command fail

#73 patch applied. The patch is working fine

Verified and tested patch #74.
Patch applied successfully and it's working perfectly on iPad only.
UI is breaking on Mobile devices.

Testing Steps:
# Goto: admin/structure/views/view/comment
# User is able to see buttons are overlapping on text and UI looks like broken on Mobile devices.

Expected Results:
# User should not see broken UI.
# User should not see buttons are overlapping on text.

Actual Results:
# User is able to see buttons are overlapping on text and UI looks like broken on Mobile devices

Please Fix the above issue on Mobile devices and check comment #59 also.
can be move to Needs work

patch #73 applied successfully it shows working fine on "9.3.x-dev".

Resolve #74 command fail.

Applied #73 patch in drupal-9.3.x-dev
Applied successfully and looks good for me
for ref sharing screenshot ...

Applied patch #73. But some labels are still overlapping.

Attached reroll patch against as per #84 title overlap issue on mobile.
For ref sharing screenshots...

Applied patch from #86 and attached a screenshot of what I see on the content view using claro theme.

Tested with and without the patch, clearing cache in betwee, and nothing changed.

@smustgrave This issue is on Seven Theme. Please check.

Applied patch in #86 successfully.. Adding results as screenshots..

So if this fix is targeting just the seven theme why is it going into the core views module?

targeting a single specific theme doesn't sounds correct to me.

The Seven theme has been removed from Drupal 10 core. However, this issue appears to apply to the Core Views Module no matter which theme is used.

Last patch #86 passed on 10.1.x and they are not targeting a specific theme.
Anyone, please review the patch.

Claro has overrides for this, which make the sizing dynamic, so the only way to see this is probably in Stark.

This isn't a WCAG SC, but still a good practice for readability.

I have updated the fonts as per reference of Claro. Font size is still small in stable theme. Added after patch screenshot

Before patch

After patch

Can the issue summary be updated with the proposed solution.

Would be nice if new screenshots from 97 can be added too.