Live data from Hacker News

Media Queries and Responsive Design

engineering.kablamo.com.au

21–30 of 50 posts

Re: Media Queries and Responsive Design

#21

@media (max-width: 479.98px) This would be more accurately expressed with negation (though the difference will probably never matter to even a single human): @media not all and (min-width: 480px) This is using widest-compatible syntax, since WebKit only very recently (Safari 16.4) got the Media Queries Level 4 stuff to let you write it in clearer ways. The “not” applies to the remainder of the query: parse it as “not…

You should mention that new stuff, so that people know what to look forward to.

@media (width < 480px)

Re: Media Queries and Responsive Design

#22

@media (max-width: 479.98px) This would be more accurately expressed with negation (though the difference will probably never matter to even a single human): @media not all and (min-width: 480px) This is using widest-compatible syntax, since WebKit only very recently (Safari 16.4) got the Media Queries Level 4 stuff to let you write it in clearer ways. The “not” applies to the remainder of the query: parse it as “not…

You should mention that new stuff, so that people know what to look forward to. @media (width < 480px)

The article already mentioned that.

Re: Media Queries and Responsive Design

#23
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…

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 change that a viewport width on a device would fall between the cracks.

The .02/.98 values might seem strange, but many popular libraries use these offsets (including Bootstrap: https://github.com/twbs/bootstrap/blob/main/scss/mixins/_bre...).

The way I tend to work with media queries is not writing them directly but rather use a mixin (when using SCSS) or a media function (CSS-in-JS). That way, this weird quirk can be documented just once in an application, leaving anyone curious enough with the explanation. There tends to be an 'upTo(breakpoint)' function which is an exclusive range, and a 'from(breakpoint)' which is inclusive.

Re: Media Queries and Responsive Design

#24
post #18

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.

For desktop systems the EDID data is not always reliable. Besides, you don't want the screen size, you want the viewport size and the DPI.

I think I want the arc length of the viewport. Fonts should have a minimum size based on that, certainly not 11pt or whatever.

Re: Media Queries and Responsive Design

#25
post #18

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.

For desktop systems the EDID data is not always reliable. Besides, you don't want the screen size, you want the viewport size and the DPI.

> Besides, you don't want the screen size, you want the viewport size and the DPI.

...I can think of at least one case where you really would want the screen size, although perhaps it's specialized enough to warrant a separate API.

As a user, I have often wished there was a reliable way to view an image on the web at "actual size". Examples would include purchasing band-aids on Amazon, or reading a Wikipedia article about insects. As far as I know, there's currently no good way for websites to offer this, and there really should be!

Re: Media Queries and Responsive Design

#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.

Re: Media Queries and Responsive Design

#27
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 sizes depending on the content. At the end of the day, it is very arbitrary.

Thanks for the link!

Re: Media Queries and Responsive Design

#28

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 make it accurate far too much of the time, and (b) it’s almost never what you want anyway (about the only legitimate uses: simulating a ruler, and physically-accurate sizing for comparison with physical artefacts; certainly never on general-purpose web pages), so it was just dropped.

Re: Media Queries and Responsive Design

#29
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…

It looks like that advice is specific to iOS. Recommendations elsewhere specify that both device-width and initial-scale should be included for compatibility with all mobile devices, e.g. https://developer.chrome.com/docs/lighthouse/pwa/viewport/

Re: Media Queries and Responsive Design

#30
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 going to be what you actually want. If what they document is correct, and it does sound right for how I recall it being described some years back, that the page effectively zooms in when you rotate, then it’s just not what you want.

Testing in desktop Chromium’s responsive design mode, it does seem to behave reasonably in the presence of . I haven’t checked anywhere else.

But if you specify width=device-width, then initial-scale=1 is actually superfluous, that then being the default. I understand that it was part of the common incantation in order to work around Safari orientation change bugs which I think have been fixed for a few years now, but I don’t have anything to confirm it on (really wish they’d provide an emulator for non-Apple platforms) and have never had anyone answer it when I’ve mentioned it here on HN.

Post reply on HN