- πΊπΈ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.
- Status changed to Closed: works as designed
over 1 year ago 7:45am 1 February 2023 - π³π±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.