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.
Problem/Motivation
Step to reproduce:
1. Go to /admin/structure/views
2. See on the DISPLAYS column.
Proposed resolution
It seems this is due to this rule
ul {
margin: 0.25em 0 0.25em 1.5em;
}
If you change to
ul {
margin: 0.24em 0 0.24em 1.5em;
}
That all works elegantly on all the width screens I've seen. Although I do not know why.
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#3 | 2943448-3-D8.patch | 440 bytes | mohit1604 |
views-list-1_pixel-shift.png | 19.77 KB | Anonymous (not verified) |
Comments
Comment #1
Anonymous (not verified) CreditAttribution: Anonymous commentedvaplas created an issue. See original summary.
Comment #2
mohit1604 CreditAttribution: mohit1604 at Google Summer of Code commentedComment #3
mohit1604 CreditAttribution: mohit1604 at Google Summer of Code commented@vaplas, Thanks for the issue. Uploading required patch, please review it :)
Comment #4
Anonymous (not verified) CreditAttribution: Anonymous commented@Mohit Malik, thanks for super quick help with it! After the #3 patch, it seems like everything look good. So, RTBC.
I also tried to find some regression after patch, because this css rule is too broad and affects all ul in seven theme. But did not find it. Although this does not mean that the regression did not occur :)
Perhaps more experienced developers will be asked about more specific rule, like
td.views-ui-view-displays ul
to ensure that nothing degrades, maybe not.Also I want to pay attention that in other cases, we using wrapper 'item-list' (with margin:0). Example:
But it is not appropriate here, because it violates the design.
Comment #5
alexpottGiven that we already have CSS targeting this td directly i.e.
.views-ui-view-displays ul
in views_ui.admin.theme.css we should do that in Seven's CSS rather than making a more risky change. We can just do:Not entirely sure of where best to add this - I'll ping a frontend maintainer.
Comment #6
joelpittetI tried this in the latest Firefox and Chrome and can't reproduce the bug.
The only way I could see something like that was Chrome and I had the zoom up at 110%, can you confirm your zoom is at 100%? Firefox zoom didn't break this line.
Comment #7
Anonymous (not verified) CreditAttribution: Anonymous commentedWithout problem:
FireFox (58.0.1)
Chromium (49.0.2623.110)
Edge (38.14393.0.0)
Safari (5.1.7)
With problem (it seems they have one WebKit engine):
Chrome (64.0.3282.167)
Yandex.Browser (18.1.1.839)
Opera (51.0.2830.26)
In these browsers I have a persistent problem with "1 pixel shift" with zoom 100%. If I start to change the zoom, it disappears (but after the page refreshes it appears again).
It looks like a bug of the browser (or WebKit engine series).
In problem browsers:
In correct browsers:
Comment #8
joelpittetMuch of this comes down to how the drop-buttons are made with the position absolute and min-height combo.
It may be worth redoing the markup and CSS for the dropbuttons in general but this fix just masks a browser issue.
Let me know if you'd be interested in reworking the dropbuttons and we can create a more focused issue for that.