4 ms·

> The most common solution I see online is to swap layouts when the page drops below a certain aspect ratio or width, which can actually be kind of annoying on

by sings 6y ago

> The most common solution I see online is to swap layouts when the page drops below a certain aspect ratio or width, which can actually be kind of annoying on desktops. It's a hacky solution. In many scenarios, there is no way to interpolate between the ideal layouts for large and small screens. This makes it necessary to arbitrarily select some point where the layout is rearranged as the viewport changes. I agree that this behaviour can be annoying on desktops as the window is resized, but it’s better than the alternative - a layout that needs to work the same way for drastically different screen sizes.

simion314 6y ago
The problem I have presented in the grandparent comment could be solved either with: - let me specify the button size in real world dimensions - let me specify that my button should be the same size as Safari/Chrome buttons in the toolbar. Then my users can't complain that on their device the buttons are too big or too small. The page was something like a map with a toolbox on bottom, if you make the buttons too big the map area is reduced, if the buttons are too small then are hard to use. With native toolkits like Qt you have a toolbox widgets, you don't define any dimension or colors and the user theme will handle everything.
- tracker1 6y ago
  if the OS reports the PPI correctly, px (1/96") and pt (1/72") give you real dimensions.
  - danShumway 6y ago
    A 5 inch wide page on a desktop and a 5inch wide page on a mobile device have different concerns because they're controlled by different pointer devices. It's a little irritating that they both collapse to the same touch interface.
    - tracker1 6y ago
      That's the case for most ui/ux at a given point for responsive design, regardless of the ppi/size reporting. Also, I'm refering to text/font rendering, not UX breakpoints, though I do understand the issue... the problem is, short of sniffing the user agent for "phone" or "mobile" there's no way to tell for sure... touch interfaces are unreliable as many desktops also have touch support. Note: I have used the phone/mobile sniffing to do some things slightly differently for desktop vs. mobile before. For the most part, it's not too big/bad of an issue.. I do know people that don't like certain sites/apps on desktop as this practice has changed though (namely, skype and discord) as a friend liked to use about 1/4 the screen for chat, but the ux now changes to phone ux when too small.
  - simion314 6y ago
    Browsers never report the real PPI, probably anti-fingerprint feature.
- danShumway 6y ago
  Right, the issue here is that we don't have enough semantic control over why an element is a certain size in CSS. One of the underlying reasons why `em`/`rem` units tend to work better in CSS for container widths is because very often semantically you want to design a column in relation to how many characters of text it should display in a row before wrapping. But not always; case in point touch interfaces where the reason everything is getting bigger is not because anything fundamental has changed about the user's text preferences, but because bigger elements are necessary for a bigger pointer. So it does kind of make sense to me that we could have a semantic unit that is unrelated to text size and specifically related to a user/device defined touch size. And then you could have a mix of min/max widths and heights based on different semantic units to have something that responds equally well to both narrow windows on the desktop and mobile devices. I am all for having more sizing units that are based on user-defined attributes that are applicable to a specific category of measurement (font-size, touch-precision, screen-brightness, whatever), not on trying to guess what specific device a user has.

by sings 6y ago

simion314 6y ago

The problem I have presented in the grandparent comment could be solved either with: - let me specify the button size in real world dimensions - let me specify that my button should be the same size as Safari/Chrome buttons in the toolbar. Then my users can't complain that on their device the buttons are too big or too small. The page was something like a map with a toolbox on bottom, if you make the buttons too big the map area is reduced, if the buttons are too small then are hard to use. With native toolkits like Qt you have a toolbox widgets, you don't define any dimension or colors and the user theme will handle everything.

tracker1 6y ago
if the OS reports the PPI correctly, px (1/96") and pt (1/72") give you real dimensions.
- danShumway 6y ago
  A 5 inch wide page on a desktop and a 5inch wide page on a mobile device have different concerns because they're controlled by different pointer devices. It's a little irritating that they both collapse to the same touch interface.
  - tracker1 6y ago
    That's the case for most ui/ux at a given point for responsive design, regardless of the ppi/size reporting. Also, I'm refering to text/font rendering, not UX breakpoints, though I do understand the issue... the problem is, short of sniffing the user agent for "phone" or "mobile" there's no way to tell for sure... touch interfaces are unreliable as many desktops also have touch support. Note: I have used the phone/mobile sniffing to do some things slightly differently for desktop vs. mobile before. For the most part, it's not too big/bad of an issue.. I do know people that don't like certain sites/apps on desktop as this practice has changed though (namely, skype and discord) as a friend liked to use about 1/4 the screen for chat, but the ux now changes to phone ux when too small.
- simion314 6y ago
  Browsers never report the real PPI, probably anti-fingerprint feature.
danShumway 6y ago
Right, the issue here is that we don't have enough semantic control over why an element is a certain size in CSS. One of the underlying reasons why `em`/`rem` units tend to work better in CSS for container widths is because very often semantically you want to design a column in relation to how many characters of text it should display in a row before wrapping. But not always; case in point touch interfaces where the reason everything is getting bigger is not because anything fundamental has changed about the user's text preferences, but because bigger elements are necessary for a bigger pointer. So it does kind of make sense to me that we could have a semantic unit that is unrelated to text size and specifically related to a user/device defined touch size. And then you could have a mix of min/max widths and heights based on different semantic units to have something that responds equally well to both narrow windows on the desktop and mobile devices. I am all for having more sizing units that are based on user-defined attributes that are applicable to a specific category of measurement (font-size, touch-precision, screen-brightness, whatever), not on trying to guess what specific device a user has.