The ideal viewport doesn't exist
viewports.fyi
viewports.fyi
I don't know how useful this is.
setting breakpoints allows some sanity in the build and testing process otherwise you have an infinite scope for issues which of course would be pretty lucrative for a boutique agency.
> "This goes all the way back to planning your projects too. When mapping out page content, ask yourself how it will be for the weird viewport sizes that don’t fit the typical mould? Always try to simplify and condense content to make it useful for everyone."
it's really not that complicated. keep the amount of crap (stuff that can go wrong) like animations, weird font sizes and font faces, javascript to a minimum. and dont do stuff like hijacking the scroll, zoom or other common behaviours. just dont do anything unless you absolutely have to.
but thats why the web is such a hostile platform. difficult to manage high user/client expectations with pragmatism.
The hijacking of scrolling pisses me off so god damn much that I've considered building Firefox from source and modifying the code to completely eliminate a website's ability to set the scroll position.[0]
Front end devs, I implore you. Stop acting like you think you know what the user wants in regards to scrolling behavior. Smooth scrolling already exists natively in every browser. There's no need to try to re-implement it in JavaScript. Your implementation will not work in every browser, and will only cause strange stuttering, bouncing, or even end up somehow completely disabling scrolling altogether. Do not try to get fancy and implement "momentum" into scrolling. You're changing a well-understood behavior into something that is unexpected and jarring, and likely it won't work anyways.
Do not change the scrolling amount. My wheel sensitivity and browser setting are configured so that 1-click ~= 2.5 lines of scrolling. Do not impose your preference of 1 click ~= 1 line on me. You do not know better than me.
And disabling zooming? WHO EVEN DECIDED THAT WEBSITES SHOULD BE ALLOWED TO DO THIS?! It destroys accessibility! Sometimes there's text or an image that's just a little too small to recognize. I'd pinch to zoom in...but some moron front-end dev has adopted the beyond-bone-headed mentality of "removing features is a feature!" and makes their site tell the browser to not allow zooming because...why? Someone please, tell me why.
[0] I'm sure it's possible to write an extension that could do this, but any time you're manually setting the scroll position in code, you're bound to fuck it up. Rather just completely eliminate the ability to set the scroll position entirely.
Applications such as maps, image editors, presentations, and flowcharts benefit from having control over zoom. (And you'll notice that almost every one of them does.)
This of course is only one difference of many between "documents" and "applications" and the web is being used for both.
Browser zoom cannot be overridden.
Plus, overriding the zoom gestures makes it really hard in mobile browsers to access the actual browser zoom, although I blame that on browsers.
(In stead I have to disable zooming in on images to preserve the next/previous/close buttons and implement zoom from scratch. wtf?)
The only thing maps.app or Google maps are good for are finding places to spend money or driving to places to spend money. If you have any other spatial interests, they're almost pointless.
I would happily run a build that removes this capability.
https://upload.wikimedia.org/wikipedia/commons/3/3d/LARGE_el...
Look how fast and responsive it is!
I had a weird experience with Google Groups recently - I zoomed in because the text was too small and ... the page resized the viewport to its original pixel size even though the font was scaling. Ended up with about 10 characters in an unscrollable viewport. HILARIOUS.
Alternate horror scenarios that are all too common:
Zoom only to have one picture take over the whole page, pushing text off the side (not even down, off screen to the side).
Zoom only to have the text immediately become wider than the screen, forcing you to scroll sideways for every single line.
I will say this… the scroll speed being different between Chrome, Safari and Firefox doesn’t help our cause… wish these were normalized at the very least so we can avoid “it feels better in X, but we use Y browser” notes.
Allowing an easing function API for scroll would be a middle ground I could live with. It’s better than what we have now (a bunch of award winning sites emulating scroll with translates).
Smooth scrolling can cause motion sickness because it doesn't perfectly match up with the action. Javascript versions make it even worse because the ratio is pretty much guaranteed to be off from the user's normal scroll amount, particularly with a mouse or touchpad.
It's not that bad for me, but I do disable it wherever possible because I find it disorienting. Can't do that with javascript implementations.
I have a collection of articles and studies and discussions on scrolljacking that I show to the business stakeholders when it comes up.
I make sure thy hear from multiple parties independently when such an idea starts making its way toward implementation.
But it is exhausting because trendy flashy websites still use the technique and do catch the eye and I have to explain why we can’t and should not have the shiny toy - despite big brand x y or x having it.
In which process I am saying no to the very people deciding on my bonus.
Just a bit of perspective.
It was very jarring and also felt weird being flush with the top - we added a jQuery smooth scroll to go to just a little above the item in a few hundred ms and it felt much better. I say this as someone who generally hates scrolljacking and custom scrollbar rendering on sites.
For sites that have no business disabling zoom: no idea, and it annoys me too. I just chalk it up to dev, designer and/or managment incompetence, close the tab and never return again.
/Moron frontend dev
excuse me, but no designer ever gave audience to such a sensible suggestion
That'll break just about every cloud logging UI I'm aware of, but what you do to your own UA is your business.
I think very. I've never designed anything based on arbitrary breakpoints (md, lg, xl and whatever numbers they might translate to) because that forces me to make design choices around those constraints.
The only way to sanely add breakpoints in my opinion is to gradually reduce the width of your page and search for things that start looking off. Are your paragraphs starting to look a little cramped? Add a breakpoint at that width, maybe remove the sidebar, maybe lower paddings and margins to allow it to stay a little longer, maybe manually reduce font size or switch your column layout to rows if applicable. Keep doing that until you get to ~350px width and everything looks fine. You decide what needs to change when it makes sense rather than being told that something needs to change at some specific breakpoint.
But it just isn't practical for a commercial product that needs manual testing. If you have a single breakpoint, you only have 2 versions to test. If you ultimately have 30 different breakpoint values, that's 31 versions to test. And that's a lot of opportunity for CSS rules designed in isolation to wind up colliding with undesired results.
Not to mention a nightmare for any designer to attempt to document expected behavior.
To test that the responsiveness works everywhere, the easiest thing is to probably go to the "responsive" tool in the browser's devtools, which opens the page in a little subwindow inside the main browser window, and then you can resize the subwindow freely to check a range of different sizes (rather than just an explicit set of them).
The website that is the subject of this discussion comes from Andy Bell.
I would encourage you to see his other work, e.g. Every Layout[1], and the website[2] linked to a recent talk he gave[3].
In particular the answer to your question can be found at 14:38[4] in the talk, perhaps more precisely the slide he shows at 14:59.
[1]https://every-layout.dev [2]https://buildexcellentwebsit.es [3]https://www.youtube.com/watch?v=5uhIiI9Ld5M [4]https://youtu.be/5uhIiI9Ld5M?t=878
>setting breakpoints allows some sanity in the build and testing process
clamp allows for sane responsiveness
https://developer.mozilla.org/en-US/docs/Web/CSS/clamp
and if needed you can add some minimal breakpoints.
The fact is that most front end devs don't know about it, and there is no framework that I know of which is based around its use (and everything nowadays seems to be about the frameworks), thus you end up with inefficient multiple breakpoints which may seem sane until you get too close to one of the breakpoints and your design looks like crap until that point is hit and you can switch to the new values set for the breakpoint.
breakpoints are a great solution if you happen to be living and working in the web of 3 years ago. But the clamp, min, and max functions have been available in every major browser since 2020 - even Opera.
People keep telling me 3 years is an eternity in internet time, so why are there still all these damn breakpoints?
they're simple, easy to understand and well tested.
looking at clamp it smells of over engineered complexity. 3 arguments. difficult to visualise.
margin, padding, box sizing, line-breaks, non-breaking spaces that can all impact how text flows and wraps - clamp is stacking on top.
most css is written, forgotten and ime never refactored. so what's fast and dirty often is good enough, within reason.
although you can use clamp to do complicated things that are difficult to understand, as is the case with all technology the simplest way to use it is quite clear.
(static minimum size you want for something, percentage of something, static maximum size you want for something)
thus width: clamp(100px, 80vw, 750px)
and now someone says well why wouldn't you just do min width max width etc. with that - no reason it's just nicer to have it one line to see IMO. But of course you can put clamp anywhere you can calculate anything so.
margin-left: clamp(20px, 5vw, 50px)
OR
margin-right: clamp(var(--minmarg),var(--margpercent), var(--maxmarg))
then you change your minmarg, margpercent, maxmarg as needed by normal css variable rules.
This should be an easy to understand system for a developer. It is easy enough for me to understand and visualize, and I suck at visualization.
This allows one to finally get rid of most breakpoints and say not just what the min and max heights and widths are of things but what the min and max and preferred margins, paddings, font-sizes etc. are of things - which without that IMO the max height and max width is just sort of stupid. But with that you can make designs flow and look good in a manner that can actually be described as 'responsive'
Now as I said - one can do all sorts of complicated and clever stuff on top of this sure. And if people do that they might end up with something that is difficult to reason about.
But if people can't reason about the margin example above then I think they should probably switch from Frontend development.
on edit: grammar change.
> crap (stuff that can go wrong) like animations, weird font sizes and font faces, javascript
None of these per se are the issue, and you can still have the issue with zero animations, fonts or JavaScript.
Mobile:
50% of viewports: Width 375, Height 635
80%: Width 375, Height 635
90%: Width 360, Height 560
95%: Width 360, Height 550
99%: Width 320, Height 500
Desktop:
50% of viewports: Width 1440, Height 900
80%: Width 1024, Height 600
90%: Width 1024, Height 600
95%: Width 1024, Height 600
99%: Width 800, Height 300Honestly, now that container queries are available, I see very little use for breakpoints. Container queries allow for easy reuse of components, and a truly fluid and responsive design.
You're still probably going to want the left sidebar of your multi-column layout to collapse behind a menu on narrow viewports and abruptly appear when the viewport width gets to >= n [0]. But it's conceivable that the value of n emerges from some constraints you specify (such as the minimum desired width of the sidebar and the main content column), instead of being chosen upfront from a small list of predertmined breakpoints.
[0] E.g. https://tailwindui.com/components/application-ui/application...
The example you give of a sidebar collapse with a menu button replacement can easily be accomplished with a container query on the wrapping box, no?
I'm honestly curious about a use case that a media query breakpoint can handle, but which a container query can't.
It's one thing to convince them not to do some weird scrolljacking, but even something like a dropdown or a popover adds a ton of complexity for responsive sites.
I invite you to learn to use a screen reader and try using your app (whatever it happens to be). It's seriously pretty terrible for some of these websites with all the fancy crap.
I have lost jobs and annoyed people trying to argue for greater care with accessibility. It's somewhat depressing.
If it doesn't you can instead appeal to the bottom line. Tell 'em that they might get targeted by an accessibility troll: https://www.wrightlawgroup.com/blog/attack-of-the-ada-trolls
As far as trolls go, I consider these fairly benign, as their behavior actually promotes something good; we got hit with such a lawsuit, and all of a sudden a11y became a big thing as our CEO didn't want to give a dime to those 'greedy assholes'.
In all seriousness, I ask something similar to the above: "Would you feel the same way if you got in an accident that left you blind for the rest of your life?" Sometimes this moves a few people to your side. I don't want to be the only one, but I do care about accessibility. I care a lot, for personal reasons. But like you said, you don't want to be the minority trying to support minorities.
Users can't, for some hideous reasons that should be illegal due to accessibility concerns, disable it, and it is an excellent way to accidentally throw away your work several times a month if you don't have very steady hands, depending on if the back button decides to not restore.
Plus it's also just plain annoying. If a site has no well defined concept of pages, you'll probably be in a whole different dynamically generated page. Not that I think sites like that are all that great to begin with...
* The web is a great way to publish information and access a few services.
* The web is the cross-platform operating system for applications.
Everything stems from the difference in those two approaches. Both are correct.
Your first WebGPU app (Conway's Game of Life)
https://codelabs.developers.google.com/your-first-webgpu-app
There is so much whitespace, huge fonts, huge buttons, hamburger popup menu everywhere (aaaargh!!)
Basically it boils down to the “information density” which is dumbed down to the lowest possible denominator.
There should be a measure for this and websites/apps should be rates based on that.
It really makes me wonder 'wtf? Who designed that, did he actually try to use it by himself?'.
At least it seems they steps back a bit now. Also they moved the new mail button back to top left.
I'm very familiar with websites switching to mobile layout with hamburger menu instead of a navigation bar, when you reduce the width of the browser window on your desktop. BUT I don't think I've ever come across a resolution change where the website elements (either hamburger menu or content) get massively larger.
Can you provide an example of one or two mainstream sites that change resolution like that?
The reason I'm confused is because in CSS everything is based on logical pixels, not actual device pixels. E.g. a "1 px" width will be 2 or 3 hardware pixels wide on an iPhone. Similarly "1 em" will be 16 hardware pixels on a standard resolution display, but 32 or 48 hardware pixels on a 2x or 3x display. So web designers don't have to do anything special to accomodate hi-DPI screens in the first place.
The hamburger menu buttons all seem normally sized to me when I make a browser window narrow on my desktop.
Although 16x16 is a little on the small side even for desktop. The point isn't just to click it, but to have it be prominent enough to see and notice as a primary action. It's about visibility, not touch area.
For example, on the SquareSpace homepage (an example someone else brought up) it's 30x18. That seems like a nice size to me. It's two pixels taller than the 16 you suggest, but the extra width helps make it a little more prominent. Especially since the width isn't taking away from anything else.
I can't tell what units you're measuring in, are you measuring hardware pixels on a hi-DPI screen? We're talking about logical pixels which is the only thing that makes sense to measure in and compare.
But comparing it with e.g. the refresh button on your browser, it's merely 17% taller than that, in your screenshot. So I literally don't know what "absolutely massive" you're talking about.
It seems perfectly fine to me. Maybe I'd make it a little narrower, but they probably wanted to balance the logo in the top left corner in terms of visual weight, so it makes sense.
You've been able to select radio buttons by clicking on their text for decades now. On desktop. Often literally hundred of pixels wide.
Generous margins for clickable elements seems like a feature, not a problem. As long as they don't interfere with anything else (which they don't, here).
And 16 pixels tall...
Sorry if it sounds rude, but have you used the web on the desktop in the past 10 years? Anything under 1000px-wide windows and sometimes 1200px-wide ones gets you the “mobile menu” on most websites. It’s a consequence of Bootstrap and other fixed-breakpoint frameworks. Overflow menus like what you see on GitHub repositories are the minority.
And for an example that does it better, legacy.reactjs.org :)
When I saw it I wondered how they managed to drop the ball so hard and how much they paid for it. All they needed is to expand and slightly restructure the docs, but apparently someone sold them a complete redesign that just made the whole docs way less usable (a11y aside, can't speak for that).
IIRC SquareSpace does exactly what they're saying: on desktop sites will have a horizontal list of links but on mobile it's a hamburger icon that takes over the entire viewport when clicked. Functionality exists to target pointer type and things like that in media queries, it's just very rarely used.
https://developer.mozilla.org/en-US/docs/Web/CSS/@media/poin...
coarse - The primary input mechanism includes a pointing device of limited accuracy
such as a finger on a touchscreen.
fine - The primary input mechanism includes an accurate pointing device, such as a mouse.
Gotta love how every time you don't watch CSS like a hawk, it spawns 500 new features. Thanks again.
Surely this is better than cutting off the navbar and half the page content in the middle vertically, and requiring the user to scroll horizontally?
The point is that the viewport-covering menu is huge because it’s designed to accommodate touch (i.e. imprecise) interaction. It could be much smaller when the user is using a mouse. But you rarely see such accommodation being made. The assumption is low width = mobile = touch.
The actual menu items you select are 20 px font size in the hamburger menu, and 18 px font size from the navbar menu. That's just 11% larger. Nothing about that is "huge".
The hamburger menu taking over the whole (narrow) screen doesn't bother me at all. If I'm using the menu, it's not like I need to be looking at the rest of the screen.
And it just feels silly to create a third design. We already have navbar for widescreen and hamburger menu for narrow screen. Now you want a third version -- a hamburger menu that is pop-up rather than fullscreen -- for narrow desktop usage? I sure wouldn't want to do all that extra work.
My normal browser width is about 1300 pixels and I see so many web sites and apps these days that can't tolerate what I consider a very reasonable browser width that this is the only explanation I can come up with.
There are devices with resolutions under 800x600 still accessing the Web. Every developer has to place where their own minimum threshold of consideration is. I personally aim for those old-school resolutions as the minimum, and may move upwards to something like 720p if it's a bit more complex. My screen itself is 1080p, so if it looks good at full screen, it will probably look decent on 4k as well as long as I'm using scaling units.
The problem, generally, is that frontend dev is taught poorly if it’s taught at all, and the barrier to entry is so low that there’s an Eternal September problem.
I think I could've learned a GUI toolkit and had something working in the time it's taken me to pick up building two JS apps. The barrier to entry may be low, but that's only because the feedback loop for webdev is super tight. Great for prototyping, experimentation, and getting more newbies in the field. But it's crazy that anything productive gets built on JS and DOM.
The backend, with databases and storage and caches, service management and sysadmin, that's where the fun is!
You'll notice that a lot of GUI toolkits have already adopted something like CSS (Qt Style Sheets, JavaFX CSS, etc.). Yet they will never become as good, just because there are much fewer people working on it.
I've been practicing webdev since 1999 or so; I understand how useful CSS is and still remember the dark times of inline style attributes. :)
Making something on the Web is a bit strange due to needing to set up 3 different technologies, and line them up just so, and pray a future browser update doesn't mess up some logical assumption you made along the way.
It appears CSS classes are used somewhat like UI 'states', in a JS app. It's taken some time to adjust to using more logically meaningful class names instead of structurally meaningful that I used with regular non-JS webdev. Toggling a class somewhere sometimes requires doing other things in the UI, too. I've found lots of tiny little UI bugs as I develop and learn more about how things need to work in an event-based system.
As a result, I find I do not like this way of building things. Sure, it's cross-platform, because the browser-makers do all the heavy lifting. But Tcl/Tk is cross-platform. Allegro and wxWidgets and Qt are, too. Tkinter is a single `import` away. Each has its own challenges that get added on as a result of not relying on a multi-gigabyte-per-instance virtual machine, but software is all about trade-offs is it not?
Lesser used things aren't changed as often, for example. You can rely on them to not change so quickly. Compared to Mozilla or Google, who are competing for highest software version number and have a new release every 6 weeks.
+--------------------+
| . . |
| *. .*. |
| .**. .. |
| ..*. |
| . . |
| . |
+--------------------+https://i.imgur.com/9cJ13ue.png (alternative link: https://imgur.com/a/uBG5KUD)
(The area of each circle is proportional to the count, clamped to a minimum value. Axes a are linear.)
Uses the data from https://viewports.fyi/data.csv.
Code:
import csv
from math import sqrt
import sys
csv_reader = csv.reader(sys.stdin)
headings = next(csv_reader)
data = [tuple(map(int, row[:3])) for row in csv_reader]
max_w = 7100 # max(row[0] for row in data) + fudge
max_h = 7100 # max(row[1] for row in data) + fudge
max_count = max(row[2] for row in data)
margin = 200
svg_width = max_w + 2*margin
svg_height = max_h + 2*margin
max_r = 90
min_r = 4
print('<?xml version="1.0"?>')
print(f'<svg xmlns="http://www.w3.org/2000/svg" width="{svg_width}" height="{svg_height}" viewBox="{-margin} {-margin} {svg_width} {svg_height}">')
print('<desc>Visualization of viewport sizes from https://viewports.fyi/</desc>')
print(f'<rect x="{-margin}" y="{-margin}" width="{svg_width}" height="{svg_height}" fill="white"/>')
print(f'<line x1="0" y1="0" x2="{max_w}" y2="0" stroke="black"/>')
print(f'<line x1="0" y1="0" x2="0" y2="{max_h}" stroke="black"/>')
for i in range(0, max_w, 200):
print(f'<text font-size="64" font-family="sans-serif" x="{i}" y="-30" text-anchor="middle">{i}</text>')
print(f'<line x1="{i}" y1="0" x2="{i}" y2="-20" stroke="black"/>')
for i in range(0, max_h, 200):
print(f'<text font-size="64" font-family="sans-serif" x="-30" y="{i + 20}" text-anchor="end">{i}</text>')
print(f'<line x1="0" y1="{i}" x2="-20" y2="{i}" stroke="black"/>')
print('<g fill="blue" stroke="darkblue">')
for w, h, count in data:
r = max(min_r, sqrt(count) / sqrt(max_count) * max_r)
print(f'<circle cx="{w}" cy="{h}" r="{r}"/>')
print('</g>')
print('</svg>')The author's put forward a lot of valid criticisms of the breakpoint-based approach & also provided a really good guide to doing proper web design, but what's skipped over is that their guide only works for developer-designers, & won't fit the workflow of a large proportion (majority?) of people doing visual design for web. Those designers are have backgrounds in multimedia or have academic backgrounds in design-forward colleges with extremely poor html-css modules. And their tool is Creative Suite - largely because Adobe has a stranglehold on design education.
The likes of Sketch have shaken things up somewhat so we at least have XD, and slightly fewer people are designing entire websites in Photoshop & Illustrator alone, but even so - the ability of tools like XD/Figma to allow the designer to model their work fluidly in a way that matches web viewports is not mature, not least because Adobe have been historically hostile to the idea (XD being a very reluctant response to new competitors after already killing off Fireworks).
Across the wide industry, sure, but I haven't worked with a designer who uses Photoshop in 10 years...
Granted, I'm in my own bubble, but over a varity of gigs it's been Sketch, and now universally figma.
Even so though, Figma, while an improvement, is still not where tools should be in this regard. It's a compromise between what's expected by Adobe-educated users and how things actually work on the web.
It's a bookmarklet that gets rid of sticky elements. It nukes those stupid fucking headers and footers and kills most cookie banners and "give me your email" type pop-ups. Works in every browser (I use it in Safari on iOS and Firefox on desktop). I almost reflexively go hit this bookmarklet on every website now. It makes the web so much better.
You can shrink them by rotating your phone back to the correct, portrait orientation.
While this is laudable, I think it’s important to remember that a design should focus more on how the layout flows when resizing the viewport and focusing on a couple target breakpoints. I think that’s what this article is trying to emphasize.
(they have 120000 viewpoints):
"Wembley stadium has a capacity of 90,000, so our datapoints could fill Wembley once and still fill another third of the available capacity."
the way this is written adds to confusion rather than enlightens. "another third of the available capacity" makes it sound like there is space left over in wembley i.e. you haven't fully filled it.
I think people know how big 120.000 is, but if you must, just say its more than wembley
Agreed. And if you must compare to a stadium, why not just pick a bigger stadium? You can pack at least 115,000 into Michigan Stadium, which would get you a lot closer than Wembley.
(What's that you say? You've never been to Michigan Stadium? That's probably another reason not to rely on this kind of comparison! I, for example have never been to Wembley and have no idea how big it is.)
If the post was “the incredible difficulty of inserting 120k rows in database” you’d have a point. But it isn’t.
Their "all viewports" page also isn't visible on my browser if the window is too small as the titles on each viewport aren't visible.
+ A focus on viewport size instead of screen size.
Few people browse websites in full screen in fact "Full Screen" browsing is used almost entirely for people using a web browser for presentations or physical kiosks. A completely different use-case than regular desktop browseing.
I loathe the fact that when I tile my windows to half my screen size the website "helpfully" switches into a tablet/mobile layout. Incidentally WCAG (which I consider a well-meaning but ultimately largely useless set of guidelines) can be blamed for a lot of this nonsense.
Things that I hate about this article:
- Like many "analysis" articles they start with a misleading validation of their sample size. 120,000 datapoints is not terribly big.
- Implying that these screensizes can't be grouped together. Resolutions #3 and #4 are practically identical 393x660 vs 390x664 is essentially a rounding error.
- Implying that any sane person should be considering how their desktop/mobile website should be displaying on a smart watch. This is totally different use case and (admittedly having never built anything for a smartwatch) I assume (hope?) that unless you've somehow identified your design as being smart watch compatible the browser is very liberally going to strip most of your layout and styling anyway to just text and headings.
- Implying that anyone should care about the minor differences in screen sizes. As a veterean of the Flip-phone days when the scourge of "form over function" phones (think Beyonce clamshell phone) was at its previous highest. There is no solving this problem. Apple swooped in an took a strong-armed approach to screen sizes that made developing on iOS EXPONENTIALLY EASIER than supporting MIDP or Android.
- A useless masonry visualization of viewports in a garish orange/purple contrast that is impossible to read. Thanks for nothing.
I feel like I must be a minority, My workflow is almost entirely switch desktop+ switch tab.
Client education is a challenge and all, they often have ideas in mind that are very specific (For some reason clients invariably like the simplest thing that's the least general and most direct of a translation from a basic analog system...). But on the technical side... once you stop making designs that rely on being able to control exactly where everything goes it gets a lot easier.
Why is this even here? This is a long ad with useless data points.
I've found that on simple websites a lot of problems are solved with just a few lines of flexbox config (flex-wrap, etc)
Present a .css file for mobile or for desktop, based on the presence of "mobile" in the agent string. Chrome continues to report that agent data and it's very accurate for this use case (where your primary aim is to detect mobile equivalent, else present for desktop).
You can drop the viewport html tag. All major phones, including iOS and Android operating systems going back at least a decade, will automatically scale your site for mobile without viewport. You customize the mobile version of your .css file for just mobile. And it's very easy these days to cross check to make sure the look and compatibility is correct (for Chrome and Safari mobile in particular). You present different site UI/UX based on the "mobile" detection; if mobile, present mobile layout, else present desktop layout.
Google will punish you (SEO) slightly for the lack of a viewport tag however.
This is a far easier way to design for mobile & desktop vs trying to deal with many different viewports (which is a ridiculous, backwards problem that represents an industry failure).
Please don't do this. There's a reason it's an unpopular approach.
The core to it is simply getting the "mobile" keyword out of the user agent string. That takes care of nearly everything, from there all you have to do is a simple css split for either desktop or mobile.
It very effectively covers all the major browsers, all the major platforms, going back at least a decade.
Your desktop browser doesn't include the keyword "mobile" in the agent string. Your Safari browser on iOS does, ditto for Chrome on Android.
So here's the iPhone 13 Max user agent string:
"Mozilla/5.0 (iPhone14,3; U; CPU iPhone OS 15_0 like Mac OS X) AppleWebKit/602.1.50 (KHTML, like Gecko) Version/10.0 Mobile/19A346 Safari/602.1"
The "mobile" keyword gets you what you want.
Here's iPhone 8:
"Mozilla/5.0 (iPhone; CPU iPhone OS 11_0 like Mac OS X) AppleWebKit/604.1.34 (KHTML, like Gecko) Version/11.0 Mobile/15A5341f Safari/604.1"
The "mobile" keyword gets you what you want.
ChromeOS desktop (Chrome browser), Mac desktop (Safari), Windows desktop (eg Chrome or Firefox). They don't include the "mobile" keyword.
It's not flawless, getting to 100% requires a lot more effort. This approach is far beyond good enough however, particularly for an average site. If you're building a giant enterprise app and want to appeal to every possible user and you have a team, maybe you'll throw a lot more resources at getting the small number of problematic edge cases.
And if you're using Nginx, which I commonly do, you can map the agent key in your http segment, eg:
map $http_user_agent $mobilekey {"~*Mobile" mobile; default desktop;} (or vise versa)
and then you can utilize that for caching related tasks (attach it to your proxy_cache_key to differentiate a mobile vs desktop cache).
And as I've noted, this is widely despised by the HN crowd despite the fact that it works so well and so easily.
If this is how you want to build websites, discarding users, go ahead. But it's irresponsible to recommend this as advice to others.
In this particular case, it makes the largest viewports look the smallest, and makes the smallest ones look largest. It's indeed very deceptive.
> It’s safest to presume that users on desktop or laptop devices are not filling their entire screen with a browser.
Is this true? If you're reading this casually (and you are reading this casually) is your browser not at full size? I almost exclusively use my desktop and laptop with windows maximized unless I'm doing some work which requires me to split up my screen (for example writing while looking at docs or program output). Am I the outlier here?
Over the last few years increasingly many websites when allocated half the laptop screen have needlessly contorted into less functional layouts appropriate for a phone, but stretched huge.
Given that the workaround was to set the system font-size small enough that the button would appear back on the screen, this would also be an accessibility problem for those who have their font-size set larger, even if their screen would be normally large enough to display it.
Besides the fact that I'm not convinced the 3d touch one is a real viewport, how can he miss the fact that there is landscape mode on these devices, which have completely different dimensions?
120,000 > 116,000, so their 120k data points could more than populate the town...
Then there's the progressive web app (PWA) debacle, where users don't even know what a PWA is and don't know that they can pin sites to their home-screen, simulating an app.
Users don't need to know what a PWA is. Thereason users don't know that they can be 'installed' is because they're on iOS, where Apple has been effectively hamstringing them in favor of the Apple App Store. There is a way to install PWAs on iOS, but it's quite hidden.
We basically just account for 800-1300px width range and call it a day. On the low-side, we show a "desktop only" overlay. On the high side, we block the content from expanding.
"it's a much difference picture." should be "it's a much differeNT picture."
[0]:https://viewports.fyi/data.csv [1]:https://viewports.fyi/all/
Not on literally any laptop I've ever seen. I've never seen a screen where the browser _isn't_ filling all space available to them, sometimes even the entire screen (in fullscreen mode on MacOS).
A lot of people still make this mistake one way or another. In about the last year I finally gave up; my tiling window manager used to have the browser at 2/3rds the screen with the remaining 1/3 a terminal, but more and more I've been encountering websites that are very unhappy with that width; not small enough to kick in mobile mode or they detect that I'm on a desktop browser and don't adjust, but not large enough for the design they serve me, creating overlapping regions, or horizontal scrolling, etc. So my browser is full screen a lot more often now. On the one hand I'm annoyed, but on the other, an implication of the article is that you essentially can't test at "all" viewport sizes anymore and it's just so easy to accidentally write a website that is unhappy at exactly pixel widths 892-945 when used with my exact font setup and/or zoom setting that I can't really stay mad at some of these sites. Some of the sites I have trouble with are clearly trying, and are competent in many other ways. You can hardly expect your designers to visit every page on your site and test every single width from 200 to 2000 one pixel at at time, let alone ask them to do it again with a variety of zoom settings.
Heck, I can't even tell you my own website can do that. I've checked it on a phone and in my desktop browser at a couple of sizes, but I can't do it anymore than anyone else can nowadays.
It almost makes me nostalgic for 960px being the defacto standard width for desktop sites.
Never. I cmd+tab between windows. What I _have_ seen is developers have those on different monitors, but even there the browser is always fullscreen.
> And even barring that the taskbar of your OS along with window decorations means that your browser is seldom 100% of the screen
I did mention this ;)
Although I think that sentence would probably be better written "It's safest not to presume [...]", as in, don't make assumptions about screen sizes here.
Go maximize your browser and enter this into your dev tools:
console.log(`${window.innerWidth}x${window.innerHeight}`)
Gnome pushes users to fullscreen programs too, with a quick mouse twitch to get the overview open to switch programs.
But I think what they meant is: it is safest not to presume that desktop or laptop users are filling their entire screen with a browser.
The way they wrote it suggest that the assumption of the negative is safest, while the way I wrote it says it is safest not to make the assumption. This has a general smell of the inverse fallacy, although it isn’t like they are trying to make some bulletproof logical deduction anyway.
Personally, I always use a browser full screen and most everything else is 'windowed'. My browser usually ends up being the "background" of my monitor, only traded out when I'm writing code, in which case my IDE is the "background" (full screen). Everything else except games runs in a smaller window. Dragging and dropping still works, like that. It's just really convenient.
From mostly working with other devs, this is usually what I see. This is how I see MOST people use their desktops. Full screen browser, always. Then we get to this article and this comment section and people are talking like it's a given that MOST people use their browsers in windowed mode. Personally, the only time I can even remember someone doing that is when they snap it to an area and then snap something else beside it.
My suspicion is this is a Windows/Linux vs Mac thing? Everything in Mac defaults to "floating" app windows, instead of defaulting to a single app window, maximized, with sub-panel windows inside the app renderer. So people just kind of mentally map it that way, depending on the OS? But then, that's just a guess!
Obviously, I don't mean to imply that one way is better or worse. I'm just kind of intrigued by how blindsided I - and apparently others - are about this.
Anyway, you're right about the article's hand-waving. It's not as compelling to me, because I've had users file tickets when our "anything past 1060px gets centered on the screen, instead of expanding to fill" method was displayed on a 4K screen. They claimed it was "unusable", even though it was entirely the same, it just didn't expand as much as they would have like (yes, even on a TV; other users were using it just fine). So I don't think anything past 800 is less worth consideration. At the very least, I'd say that number is more like 960 or 1400. The upper end of standard desktop sizes instead of the lower. At 800px width, even default browser font sizes look big. Scaling down to a 10 or 11px font size is fine for complex utilities, but when you're trying to size it for big, finger-sized buttons, 800px gets cramped, fast.
But yeah, the overall advice holds.