I think the nail is in coffin now: you should never design something for the web with only one (or even a narrow set) of particular viewport sizes in mind. It’s just so darn tempting to think that way. You have a couple of pretty specific screen sizes in front of you right now, you likely design toward those to some degree. Design tools often ask you to draw a rectangle that represent a screen to design for. Testing tools sometimes show you a site at a set of pre-set screen sizes. It can feel normal and fine to design toward, say, three sizes, and hone in on them. Honestly, that might end up working fine, but it might not! It might lead to some awkward in-betweens, especially if you are very rigid in writing CSS that only changes at those specific breakpoints only.
That’s the thing, really. You just don’t have to think in really specific breakpoints anymore. Media query width breakpoints are still a fine tool, but now we’ve got viewport units, container units, container queries, calc/min/max/clamp, and all sorts of other stuff that allow you to design components and pages that work well and look good at the size and under the conditions they are in. It’s just a better way to code. But this stuff has only relatively recently arrived in CSS so it’ll take a minute for it all to settle in.
This isn’t even really new news. Over a decade ago, I was like, yo, there are a ton of different sizes that your site is getting viewed at. Deal with it. Now we can properly.
Have websites gone to crap? Browse around popular sites, and I think you’ll land on an easy yes. Especially on mobile, cripes. Just to name a few: they are too slow to load, the ads and popups are too obtrusive, and there is too much usage of fixed-position elements that reduce usable area.
This website User Inyerface satirized it recently, and it’s pretty funny (ya know, if being intentionally frustrated is your thing, gamers should relate).
People have been worried about this for ages, and it never seems to get any better.
- Brad Frost called it bullshit.
- A couple folks made termsandconditions.game mining these patterns for ideas.
- Guangyi Li’s how-i-experience-web-today.com gets at the heart of the complete experience.
- Tracking is a big part of this story, and clickclickclick.click pokes at that.
This all just makes me sad. Fortunately, most things are fine.
Have you seen the popover API? It’s a neat idea, already play-with-able in Chrome. Think styled tooltips. The idea is that you connect some interaction (click of a button) to toggling another element with more information or context. Amazingly, to me, this HTML totally works in Chrome with no CSS or JavaScript at all:
<button popovertarget="my-popover">Open Popover</button>
<div id="my-popover" popover>
<p>I am a popover with more information.</p>
</div>You can style stuff with CSS of course, but the basics of the interaction work without. Like a <details> element.
Anytime we get any form of “state management” outside of JavaScript, the people will play! There are countless games made in CSS thanks to the whole idea of the :checked selector in CSS and using the ~ combinator to select other elements.
This time, leave it to Garth Heyes who has made Tic-Tac-Toe entirely in HTML only. That’s gotta be a first.
Wanna see it? Fair warning first. It’s 170 MB (!!) of HTML and “over half a million nodes”. Chrome really struggles with this. It took my machine maybe near a minute to even render the first page, and each click took a while as well. If you’re down try it, see the demo.
So now that we’ve looked at something you absolutely shouldn’t do on the web, here’s Heather Buchel with some things you absolutely should do on the web. Heather ain’t even mad that we’re building websites with newfangled tech and trying to share code across platforms and all that, but, just, like, don’t break stuff. Don’t break super duper basic stuff that websites easily do and are good for everyone. I’ll hijack her whole list, but of course go read it for more context:
- Let me copy text so I can paste it.
- If something navigates like a link, let me do link things.
- Let me zoom in on my browser without the website getting all out of whack.
- Do responsive things.
- Let me have hover styles.
- If the UI completely changes when I click on something, as if I’ve navigated to a new page, give me a browser history update and a new URL.
- Let me see scroll bars.
- Stop hijacking my typical browser shortcuts for use in your own app.
Reasonable asks, no?
Onnnnneeee more thing you should be really careful about doing on the web. Adam Silver: The problem with sticky menus and what to do instead.
One problem is fairly obvious with sticky menus: they overlap stuff! They get in the dang way far too often.
But there are other things that cause problems that you might not see right away. Adam mentions zooming. One little zoom or too might kick a sticky/fixed element right off the page. Also, if something opens a sticky menu, and that menu happens to be taller than the viewport, you’ve got issues. You either need that area to be scrollable (but nested scrolling sucks) or you require users to scroll likely further than they want to just to see more of the menu. Ughghadk.
Adam lists three more that are just as bad or worse, and even less obvious at first glance. I’ll force you over there to see them. But I’ll snag the good ending, featuring the alternatives:
- Keep pages short: Sticky menus are a symptom of long pages so fix the root cause.
- Just let users scroll: It’s a myth that scrolling is a problem. Even on mobile, the top of the page is a flick or 2 away mostly.
- Put relevant links in context: For example, add a subscribe form to the end of a post or add a CTA to a pricing section.
- Use a back-to-top link: They’re relatively unobtrusive (but only do this once you exhaust the other options).
The post Chris’ Corner: Variations on What Not to Do appeared first on CodePen Blog.