Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Media Queries and Responsive Design

engineering.kablamo.com.au

Post reply on HN
Print view View original

31–40 of 50 posts

Re: Media Queries and Responsive Design

#31

Post by chrismorgan »

nhardy wrote: post #23
chrismorgan wrote: post #12

Earlier quoted context omitted.

I’m confused by your defensiveness. What I express has the same browser support, but is correct (rather than leaving a tiny gap that is theoretically possible to encounter, though vanishingly improbable in reality), doesn’t depend on esoteric knowledge of the meaning of a 0.02px difference, and sticks with just the one magic number which is obviously desirable for various maintenance purposes. On the downside, “not a…

The CSS Media Queries Level 4 spec actually includes fractional pixel values as part of the examples for browsers which do not yet support the range syntax: https://www.w3.org/TR/mediaqueries-4/#mq-min-max > One approach to work around this problem is to increase the precision of the values used for the comparison. Using the example above, changing the second comparison value to 320.01px significantly reduces the cha…

If you have only one clause, using a negated clause is strictly superior. The only reason to go fractional is if you have multiple clauses, since Level 3 only supported negation of the entire thing. I think that’s why using negation has never been particularly common, because people sometimes like to basically do `(width >= 480px) and (width normally better stacking the queries—e.g. mobile default, then (min-width: 480px), then (min-width: 768px)—rather than attempting to apply them exclusively, though there are certainly sometimes reasons to do it otherwise.)

Re: Media Queries and Responsive Design

#32

Post by lapcat »

chrismorgan wrote: post #30
lapcat wrote: post #17

> To tell the browser that a site is providing an optimised experience for all viewport sizes, you can include the following meta tag in the document : > I see this a lot, but it's actually cargo culting, and all you need is initial-scale. "You do not need to set every viewport property. If only a subset of the properties are set, then Safari on iOS infers the other values. For example, if you set the scale to 1.0, S…

To begin with: that documentation looks to be ancient , so be careful as it may not reflect reality any more, though nothing stands out as obviously wrong. You’ve skipped over the difference: > Safari assumes the width is device-width in portrait and device-height in landscape orientation Whereas width=device-width means device- width when in landscape (device-width now being the longer axis), which is I think always…

> To begin with: that documentation looks to be ancient, so be careful as it may not reflect reality any more, though nothing stands out as obviously wrong.

I've also tested it. In fact I came upon that document in the process of testing, to determine what exactly "width=device-width, initial-scale=1" means.

> But if you specify width=device-width, then initial-scale=1 is actually superfluous, that then being the default.

This is not true. If you have wide non-text content, for example an img, then the page will not necessarily appear at scale 1.

Re: Media Queries and Responsive Design

#33

Post by chrismorgan »

dorfsmay wrote: post #26

Screen size is good for layout but don't forget "pointer". If (not (pointer: fine)) then you really want all your links to be more like button (big target areas easy to hit with a finger), otherwise you're forcing your users to do the zoom-and-click dance, and often completely give up. On the other hand, big button-like links are a waste of space if your users have a mouse, track point or track pad.

I generally disagree with this; the sorts of changes you might make for coarse pointers will tend to help the users of coarse pointers too; my mild inclination is to view any use of any interaction media feature as a nudge to reconsider aspects of your design. They’re really just too coarse to be particularly good, hints of how the user might interact with the document. You probably also want (not (any-pointer: fine)) instead of (not (pointer: fine)), as the spec notes suggest: https://www.w3.org/TR/mediaqueries-4/#mf-interaction. (These spec notes are fairly extensive, because these are delicate matters where it’s easy to make a mess of things.)

Re: Media Queries and Responsive Design

#34

Post by chrismorgan »

lapcat wrote: post #32
chrismorgan wrote: post #30

Earlier quoted context omitted.

To begin with: that documentation looks to be ancient , so be careful as it may not reflect reality any more, though nothing stands out as obviously wrong. You’ve skipped over the difference: > Safari assumes the width is device-width in portrait and device-height in landscape orientation Whereas width=device-width means device- width when in landscape (device-width now being the longer axis), which is I think always…

> To begin with: that documentation looks to be ancient, so be careful as it may not reflect reality any more, though nothing stands out as obviously wrong. I've also tested it. In fact I came upon that document in the process of testing, to determine what exactly "width=device-width, initial-scale=1" means. > But if you specify width=device-width, then initial-scale=1 is actually superfluous, that then being the def…

> If you have wide non-text content, for example an img, then the page will not necessarily appear at scale 1.

Hmm, interesting. Thanks for the correction; I confirm this in Chromium’s responsive design mode. Also that (as expected) if you’ve got suitable `max-width: 100%; height: auto` incantations so that it doesn’t actually overflow, this doesn’t apply, and you stay with an initial scale of 1. Frankly, I think that removing initial-scale=1 while developing might be a good thing, since it’ll make overflow more obvious, but I now have a clearer understanding of initial-scale’s purpose and default value. I suppose that means that it’s probably still desirable in general, as most causes of overflow are probably better handled by inducing scrolling rather than scaling the whole document down.

Need to file an issue to fix https://developer.mozilla.org/en-US/docs/Web/HTML/Viewport_m... which claims the default is 1, then. Going to add a blog post about this to my TODO list as well, since I had erroneously thought it was solely about that Safari orientation change bug, and have mentioned that belief a few times here on HN and probably misled others thereby.

(Found some potentially relevant spec, too: https://www.w3.org/TR/css-device-adapt/#handling-auto-zoom, though I’m not sure quite what the situation is, HTML Standard seems to cite that spec but a csswg draft, and that link’s a 404, and the @viewport stuff hasn’t ever been implemented and has been retired https://github.com/w3c/csswg-drafts/issues/4766>, so I’m not sure if there’s actually any nominally-active spec for meta viewport at present.)

Re: Media Queries and Responsive Design

#35

Post by leetrout »

nhardy wrote: post #27
kilian wrote: post #13

Nice overview, though I would advice against using device-specific breakpoints even beyond giving them device-specific names. Phones continue to get larger every year so designs made for 320px specifically started to become unoptimized when phones became 375px wide, and those in turn started becoming unoptimized when 414px became the norm, then iPhone 14 came out at 428px wide and that'll just continue. The best stra…

That is similar to what I was trying to convey. Breakpoints are just that though, the _point_ at which style rules _break_ into different groupings. Viewport _ranges_ exist between breakpoints. It is also a pet peeve of mine that breakpoints get referred to as "mobile", or "tablet". Very much agree on making content work at all screen sizes, and picking points where it makes sense to "break" at different viewport siz…

I use all my desktop screens split in half. It drives me nuts when I get mobile layouts on a browser set to half the width of my QHD displays.

Re: Media Queries and Responsive Design

#36

Post by kevincox »

chrismorgan wrote: post #28
bruce343434 wrote: post #14

Why is it not a thing to query the literal screen size in cm? Instead we have to work with fake pixel measures and scaling factors and a whole bunch of bullshit and edge cases.

Device diversity is such that that’s useless for general content. People use devices at less than arm’s length and at multiple metres away. Firefox used to have an experimental resolution-independent millimetre unit mozmm , but devices simply don’t tend to expose what you need so most of the time it wasn’t accurate. Browser makers considered standardising such a thing, but consensus was that (a) it wasn’t possible to…

It's also worth noting that CSS "pixels" are not real pixels. There are somewhat scaled to the relative size. But even better you can set your breakpoints in terms of `rem` which is the user's default font size. This usually gives a pretty good intuition to how big UI components need to be to be easily readable to the user. This can also handle differences such as a user with great vision on a small device (they set a tiny font to get the most of the limited screen space) compared to a user with limited vision on a large screen far away (their text size may be cranked high so that they can see it).

Re: Media Queries and Responsive Design

#37

Post by benatkin »

chrismorgan wrote: post #12
benatkin wrote: post #7

Earlier quoted context omitted.

There's no need to mess with the breakpoints. They're chosen carefully. The article explains why this one works optimally: > Why 0.98px specifically? 0.02px is the smallest division of a CSS pixel that an earlier version of Safari supported. See WebKit bug #178261.

I’m confused by your defensiveness. What I express has the same browser support, but is correct (rather than leaving a tiny gap that is theoretically possible to encounter, though vanishingly improbable in reality), doesn’t depend on esoteric knowledge of the meaning of a 0.02px difference, and sticks with just the one magic number which is obviously desirable for various maintenance purposes. On the downside, “not a…

> I’m confused by your defensiveness

It's because you say something is superior, and that "not all and (min-width: 480px)" negation syntax is by any programming language standard unreadable. The .98 thing is terrible too, but for me, I don't like when I can't easily parse using parens and PEMDAS. I don't think there is a single correct answer so I felt the need to point out that the breakpoints you disagree with are fine. I think it's fine if you use something else in your code but I don't really want the authors of frameworks I use to move over to "not all and X" that is really "not (all and X).

Re: Media Queries and Responsive Design

#38

Post by zuprau »

bruce343434 wrote: post #14

Why is it not a thing to query the literal screen size in cm? Instead we have to work with fake pixel measures and scaling factors and a whole bunch of bullshit and edge cases.

Seems logical, but as a user, I can already choose the size of the content of the screen, I don't want you to choose it for me. So we all agreed that "16px text" is ok and we started designing the world around that.

As a practical example: my iPhone lets me chose between "native" and "scaled up" sizing. This affects the whole OS including the browser. Where does your "cm" measurement fit in that? Do you want to override my (user) choice?

Additionally, every browser lets me scale the content up and down between 50% and 200%, so "cm" is broken once more.

"pixels" haven't been "pixels" for a very long time, and that's ok, they're now just a logical unit.

Re: Media Queries and Responsive Design

#40

Post by chiefalchemist »

nhardy wrote: post #27
kilian wrote: post #13

Nice overview, though I would advice against using device-specific breakpoints even beyond giving them device-specific names. Phones continue to get larger every year so designs made for 320px specifically started to become unoptimized when phones became 375px wide, and those in turn started becoming unoptimized when 414px became the norm, then iPhone 14 came out at 428px wide and that'll just continue. The best stra…

That is similar to what I was trying to convey. Breakpoints are just that though, the _point_ at which style rules _break_ into different groupings. Viewport _ranges_ exist between breakpoints. It is also a pet peeve of mine that breakpoints get referred to as "mobile", or "tablet". Very much agree on making content work at all screen sizes, and picking points where it makes sense to "break" at different viewport siz…

The other mistake I've seen with the "mobile" and "tablet" mindset is that "desktop" navs that rely on hover don't translate well when the "tablet" is desktop-esque in size.

In general I prefer to presume the user is always touch-based. At the very least, that's their mindset / exportation. Personally, I get annoyed with desktop experience that use hover but don't make it mindlessly obvious that you need to use hover (to get the info I need).

Clever might be clever but it's too often a shite UX.

Post reply on HN