u-hide utilities' breakpoints deviate from expected screen size values

[pastelcyborg]

Describe the bug

At exactly between 1035px and 1036px (inclusive), there's a clash between u-hide and the grid definitions as a result of these lines:

https://github.com/canonical/vanilla-framework/blob/main/scss/_utilities_hide.scss#L30

https://github.com/canonical/vanilla-framework/blob/main/scss/_base_grid-definitions.scss#L62

This means the medium hidden hr element becomes visible for a tiny slice before the large grid styles kick in.

Though grid is used to explain this issue, it is likely that the values used for the u-hide utilities are causing similar clashes with other responsive components in the library.

The solution is probably to change u-hide breakpoints, which would alter u-hide functionality across the entire library. Our components and examples that use u-hide utilities will need to be assessed for issues as a result of this change.

Expected behavior

u-hide utilities should possess the same responsive breakpoints as all other components, so elements utilizing these classes are shown/hidden as expected and in alignment with other components' breakpoints.

Screenshots

Here's a screenshot of this occurring on the Equal Height Row component - the divider is shown at 1035.72px, mistakenly being displayed right before the grid changes layout at 1036px:

[syncronize-issues-to-jira]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/WD-14040.

This message was autogenerated

[bartaz]

How to reproduce it? How can I get fraction of pixel width to test it?

[bartaz]

Overall I think the fix for that would be switching to range queries for utilities.

What's causing the issue right now is the max-width: $breakpoint-something - 1. Because that's what creates this 1px gap that may trigger when the device (and operating system) allow fractions of screen size.

vanilla-framework/scss/_utilities_hide.scss

Lines 20 to 40 in 6c5c7ce

	.u-hide {
	display: none !important;
	&--small {
	@media (max-width: $breakpoint-small - 1) {
	display: none !important;
	}
	}
	&--medium {
	@media (min-width: $breakpoint-small) and (max-width: $breakpoint-large - 1) {
	display: none !important;
	}
	}
	&--large {
	@media (min-width: $breakpoint-large) {
	display: none !important;
	}
	}
	}

To fix that we need to replace those with $breakpoint-x <= width < $breakpoint-y.

 .u-hide { 
   display: none !important; 
  
   &--small { 
     @media (width < $breakpoint-small) { 
       display: none !important; 
     } 
   } 
  
   &--medium { 
     @media ($breakpoint-small <= width < $breakpoint-large) { 
       display: none !important; 
     } 
   } 
  
   &--large { 
     @media ($breakpoint-large <= width) { 
       display: none !important; 
     } 
   } 
 } 

This probably applies to ALL utilities that use responsive variants.

It's probably OK to leave grid as is, because grid doesn't use exclusive ranges (min-width and max-width), but only overlapping ranges (always min-width), so there is no gap between them.

[pastelcyborg]

How to reproduce it? How can I get fraction of pixel width to test it?

I was able to just opening DevTools as a left/right panel and dragging it around manually, but I'm only on a 1080p screen, so that might be harder to achieve on a high-density display. I'll look into a more programmatic way to repro this.

[bartaz]

How to reproduce it? How can I get fraction of pixel width to test it?

I was able to just opening DevTools as a left/right panel and dragging it around manually, but I'm only on a 1080p screen, so that might be harder to achieve on a high-density display. I'll look into a more programmatic way to repro this.

As far as I remember this could have been also OS related. So only on some OSes (Ubuntu?) it was possible to get fraction of
pixel in window size, while in others (macOS?) it was always rounded to next pixel.