Excessive margin-top in Views live preview

Created on 22 May 2014, over 10 years ago
Updated 1 February 2023, over 1 year ago

Problem/Motivation

Excessive margin-top in Views live preview

Steps to reproduce

Proposed resolution

Remove the margin from the preview

Remove the media library specific margin removal in core/themes/claro/css/theme/media-library(.pcss).css as
removing the margins from previews overall would take care of this without the need for this targeted styling.

.views-live-preview .media-library-view div.views-row + div.views-row {
  margin-top: 0;
}

Remaining tasks

Review
Commit

User interface changes

Only for the views preview

πŸ“Œ Task
Status

Closed: works as designed

Version

10.1 ✨

Component
Views UIΒ  β†’

Last updated 9 days ago

Created by

Pancho UTC+2 πŸ‡ͺπŸ‡Ί EU

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΊπŸ‡ΈUnited States bnjmnm Ann Arbor, MI

    I'm also uncertain about the benefits of removing the margin, but I do see a benefit of keeping it there. Any view built for the public facing part of a site will likely look quite different in preview already, as it's using the admin theme instead of the default theme where it will be displayed. The additional margin provides a clear means of distinguishing between rows without having to introduce view-specific styling in the admin theme for a public facing view.

    I also think that while there are instances where the additional margin can look a little rough, removing it will potentially introduce other less than ideal results such as the one mentioned in #22. I'm leaning towards not doing this, but if there were multiple before/after screenshots of different use cases and view types demonstrating this results in a clear improvement without unwanted tradeoffs, I'd be more open to the addition.

  • πŸ‡ΊπŸ‡ΈUnited States bnjmnm Ann Arbor, MI
  • Status changed to Closed: works as designed over 1 year ago
  • πŸ‡³πŸ‡±Netherlands Lendude Amsterdam

    Let's close this then. I'm certainly not bothered by the margin and if people see a benefit of it, great, let's keep it in. There are way too many permutations of possible views to really ever say there will be no unwanted trade offs, I think, so might as well stick with the trade off we have now.

    We could go back to the solution in #2 but trying to target view modes sounds very bothersome, since these can just be created and then you'd have a difference in margin when flipping between different view modes if some are supported by the selector and some aren't, which also sounds less than ideal.

    Since the preview is more about previewing your result set and not previewing how it's going to look, I'd opt not to spend too much time on this and just leave this as it is, until something like #2684509: [meta] Implement a preview-first Views UI with current functionality β†’ lands.

Production build 0.71.5 2024