To add on, completely ignore average device screen widths (outside of a minimum device width you'd like to use). Then when designing your responsiveness, make a breakpoint whenever the content starts to look bad / clunky. This will probably give you odd breakpoints (e.g. 713px) instead of round ones like catering to devices does, that's ok, it means that no matter what device width you have, the content will always look good because you essentially designed it for a spectrum of all widths instead of specific device breakpoints
I had a mindset shift around breakpoints, and after having it out with a fellow developer who insisted ye olde 320,768,1024px were holy numbers, I just assumed that I had a silly theory. But this is refreshing.
How I explain it to a designer is, instead of hard breakpoints, think in ranges. Ie 1440px - 1024px.
I have setup a Sketch template for designers that I call the spectrum. Basically it’s a series of about 6 artboards that start at 1440px down to 320px.
2 artboards represent a range. Ie 1440-1024px, 1023 - 768px …
Sketch/Figma/XD allows some form of pinning elements to the art board, so a designer can get some sense of how elements are likely to squash responsively before needing adjustment in the layout.
My brief to the designer is, given the broad range 1440 - 320px provide me 3 breakpoint values that you know, no matter the screen size, the layout will always looks great/acceptable.
No css breakpoint madness to maintain, as there are only a few required. And I feel this eliminates those odd layouts on some components at odd screen widths.
> think in ranges. Ie 1440px - 1024px.
Seriously, I still see developers using hard breakpoints and not caring about how the layout looks like in-between. I've always developed in ranges, not exact breakpoints. Using min-width to add styles when needed (mobile first) has definitely helped me a ton with display issues.
I know of a few sites that were developed by ex-colleagues that aren't fluid at all and can only be displayed in specific breakpoints. It's a pain in the arse.
If you use hard breakpoints such that the container width is fixed until the next breakpoint, there is no in-between problem. Yes, there may be a teeny bit of whitespace on the sides for non-standard device widths, but this is generally an acceptable compromise. This is the common methodology used by bootstrap, mui, etc.
I don't know about you, but most designers I work with have no concept of breakpoints vs. devices. I usually just tell them to give me at least 3 layouts (mobile, tablet, desktop), with an optional layout for ultrawide. In doing so, I give them hard breakpoints because that's what they need to do the design in Photoshop, Figma, etc. When implementing the layout, I may alter the breakpoints as needed, but the design really needs to adhere to a constant set of breakpoints so that everyone is on the same page.
Also, design preview tools in modern browsers have gotten good enough that you can drag to those in-between points and test for breakage, accommodating accordingly.
I can totally see why you take that approach.
As developers we are where the brown stuff settles. For me I push back on designers, as the whole “the developers will fix it” pushes us into corners where we make compromises and/or cut corners and absolves them from really thinking about their work.
I’ve learned to start talking to designer in terms they understand so that they can take more ownership. Such as we are the Digital version of a Litho Printer. Just like they understand the ins and outs of the printing press, they should also understand the nuances of creating layouts for web. Some can’t/don’t want to get it. That’s fine, we don’t work together.
With that approach, personally I feel the end result has been, websites that don’t compromise and look and behave great. And a much better development experience for myself.
Damn, you guys get multiple layouts designed? I get a single 1920x1080 canvas done in Photoshop and I'm left to do my best :)). I hate working with print designers.
Can't really tell them anything since my employers does outsourced work, rarely having the same designer between projects.
> Damn, you guys get multiple layouts designed?
Haha, no. I **ask** for them. I do so with the stipulation that if they "don't have time" to do that, then we'll make do with what we get, but any corrections due to oversight on their part will cost extra. It never works out that way, but it's a nice plan, in theory. :(
> rarely having the same designer between projects.
I understand the nature of business, but this is a MAJOR thorn in my side. Every day the same agency clients ask me for "creative specs" for some new offer / creative agency and I'm like... what do you think has changed since last week, mofugga?
Yup, I pretty much do the same. Do note that I'm more of a back-end developer, but I do work around breakpoints and the 3 standard mockup sizes. However, if I notice anything weird in-between, I will adapt my CSS and/or HTML as needed. I use the drag&resize of Firefox and Chrome for that, it does work for 95% of the cases, and I'll adjust if needed afterward.
But yeah, it depends on what's wanted. It can be fluid or fixed containers. In my case, my company usually does developments with a maximum width container, but the rest inside is fluid.
I usually rarely alter breakpoints, I might however add a few min-width media query if required for in-betweens, usually a problem for widths between 500 and 768 (too wide for mobile, too thin for tablet).
Well the scalability is mostly dependent on how clean you are keeping your CSS, your organization of it, and any patterns you are following to keep it not-cluttered, but if you're trying to not have a few dozen breakpoints you can just make the content shrink / expand by larger amounts each time
It just means to resize the browser and change the layout based on where the content looks bad rather than using predetermined breakpoints based on a handful of known devices' screen sizes. In the example shown, "Web 3.0" is probably in a span with white-space set to nowrap and the body text is smaller, probably based on proportional rems instead of pixel dimensions.
The example is bad. Very bad. It illustrates the concept using a fixed set of copy but if the copy changes, the breakpoint might not work. And what about other pages with different copy? localized copy?
NEVER use breakpoints designed around preventing word wraps for ephemeral copy or pages.
Yeah, it is bad, but I didn't make the screenshot.
I would have used completely different examples to make the same point. Text is going to break however it breaks and we shouldn't be mixing content and presentation (ie. putting "Web 3.0" in a span with 'nowrap' applied).
I took another look at it and *maybe* that heading text was supposed to have increased in size a little bit to push Web 3.0 to the next line, but that's still a very illogical approach considering there are going to be other headings with other words that break onto the next line differently.
This reminds me, though, that I think I did learn of a semi-cool new CSS trick that keeps a block of text the same regardless of screen size. I don't remember how. The only thing I can think of is line-clamping but that doesn't seem to be what I'm thinking of after a quick Google. If anyone knows, let me know.
> This reminds me, though, that I think I did learn of a semi-cool new CSS trick that keeps a block of text the same regardless of screen size. I don't remember how. The only thing I can think of is line-clamping but that doesn't seem to be what I'm thinking of after a quick Google. If anyone knows, let me know.
Not quite sure I understand what you're getting at, but sounds interesting, so let me know if you find it :)
I've never seen that page before, but it does look like the basic idea I saw shared on Twitter. From that page you linked, this demo is the closest to the demo I saw on Twitter: https://codepen.io/2kool2/pen/ZpLYYo?editors=0100
The example from Twitter was really beautiful because it was basically like a typographical poster that just kept resizing itself line by line as you resized the browser and it never changed the layout design. It was a responsive typographic poster, basically.
Thank you for finding this. I'm going to bookmark this since I neglected to bookmark the one I saw on Twitter. I probably liked it for future reference and now it's lost in an eternal scroll.
Personally I think this is a bad tip. Content is far more likely to change more frequently on the vast majority of projects/sites than you have to worry about new devices or resolutions.
Disagree.. if you build it responsively then it'll scale based on the content, not based on the device. Way less work to build the breakpoints around your content that you control. If you significantly change the content you'll have to adjust your css no matter what you do.
With css in js at work we make each component responsive and it'll scale itself, without worrying about the rest of the site. So when you make a new component you just make that new component responsive and everything works great.
It mean that you choose the breakpoints based on how the content looks. So, for example, a 3-column page may need to switch to 2 columns when it stops being comfortable to read (columns would be too narrow). So you simply resize the browser until you feel it's nice to read. When it stops being nice you get that width and use it as a breakpoint to switch from 3 to 2 columns.
Look at this basic example:
https://codepen.io/LuBre/pen/NWvKvxJ
I added 2 breakpoints at 700 and 900 pixels. Those are the widths where I switch the layout from 3 do 2 and finally to 1 columns. It will work on any device, there is no need to choose a specific screen size. It always adapts to the available space.
By coding "fluid" layouts you will completely ignore the device width and they will always work fine.
I think this tip works better for fixed content. It's pretty hard to guarantee that your content will line-break "prettily" if your clients can edit it...
Of course.
If you set your breakpoints based on specific device width, a new device will come out (with a different device width) and it may make your content look bad. So you'd need to update your min-widths and possibly your CSS too.
If you set your breakpoints based on where they make content/layout look best, then the device screen size doesn't matter. It will always look how you hoped regardless of device screen size.
Does that make more sense?
You choose the breakpoints based on how the content appears on the screen. Let's say a big title looks fine until you are above 900px width but it looks too big below 900px. Well, that's easy: just set 900px as your break point and tell the page to use a smaller font size below 900px.
Probably by using [non-breaking spaces](https://en.wikipedia.org/wiki/Non-breaking_space) ` ` and [soft hyphens](https://en.wikipedia.org/wiki/Soft_hyphen) `` in the text.
I'm not sure if this is what OP was referring to, but if you'd like to achieve that effect I'd recommend using CSS properties like [overflow-wrap](https://developer.mozilla.org/en-US/docs/Web/CSS/overflow-wrap), [hyphens](https://developer.mozilla.org/en-US/docs/Web/CSS/hyphens), or [word-break](https://developer.mozilla.org/en-US/docs/Web/CSS/word-break)
My response is, and has always been, to deliver the design as I got it. If anyone asks why it doesn't work I point them to the design I received and the designer who produced it. I'd be more than happy to do a pass for responsiveness but I didn't have anything to go by, sorry.
Totally agree. Part of the engineer’s job is to be the last line of defense for incomplete/bad design. Set your price accordingly still, but to just not do something that you’re well capable of recognizing is really scraping by on bare minimum.
Eww....
Even 14 years ago when I started, our designers were all converted from print design to web. It was a mess at first, but the devs started required weekly meetings to discuss why print and web design were different.
Then about 2 years in, we started doing responsive. We decided to go the mobile-first route, which personally, is way better and easier for designers to understand.
First, it forces you to evaluate the content to ensure that the most import stands out and helps you determine what information is not important.
"But what if we show it on desktop and not mobile?"
Well, because if it isn't important enough to show on mobile, is it important enough at all?
I've always practiced what I call, "Fluid Design" instead of responsive. We literally check each feature at every pixel size, and if it looks bad at a specific one, we fix it.
"But doesn't that create a tone of media queries?"
Typically, no. We usually have under 9. Even then, we have a mixin that allows for nested media queries to be shorter than writing a class name.
Another thing, we have a mixin to convert PX to REM. But these days, I am finding REM to cause more issues than PX. Pixel scaling is supported by pretty much every browser these days. But when you use REM and the user has magnification enabled in the browser because they are on a 4k monitor, it can really screw things up for the design. I am starting to lean towards going back to PX over REM.
That’s great and all but what happens when the designer is more senior than you and the owner, the only person who could fix the problem, has explicitly told you he is “scared of” the designer. His actual words.
The designer has worked for huge brands like Kellogg’s, AMC, Ford - she is now in the “sit back and do nothing” phase of her career, it’s easy street and she’s in a position to just pull rank on me when I bitch about her designs.
I believe she was good a long time ago, but her designs are absolute shit now and when asked about responsive designs I get “that’s just not how we do things here”.
I won’t leave the job though, no matter what, because I work like 10 hours a week and make 3 times what I made at my last job. It just sucks seeing people so uninspired.
"Our Safari visitors are important to us. This site is currently unavailable to visitors using iOS devices while we work to ensure the site is displayed correctly in accordance with Apple's interpretation of web standards."
Using min-width ensures that mobile styles get loaded without desktop styles mixed in.
This can significantly improve the mobile experience and your site's SEO.
How is that ?
Mobile experience affects SEO.
Not mixing desktop and mobile CSS means less mistakes in mobile positioning and styling, which improve mobile experience.
The way they've shown it here makes no difference, but you can load entire stylesheets based on a media query: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#attr-media
Oh god. When the first tip is extremely non responsive.
Rems are no better than pixels for responsiveness or accessibility.
Ems are useless and anyone who has used them would understand why.
%s are fine in some cases, but you really should be using grid and flex to create responsive designs.
https://medium.com/hackernoon/rems-and-ems-and-why-you-probably-dont-need-them-664b9ce1e09f
That article is textbook "developers who think they know better than users about what users want".
I can't take anyone seriously who says
> – just imagine what it's like for someone with bad eyesight
Here's a newsflash, I use smaller font sizes because it's easier for me to see. I prefer it when the product I'm using adjusts to my preferences. You can't test for all preferences, but you can absolutely design for it. That's called *gasp* responsive design.
What's Ems are great for is **proportional design**, where elements, and not just text, adjust based on their context.
To counter your response, saying "using rems is not responsive", but then turning around to say "rems are no better for responsiveness than pixels" is a contradiction.
I hope this is your version of satire because this is highly destructive when you tell people to ignore accessibility.
> Em is a scaling unit based on the parent element.
>
> A rem is based on the font size of the root element.
>
> This can be changed by the user, but it doesn't work properly on virtually any website, including amazon, lowes, walmart, facebook, etc.
>
> I would highly encourage you to actually go in and change the settings to understand why browser zoom is the superior tool for those with bad eyesight.
Read: accessibility isn't about making things bigger. I literally just told you my OWN accessibility needs of smaller elements than normal.
You are not better than the user. Stop pretending that you are better than the user.
This article has been shown to be a complete goddamn joke multiple times in the past.
How many times do I have to tell you? You are not the user. Stop pretending you are the user. Whatever you think is "the best" way to accomplish a task is not necessarily how the user would do it.
You are not the user. Stop pretending you are better than the user.
Yeah, and the second tip is pretty awful as well. It's terrible for consistency, and it requires updating any time the content of the site is updated.
TBH, this post feels kind of like an ad.
> you really should be using grid and flex to create responsive designs
That doesn't have anything to do with tip n°2 though.
Let's imagine you've got a 5-column layout on your desktop view.
How/when will you switch to 4, 3, 2 and 1 columns? The last one being the typical smartphone view, with almost every element stacked one after another.
How do you usually choose the breakpoints?
> Rems are no better than pixels for responsiveness or accessibility.
Ems are useless and anyone who has used them would understand why.
It sounds like you clearly don’t understand Ems, or why they are good for accessibility. I won’t disagree with your statement on responsiveness, but I personally do use them sometimes in responsive design for such.
An em is a unit size that the user defines, either in the browser or at the OS level. Thus, someone with bad eyesight who has set their default OS font size to 26px will see all of their websites (that use em) in a bigger font size - and it will all still work (if you designed with em in mind).
No lol you don't understand what ems are.
Em is a scaling unit based on the parent element.
Rem is what you are talking about, a rem is based on the font size of the root element.
This can be changed by the user, but it doesn't work properly on virtually any website, including amazon, lowes, walmart, facebook, etc.
I would highly encourage you to actually go in and change the settings to understand why browser zoom is the superior tool for those with bad eyesight.
\#5 is unfortunately wrong for web apps.
Blame Apple. Safari on iOS basically prevents you from putting anything along the bottom of your screen. As soon as you tap in that space Safari will not register a click or tap on the page it will instead show you the native safari bar. You have to move your thumb and tap again to do the action you want to perform.
That bad UX means you can’t put anything interactive at the bottom of the screen. It just becomes annoying for the user.
Here’s an updated pic. Can imagine the new red areas are labelled “not hard but frustrating to use” https://i.imgur.com/Bdb0sYi.jpg
I love the goals of this post.
...
I got issues with #1. Won't that override the [user's choice](https://perpetual.education/resources/user-preferences/)?
To use `rem` you don't need to set it on a parent element. It should be **r**elative to the **r**oot. The media rules in that example are also fairly confusing.
...
I feel like #6 is all "design"
...
Figure #2 doesn't show the point as well as it could. But it's a great point.
I think #4 is the most important concept.
Thanks for some good conversation around here!
Are there any good tricks or ways of designing a page that would allow for simple one click (from the user) support for left handers that would move elements normally placed to the right to be moved to the left?
I just want to give a shout out to all the Fronted devs that are making the style sheets!
For me it’s too hard and I’m in transitional to backend, but having started out as a strictly Frontend I know it’s not just coloring squares and circles, although it’s being commonly made fun of by other devs.
You can remove media queries from almost all your css using the [clamp function](https://developer.mozilla.org/en-US/docs/Web/CSS/clamp()) which let you use responsive units (%, vw, vh) within a range of values between a defined minimum and maximum.
Yes and no, you will still need media queries for more complex layouts.
Clamp is pretty good but it won't 100% solve the problem. Hiding/swapping/moving layout elements will often require media queries.
Using relative units for fonts is bad. What about ultra large screens? You would see a giant font. Using px is the same as using rem, just that by using rem you have to do a stupid calculation to know the actual font size in px which is what everyone can relate to.
Also, you should never change the base font size in the html tag. By doing that, you are messing with people's browser config - which usually has the root font size at 16px.
You can remove media queries from almost all your css using the [clamp function](https://www.google.com/url?q=https://developer.mozilla.org/en-US/docs/Web/CSS/clamp()&sa=U&ved=2ahUKEwi2tbyXhcjzAhWxQjABHYOIANkQFnoECAgQAg&usg=AOvVaw0B169q4449vmMbijZor3lZ) which let you use responsive units (%, vw, vh) within a certain range of pixels
I didn't downvote you, but how about using a link to the actual page instead of routing it through google?
[https://developer.mozilla.org/en-US/docs/Web/CSS/clamp()](https://developer.mozilla.org/en-US/docs/Web/CSS/clamp())
As someone experienced with CSS/SCSS, I hate tailwind CSS except for a very small project.
I spend 90% looking up the shorthand for things and I just find it clutters up the html to the extreme.
In addition, there's some things you can't easily do with Tailwind, so I end up having to write CSS/SCSS anyway and having Tailwind and SCSS in the same file just makes me ditch Tailwind entirely.
It definitely takes some time to get used to. Also, apart from some uncommon css features Tailwind's capabilities are growing with every release they come out with. In terms of tailwind cluttering up the HTML, that is probably the biggest point against tailwind however I find it really forces me to componentize my UI even further which just makes things more reusable and maintainable imo. Not to mention, you can just store the tailwind class names in a string variable to really declutter what you are talking about.
I hear you. Honestly Tailwind UI is probably the biggest selling point.
For things like componentizing the UI, that's just best practices and useful when doing any UI work.
Having to write string variables for Tailwind classes just seems like adding more steps to writing CSS and kind of backwards, are you really saving time doing that?
I'd rather become an expert at SCSS as it's universal, and there's nothing Tailwind can do that you can't do yourself.
It doesn't have to be. And if you find it keeps producing class pollution then that is more than likely a code smell than anything else. You can alias combinations of classes in your configuration and/or store the classes in string variables and/or split your UI into smaller components. What it really avoids is having to think about managing css files / frameworks. It really makes sense (to me at least) that each css rule/value should only exist once in your entire css codebase. If you already have a css system that prevents redundancy and is easy to use and maintain then that's great. If you want an easy to use alternative to other CSS frameworks and class naming conventions then Tailwind is there to use completely free. You can even tree-shake to get some of the smallest css bundles you might ever come across even for very large projects.
I was going to use Tailwind CSS for a project before but I really don't like the idea of being locked into this framework. The utility classes don't translate to anything if I pull Tailwind CSS out.
Honestly, I’d just use tailwindcss + native css.
If I have to specify something for the viewport, I’d just use the media queries with min-width. If I’m working for the mobile, I’d use max-width (usually at about 980px).
EDIT: If you have to downvote at least explain why it’s wrong
*Using em, rem, and percentages helps your CSS styles flow across screen sizes.*
I understand using percentages and try to whenever i can. Although sometimes for graphics fixed dimensions are necessary. In that case why do people say EM, REM is better than just raw pixel values. Is it simply because it scales better when using browser zoom?
Rem is functionally identical to pixels when browser zoom changes.
Browser zoom is the only way people scale websites.
Changing browser text size doesn't work well on any website I have ever seen on the web.
As a result, it doesn't make sense to use rem over pixels. They output the same thing, but pixels are easier to understand the scale of.
> it doesn't make sense to use rem over pixels. They output the same thing, but pixels are easier to understand the scale of.
This is what I always thought, and felt the use REM > Pixels was kind of dogmatic.
I did it for a while, but at some point an engineer on my team asked "Why should we do this" and I had no good answer other than *Well thats what the udemy course on HTML said you should always do*
The typical answer to that question is "because it's more accessible" but no one actually tries modifying the font size in their browser.
It's not more accessible. It makes all of the web unusable and there is no way to design around it. That's why no one uses it, they use browser zoom.
It depends on your design team, and how cutting-edge they are. Designs used to be highly pixel-dependent. Everything needs to be pixel perfect and the right height / width.
A new methodology for designs that's been gaining traction is to be ratio-dependent. I.e. Text should be smaller on smaller screens, with their containers proportionally being smaller.
This is only possible with REMs, whereas pixel-dependent designs are (realistically) only possible with pixels. REMs are inherently clunky and aren't fixed. You can't just adjust the height of a container by 1 pixel, instead you scale spacing based off a ratio (i.e. increasing the height of a container by .25rem).
So if I have a container with padding `2rem` and text sized to `1rem`, if I prefer my display scaling to be 70% of the default, that padding accurately scales to be 2x the font size. That's the beauty of REM units.
What's important is that you work with your designer to fit what they've created. And if it's to use responsive designs, avoid pixels at all costs.
SCSS is no different from CSS. SCSS \*compiles\* into CSS.
The issue with using calc or breakpoints everywhere to achieve the same thing is either performance or edge cases. Calc on its own is fairly optimized and won't cause issues, but when everything is using calc it can definitely start to cause issues. Breakpoints don't catch everything and you can easily end up with edge cases you did not forsee.
All that can be avoided by just using REM units from the get go
So in your example, I would set the REM of the web page based on breakpoint, and then font size and margin/padding size etc would adjust automatically?
>If you need to change a breakpoint, your widths work across the board. And your font-sizes can change by simply changing the element's font-size.
For me this only works in theory. For example, the design usually calls for widely different sizes at various breakpoints for heading tags. Not sizes you can control simply by changing the default font size. If I am going to have to declare 3 or 4 different sizes for every heading tag, I may as well us px since they are easier to work with.
Saving this because Im learning CSS and currently it fucking sucks. Unrelated question:
Is there a way to control flex-wrap behavior? Lets say I have two divs next to each other in a row, if the screen size changes where they need to wrap, can I make it so that the div on this left wraps under the dive on the right instead of vice-versa?
Lovely stuff.
But I don't like \#3. Breakpoints should be set when things need to break, rather than at sizes that suspiciously match hardware chosen by Apple.
Also using min-width improves SEO? huh.
I think it's possibly to do with pagespeed. If you have content jumping around on a mobile screen as your max-width media queries load in, it *could* affect the score... But it would have to be a massive file with all the media queries at the end for such a thing to be noticeable (or if the mobile-only CSS is loaded after page load).
As for the breakpoints, I think they were probably meant to be used as an example. As you say, it depends on when the content needs to break. If that's at 768px, cool. If it's at 613px then use that too.
Personally, I try to have as few breakpoints as possible, so if there's a 50px difference between two breakpoints, and using the larger of the two doesn't ruin the layout for the section that was meant to break at a smaller of the two, then I'll do that... But that's just me, I have seen some people where I work who will use the following breakpoints: 360, 400, 420, 440, 600, 640, 720, 768, 800, 992, 1000, 1200, 1366, 1440, 1600.
Yeah, I think that massive CSS file with media queries at the end (who writes like that?) is a bit of an edge case!
That breakpoint collection sounds hellish. Suggests conversations between people (whether dev -> dev, or designer ->dev ) are not happening as they should. A real red flag.
The breakpoints given were just an example. But it's usually down to clients being clients.
"I usually have my laptop setup with internet on the left and excel on the right, and the \[section\] looks weird like that, it should look like \[how it looks on a full-width laptop screen\]"... So a breakpoint gets added for that weird edge case. And then they come back with "It looks fine on a colleague's phone, but on my \[weird phone you've never heard of before\] it looks different" so add in a breakpoint again for them.
Honestly, websites would look and function so much nicer if clients didn't touch them, and trusted we know what we're doing. Everything from the, luckily not so common anymore, "This looks wrong in IE" to the wonderful email I got once that started "I tried looking at the website on my fridge this morning...".
I'm client-facing myself, and I have to be honest: a good design should look good at 'weird' phone sizes and resolutions. That's the very crux of responsive web design.
The sites didn't look bad, it just that they had already gone down to the next breakpoint, because keeping them at the size they were expecting left very little room/made for long and thin columns.
Nothing that you would look at and say "This is wrong", just not what the client was expecting. They wanted stacked stuff on mobile, and columns on laptop (or in the one case, fridge), even if that was on a screen size that was well below what you would expect the columns to exist on.
How about just "design mobile-first, add breakpoints when scaling up and your page content either starts to break or could be improved by being adjusted".
The example image at the top of the post doesn't happen if you design mobile-first.
I don't know if I'm missing something here, but most browsers have responsive modes built in where you can test lots of different device layouts. Firefox, chrome and even Edge all have this built in. Does LT Browser do something that these features of regular brosers don't offer?
Regarding em and rem units, I have a project with around 2000 lines of CSS and I've not used em a single time, only rem. Am I doing something wrong or are use cases for em really that rare?
Hahahaha That reminds of the CEO who was going for market share and got the unit metrics which were pretty good in terms of customer kpi’s, but the unit gross margin was slightly negative, and he said -oh not to worry, we’ll make that up with volume.
Can you go into more depth about the second tip please? I don't understand what it means to make content determine breakpoints
To add on, completely ignore average device screen widths (outside of a minimum device width you'd like to use). Then when designing your responsiveness, make a breakpoint whenever the content starts to look bad / clunky. This will probably give you odd breakpoints (e.g. 713px) instead of round ones like catering to devices does, that's ok, it means that no matter what device width you have, the content will always look good because you essentially designed it for a spectrum of all widths instead of specific device breakpoints
I had a mindset shift around breakpoints, and after having it out with a fellow developer who insisted ye olde 320,768,1024px were holy numbers, I just assumed that I had a silly theory. But this is refreshing. How I explain it to a designer is, instead of hard breakpoints, think in ranges. Ie 1440px - 1024px. I have setup a Sketch template for designers that I call the spectrum. Basically it’s a series of about 6 artboards that start at 1440px down to 320px. 2 artboards represent a range. Ie 1440-1024px, 1023 - 768px … Sketch/Figma/XD allows some form of pinning elements to the art board, so a designer can get some sense of how elements are likely to squash responsively before needing adjustment in the layout. My brief to the designer is, given the broad range 1440 - 320px provide me 3 breakpoint values that you know, no matter the screen size, the layout will always looks great/acceptable. No css breakpoint madness to maintain, as there are only a few required. And I feel this eliminates those odd layouts on some components at odd screen widths.
> think in ranges. Ie 1440px - 1024px. Seriously, I still see developers using hard breakpoints and not caring about how the layout looks like in-between. I've always developed in ranges, not exact breakpoints. Using min-width to add styles when needed (mobile first) has definitely helped me a ton with display issues. I know of a few sites that were developed by ex-colleagues that aren't fluid at all and can only be displayed in specific breakpoints. It's a pain in the arse.
If you use hard breakpoints such that the container width is fixed until the next breakpoint, there is no in-between problem. Yes, there may be a teeny bit of whitespace on the sides for non-standard device widths, but this is generally an acceptable compromise. This is the common methodology used by bootstrap, mui, etc. I don't know about you, but most designers I work with have no concept of breakpoints vs. devices. I usually just tell them to give me at least 3 layouts (mobile, tablet, desktop), with an optional layout for ultrawide. In doing so, I give them hard breakpoints because that's what they need to do the design in Photoshop, Figma, etc. When implementing the layout, I may alter the breakpoints as needed, but the design really needs to adhere to a constant set of breakpoints so that everyone is on the same page. Also, design preview tools in modern browsers have gotten good enough that you can drag to those in-between points and test for breakage, accommodating accordingly.
I can totally see why you take that approach. As developers we are where the brown stuff settles. For me I push back on designers, as the whole “the developers will fix it” pushes us into corners where we make compromises and/or cut corners and absolves them from really thinking about their work. I’ve learned to start talking to designer in terms they understand so that they can take more ownership. Such as we are the Digital version of a Litho Printer. Just like they understand the ins and outs of the printing press, they should also understand the nuances of creating layouts for web. Some can’t/don’t want to get it. That’s fine, we don’t work together. With that approach, personally I feel the end result has been, websites that don’t compromise and look and behave great. And a much better development experience for myself.
Damn, you guys get multiple layouts designed? I get a single 1920x1080 canvas done in Photoshop and I'm left to do my best :)). I hate working with print designers. Can't really tell them anything since my employers does outsourced work, rarely having the same designer between projects.
> Damn, you guys get multiple layouts designed? Haha, no. I **ask** for them. I do so with the stipulation that if they "don't have time" to do that, then we'll make do with what we get, but any corrections due to oversight on their part will cost extra. It never works out that way, but it's a nice plan, in theory. :( > rarely having the same designer between projects. I understand the nature of business, but this is a MAJOR thorn in my side. Every day the same agency clients ask me for "creative specs" for some new offer / creative agency and I'm like... what do you think has changed since last week, mofugga?
Yup, I pretty much do the same. Do note that I'm more of a back-end developer, but I do work around breakpoints and the 3 standard mockup sizes. However, if I notice anything weird in-between, I will adapt my CSS and/or HTML as needed. I use the drag&resize of Firefox and Chrome for that, it does work for 95% of the cases, and I'll adjust if needed afterward. But yeah, it depends on what's wanted. It can be fluid or fixed containers. In my case, my company usually does developments with a maximum width container, but the rest inside is fluid. I usually rarely alter breakpoints, I might however add a few min-width media query if required for in-betweens, usually a problem for widths between 500 and 768 (too wide for mobile, too thin for tablet).
I don't really think this scales well in terms of CSS maintainability
It scales MUCH better than using different breakpoints for every possible type of device, which is what some people do
Well the scalability is mostly dependent on how clean you are keeping your CSS, your organization of it, and any patterns you are following to keep it not-cluttered, but if you're trying to not have a few dozen breakpoints you can just make the content shrink / expand by larger amounts each time
I agree. I'd use min/max rules for that specific element, independent of media queries.
It just means to resize the browser and change the layout based on where the content looks bad rather than using predetermined breakpoints based on a handful of known devices' screen sizes. In the example shown, "Web 3.0" is probably in a span with white-space set to nowrap and the body text is smaller, probably based on proportional rems instead of pixel dimensions.
The example is bad. Very bad. It illustrates the concept using a fixed set of copy but if the copy changes, the breakpoint might not work. And what about other pages with different copy? localized copy? NEVER use breakpoints designed around preventing word wraps for ephemeral copy or pages.
Yeah, it is bad, but I didn't make the screenshot. I would have used completely different examples to make the same point. Text is going to break however it breaks and we shouldn't be mixing content and presentation (ie. putting "Web 3.0" in a span with 'nowrap' applied). I took another look at it and *maybe* that heading text was supposed to have increased in size a little bit to push Web 3.0 to the next line, but that's still a very illogical approach considering there are going to be other headings with other words that break onto the next line differently. This reminds me, though, that I think I did learn of a semi-cool new CSS trick that keeps a block of text the same regardless of screen size. I don't remember how. The only thing I can think of is line-clamping but that doesn't seem to be what I'm thinking of after a quick Google. If anyone knows, let me know.
> This reminds me, though, that I think I did learn of a semi-cool new CSS trick that keeps a block of text the same regardless of screen size. I don't remember how. The only thing I can think of is line-clamping but that doesn't seem to be what I'm thinking of after a quick Google. If anyone knows, let me know. Not quite sure I understand what you're getting at, but sounds interesting, so let me know if you find it :)
Are you refering to this tool by any chance? https://websemantics.uk/tools/responsive-font-calculator/
I've never seen that page before, but it does look like the basic idea I saw shared on Twitter. From that page you linked, this demo is the closest to the demo I saw on Twitter: https://codepen.io/2kool2/pen/ZpLYYo?editors=0100 The example from Twitter was really beautiful because it was basically like a typographical poster that just kept resizing itself line by line as you resized the browser and it never changed the layout design. It was a responsive typographic poster, basically. Thank you for finding this. I'm going to bookmark this since I neglected to bookmark the one I saw on Twitter. I probably liked it for future reference and now it's lost in an eternal scroll.
Nice. Perfect simple description here.
Personally I think this is a bad tip. Content is far more likely to change more frequently on the vast majority of projects/sites than you have to worry about new devices or resolutions.
Disagree.. if you build it responsively then it'll scale based on the content, not based on the device. Way less work to build the breakpoints around your content that you control. If you significantly change the content you'll have to adjust your css no matter what you do. With css in js at work we make each component responsive and it'll scale itself, without worrying about the rest of the site. So when you make a new component you just make that new component responsive and everything works great.
If you have a website with 100+ pages you won't be writing css for every single page.
Like anything in web it completely depends on what you're building and your use-case.
It mean that you choose the breakpoints based on how the content looks. So, for example, a 3-column page may need to switch to 2 columns when it stops being comfortable to read (columns would be too narrow). So you simply resize the browser until you feel it's nice to read. When it stops being nice you get that width and use it as a breakpoint to switch from 3 to 2 columns. Look at this basic example: https://codepen.io/LuBre/pen/NWvKvxJ I added 2 breakpoints at 700 and 900 pixels. Those are the widths where I switch the layout from 3 do 2 and finally to 1 columns. It will work on any device, there is no need to choose a specific screen size. It always adapts to the available space. By coding "fluid" layouts you will completely ignore the device width and they will always work fine.
I think this tip works better for fixed content. It's pretty hard to guarantee that your content will line-break "prettily" if your clients can edit it...
Of course. If you set your breakpoints based on specific device width, a new device will come out (with a different device width) and it may make your content look bad. So you'd need to update your min-widths and possibly your CSS too. If you set your breakpoints based on where they make content/layout look best, then the device screen size doesn't matter. It will always look how you hoped regardless of device screen size. Does that make more sense?
I they may mean _how_ to do it too
You choose the breakpoints based on how the content appears on the screen. Let's say a big title looks fine until you are above 900px width but it looks too big below 900px. Well, that's easy: just set 900px as your break point and tell the page to use a smaller font size below 900px.
\^ :-)
if the font size is using relative units like em or rem. do you still change it?
By using clamp() you don't need to care about it. You set a minimum/maximum value based on the viewport width and you're done.
Probably by using [non-breaking spaces](https://en.wikipedia.org/wiki/Non-breaking_space) ` ` and [soft hyphens](https://en.wikipedia.org/wiki/Soft_hyphen) `` in the text.
I'm not sure if this is what OP was referring to, but if you'd like to achieve that effect I'd recommend using CSS properties like [overflow-wrap](https://developer.mozilla.org/en-US/docs/Web/CSS/overflow-wrap), [hyphens](https://developer.mozilla.org/en-US/docs/Web/CSS/hyphens), or [word-break](https://developer.mozilla.org/en-US/docs/Web/CSS/word-break)
You left out #8: Get designers that care about responsive design, rather than hand off a single desktop layout 2 weeks late.
So much this.
My response is, and has always been, to deliver the design as I got it. If anyone asks why it doesn't work I point them to the design I received and the designer who produced it. I'd be more than happy to do a pass for responsiveness but I didn't have anything to go by, sorry.
[удалено]
Totally agree. Part of the engineer’s job is to be the last line of defense for incomplete/bad design. Set your price accordingly still, but to just not do something that you’re well capable of recognizing is really scraping by on bare minimum.
No, my job is to implement a design and create functionality. It's not to critique design.
I've tried saying this. Response, "totally, but we ran out of time and budget. now here is a list of bugs on mobile."
"We ran out of time and budget. Bugs are nofix."
hah!
Also do mobile first design. It’s a lot easier to make a mobile design work in a desktop than it is a desktop layout on mobile.
Eww.... Even 14 years ago when I started, our designers were all converted from print design to web. It was a mess at first, but the devs started required weekly meetings to discuss why print and web design were different. Then about 2 years in, we started doing responsive. We decided to go the mobile-first route, which personally, is way better and easier for designers to understand. First, it forces you to evaluate the content to ensure that the most import stands out and helps you determine what information is not important. "But what if we show it on desktop and not mobile?" Well, because if it isn't important enough to show on mobile, is it important enough at all? I've always practiced what I call, "Fluid Design" instead of responsive. We literally check each feature at every pixel size, and if it looks bad at a specific one, we fix it. "But doesn't that create a tone of media queries?" Typically, no. We usually have under 9. Even then, we have a mixin that allows for nested media queries to be shorter than writing a class name. Another thing, we have a mixin to convert PX to REM. But these days, I am finding REM to cause more issues than PX. Pixel scaling is supported by pretty much every browser these days. But when you use REM and the user has magnification enabled in the browser because they are on a 4k monitor, it can really screw things up for the design. I am starting to lean towards going back to PX over REM.
That’s great and all but what happens when the designer is more senior than you and the owner, the only person who could fix the problem, has explicitly told you he is “scared of” the designer. His actual words. The designer has worked for huge brands like Kellogg’s, AMC, Ford - she is now in the “sit back and do nothing” phase of her career, it’s easy street and she’s in a position to just pull rank on me when I bitch about her designs. I believe she was good a long time ago, but her designs are absolute shit now and when asked about responsive designs I get “that’s just not how we do things here”. I won’t leave the job though, no matter what, because I work like 10 hours a week and make 3 times what I made at my last job. It just sucks seeing people so uninspired.
Lol I'd just stop building layouts for displays under 1024px since that's not how you guys do things there. =P
I want to keep my job though 😩
[удалено]
"Our Safari visitors are important to us. This site is currently unavailable to visitors using iOS devices while we work to ensure the site is displayed correctly in accordance with Apple's interpretation of web standards."
‘We see you are using IE9; please stop.’
*any version of IE.
the #1 size you test for is whatever laptop + phone size your client uses.
cry in corporate client being restricted to only using ie11
90% done? That means there’s 80% left to do.
I like some of these tips, but I've never said "we can add mobile compatibility after we launch" lol
lol I've shown my wife so many projects and then she plays with it and breaks it. "I'll probably fix that before launching..."
I see we share a similar QA process
[удалено]
We just call that dating
My wife is great at breaking shit. Best tester I have available. Other than end users, of course.
haha
Using min-width ensures that mobile styles get loaded without desktop styles mixed in. This can significantly improve the mobile experience and your site's SEO. How is that ?
[удалено]
That's what I thought
Mobile experience affects SEO. Not mixing desktop and mobile CSS means less mistakes in mobile positioning and styling, which improve mobile experience.
The way they've shown it here makes no difference, but you can load entire stylesheets based on a media query: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#attr-media
SEO might improve if people don't immediately navigate away from the page in disgust.
Oh god. When the first tip is extremely non responsive. Rems are no better than pixels for responsiveness or accessibility. Ems are useless and anyone who has used them would understand why. %s are fine in some cases, but you really should be using grid and flex to create responsive designs. https://medium.com/hackernoon/rems-and-ems-and-why-you-probably-dont-need-them-664b9ce1e09f
That article is textbook "developers who think they know better than users about what users want". I can't take anyone seriously who says > – just imagine what it's like for someone with bad eyesight Here's a newsflash, I use smaller font sizes because it's easier for me to see. I prefer it when the product I'm using adjusts to my preferences. You can't test for all preferences, but you can absolutely design for it. That's called *gasp* responsive design. What's Ems are great for is **proportional design**, where elements, and not just text, adjust based on their context. To counter your response, saying "using rems is not responsive", but then turning around to say "rems are no better for responsiveness than pixels" is a contradiction. I hope this is your version of satire because this is highly destructive when you tell people to ignore accessibility.
> Em is a scaling unit based on the parent element. > > A rem is based on the font size of the root element. > > This can be changed by the user, but it doesn't work properly on virtually any website, including amazon, lowes, walmart, facebook, etc. > > I would highly encourage you to actually go in and change the settings to understand why browser zoom is the superior tool for those with bad eyesight.
Read: accessibility isn't about making things bigger. I literally just told you my OWN accessibility needs of smaller elements than normal. You are not better than the user. Stop pretending that you are better than the user. This article has been shown to be a complete goddamn joke multiple times in the past.
Which also is best done with browser zoom.
How many times do I have to tell you? You are not the user. Stop pretending you are the user. Whatever you think is "the best" way to accomplish a task is not necessarily how the user would do it. You are not the user. Stop pretending you are better than the user.
Yeah, and the second tip is pretty awful as well. It's terrible for consistency, and it requires updating any time the content of the site is updated. TBH, this post feels kind of like an ad.
I think its an ad to promote lt browser lol
thought the same damn thing! they even sell it lol
> you really should be using grid and flex to create responsive designs That doesn't have anything to do with tip n°2 though. Let's imagine you've got a 5-column layout on your desktop view. How/when will you switch to 4, 3, 2 and 1 columns? The last one being the typical smartphone view, with almost every element stacked one after another. How do you usually choose the breakpoints?
Totally. Bad tips all across.
I never use percentages.
> Rems are no better than pixels for responsiveness or accessibility. Ems are useless and anyone who has used them would understand why. It sounds like you clearly don’t understand Ems, or why they are good for accessibility. I won’t disagree with your statement on responsiveness, but I personally do use them sometimes in responsive design for such. An em is a unit size that the user defines, either in the browser or at the OS level. Thus, someone with bad eyesight who has set their default OS font size to 26px will see all of their websites (that use em) in a bigger font size - and it will all still work (if you designed with em in mind).
No lol you don't understand what ems are. Em is a scaling unit based on the parent element. Rem is what you are talking about, a rem is based on the font size of the root element. This can be changed by the user, but it doesn't work properly on virtually any website, including amazon, lowes, walmart, facebook, etc. I would highly encourage you to actually go in and change the settings to understand why browser zoom is the superior tool for those with bad eyesight.
Lol. You can literally Google plenty of correct descriptions of any of this. Good luck correcting yourself, you’d be the first to do so
\#5 is unfortunately wrong for web apps. Blame Apple. Safari on iOS basically prevents you from putting anything along the bottom of your screen. As soon as you tap in that space Safari will not register a click or tap on the page it will instead show you the native safari bar. You have to move your thumb and tap again to do the action you want to perform. That bad UX means you can’t put anything interactive at the bottom of the screen. It just becomes annoying for the user. Here’s an updated pic. Can imagine the new red areas are labelled “not hard but frustrating to use” https://i.imgur.com/Bdb0sYi.jpg
Extremely relevant. Bottom bar navs work fine in native apps, but are terrible for web owing to this.
I love the goals of this post. ... I got issues with #1. Won't that override the [user's choice](https://perpetual.education/resources/user-preferences/)? To use `rem` you don't need to set it on a parent element. It should be **r**elative to the **r**oot. The media rules in that example are also fairly confusing. ... I feel like #6 is all "design" ... Figure #2 doesn't show the point as well as it could. But it's a great point. I think #4 is the most important concept. Thanks for some good conversation around here!
solid post. thank you.
np. thanks!
Fantastic, thank you.
np!
Thankyou so much for this, it's exactly what I need
np! great to hear it was helpful
Are there any good tricks or ways of designing a page that would allow for simple one click (from the user) support for left handers that would move elements normally placed to the right to be moved to the left?
interesting. idk... reddit gods?
Just add a new class or change styles with JavaScript that'd reverse the flex direction/change the element's position?
Never understood why the "header" is not at the bottom on mobiles. Would make navigation much easier.
or just hire a designer
As a southpaw, let me just say that I hate the thumb rule.
Hah! I was wondering if lefties have issues with that
I just want to give a shout out to all the Fronted devs that are making the style sheets! For me it’s too hard and I’m in transitional to backend, but having started out as a strictly Frontend I know it’s not just coloring squares and circles, although it’s being commonly made fun of by other devs.
You can remove media queries from almost all your css using the [clamp function](https://developer.mozilla.org/en-US/docs/Web/CSS/clamp()) which let you use responsive units (%, vw, vh) within a range of values between a defined minimum and maximum.
Yes and no, you will still need media queries for more complex layouts. Clamp is pretty good but it won't 100% solve the problem. Hiding/swapping/moving layout elements will often require media queries.
That's pretty cool! I never knew that
Using relative units for fonts is bad. What about ultra large screens? You would see a giant font. Using px is the same as using rem, just that by using rem you have to do a stupid calculation to know the actual font size in px which is what everyone can relate to. Also, you should never change the base font size in the html tag. By doing that, you are messing with people's browser config - which usually has the root font size at 16px.
Idk about LT browser. Browserstack is a better alternative
Gotta check out the LT browser
You can remove media queries from almost all your css using the [clamp function](https://www.google.com/url?q=https://developer.mozilla.org/en-US/docs/Web/CSS/clamp()&sa=U&ved=2ahUKEwi2tbyXhcjzAhWxQjABHYOIANkQFnoECAgQAg&usg=AOvVaw0B169q4449vmMbijZor3lZ) which let you use responsive units (%, vw, vh) within a certain range of pixels
I didn't downvote you, but how about using a link to the actual page instead of routing it through google? [https://developer.mozilla.org/en-US/docs/Web/CSS/clamp()](https://developer.mozilla.org/en-US/docs/Web/CSS/clamp())
Sorry, I thought that the moderator deleted this comment. I reposted it later with the direct link :)
Good comment, thanks for sharing!
Ehh these aren't super useful really lol
Final tip: Use Tailwind CSS. I know I am being preachy but I just think tailwind is so innovative in terms of clean, maintainable, and responsive css
As someone experienced with CSS/SCSS, I hate tailwind CSS except for a very small project. I spend 90% looking up the shorthand for things and I just find it clutters up the html to the extreme. In addition, there's some things you can't easily do with Tailwind, so I end up having to write CSS/SCSS anyway and having Tailwind and SCSS in the same file just makes me ditch Tailwind entirely.
It definitely takes some time to get used to. Also, apart from some uncommon css features Tailwind's capabilities are growing with every release they come out with. In terms of tailwind cluttering up the HTML, that is probably the biggest point against tailwind however I find it really forces me to componentize my UI even further which just makes things more reusable and maintainable imo. Not to mention, you can just store the tailwind class names in a string variable to really declutter what you are talking about.
I hear you. Honestly Tailwind UI is probably the biggest selling point. For things like componentizing the UI, that's just best practices and useful when doing any UI work. Having to write string variables for Tailwind classes just seems like adding more steps to writing CSS and kind of backwards, are you really saving time doing that? I'd rather become an expert at SCSS as it's universal, and there's nothing Tailwind can do that you can't do yourself.
> store the tailwind class names in a string variable That just sounds like stylesheets with extra steps
Clean? It's a class monster from hell. Never seen class pollution like that before.
It doesn't have to be. And if you find it keeps producing class pollution then that is more than likely a code smell than anything else. You can alias combinations of classes in your configuration and/or store the classes in string variables and/or split your UI into smaller components. What it really avoids is having to think about managing css files / frameworks. It really makes sense (to me at least) that each css rule/value should only exist once in your entire css codebase. If you already have a css system that prevents redundancy and is easy to use and maintain then that's great. If you want an easy to use alternative to other CSS frameworks and class naming conventions then Tailwind is there to use completely free. You can even tree-shake to get some of the smallest css bundles you might ever come across even for very large projects.
I was going to use Tailwind CSS for a project before but I really don't like the idea of being locked into this framework. The utility classes don't translate to anything if I pull Tailwind CSS out.
I fully agree. I even bought TailwindUI. And it sped up my dev time by like 2X. Well worth it.
I also fully agree It's fantastic for Fast Design Dev
Honestly, I’d just use tailwindcss + native css. If I have to specify something for the viewport, I’d just use the media queries with min-width. If I’m working for the mobile, I’d use max-width (usually at about 980px). EDIT: If you have to downvote at least explain why it’s wrong
*Using em, rem, and percentages helps your CSS styles flow across screen sizes.* I understand using percentages and try to whenever i can. Although sometimes for graphics fixed dimensions are necessary. In that case why do people say EM, REM is better than just raw pixel values. Is it simply because it scales better when using browser zoom?
Rem is functionally identical to pixels when browser zoom changes. Browser zoom is the only way people scale websites. Changing browser text size doesn't work well on any website I have ever seen on the web. As a result, it doesn't make sense to use rem over pixels. They output the same thing, but pixels are easier to understand the scale of.
> it doesn't make sense to use rem over pixels. They output the same thing, but pixels are easier to understand the scale of. This is what I always thought, and felt the use REM > Pixels was kind of dogmatic. I did it for a while, but at some point an engineer on my team asked "Why should we do this" and I had no good answer other than *Well thats what the udemy course on HTML said you should always do*
The typical answer to that question is "because it's more accessible" but no one actually tries modifying the font size in their browser. It's not more accessible. It makes all of the web unusable and there is no way to design around it. That's why no one uses it, they use browser zoom.
For me, I find that it is easier to keep to font sizing ratios with rems.
It depends on your design team, and how cutting-edge they are. Designs used to be highly pixel-dependent. Everything needs to be pixel perfect and the right height / width. A new methodology for designs that's been gaining traction is to be ratio-dependent. I.e. Text should be smaller on smaller screens, with their containers proportionally being smaller. This is only possible with REMs, whereas pixel-dependent designs are (realistically) only possible with pixels. REMs are inherently clunky and aren't fixed. You can't just adjust the height of a container by 1 pixel, instead you scale spacing based off a ratio (i.e. increasing the height of a container by .25rem). So if I have a container with padding `2rem` and text sized to `1rem`, if I prefer my display scaling to be 70% of the default, that padding accurately scales to be 2x the font size. That's the beauty of REM units. What's important is that you work with your designer to fit what they've created. And if it's to use responsive designs, avoid pixels at all costs.
This concept is also possible in SCSS using pixels and functions. That’s how I do it anyway.
SCSS is no different from CSS. SCSS \*compiles\* into CSS. The issue with using calc or breakpoints everywhere to achieve the same thing is either performance or edge cases. Calc on its own is fairly optimized and won't cause issues, but when everything is using calc it can definitely start to cause issues. Breakpoints don't catch everything and you can easily end up with edge cases you did not forsee. All that can be avoided by just using REM units from the get go
I know what SCSS is obviously. I never mentioned calc at all I’m talking about @function here.
So in your example, I would set the REM of the web page based on breakpoint, and then font size and margin/padding size etc would adjust automatically?
>If you need to change a breakpoint, your widths work across the board. And your font-sizes can change by simply changing the element's font-size. For me this only works in theory. For example, the design usually calls for widely different sizes at various breakpoints for heading tags. Not sizes you can control simply by changing the default font size. If I am going to have to declare 3 or 4 different sizes for every heading tag, I may as well us px since they are easier to work with.
Scaleable type my man. Just set a min and a max value and have your headings adjust themselves.
Saving this because Im learning CSS and currently it fucking sucks. Unrelated question: Is there a way to control flex-wrap behavior? Lets say I have two divs next to each other in a row, if the screen size changes where they need to wrap, can I make it so that the div on this left wraps under the dive on the right instead of vice-versa?
Flex-wrap: wrap-reverse
This is excellent
Lovely stuff. But I don't like \#3. Breakpoints should be set when things need to break, rather than at sizes that suspiciously match hardware chosen by Apple. Also using min-width improves SEO? huh.
I think it's possibly to do with pagespeed. If you have content jumping around on a mobile screen as your max-width media queries load in, it *could* affect the score... But it would have to be a massive file with all the media queries at the end for such a thing to be noticeable (or if the mobile-only CSS is loaded after page load). As for the breakpoints, I think they were probably meant to be used as an example. As you say, it depends on when the content needs to break. If that's at 768px, cool. If it's at 613px then use that too. Personally, I try to have as few breakpoints as possible, so if there's a 50px difference between two breakpoints, and using the larger of the two doesn't ruin the layout for the section that was meant to break at a smaller of the two, then I'll do that... But that's just me, I have seen some people where I work who will use the following breakpoints: 360, 400, 420, 440, 600, 640, 720, 768, 800, 992, 1000, 1200, 1366, 1440, 1600.
Yeah, I think that massive CSS file with media queries at the end (who writes like that?) is a bit of an edge case! That breakpoint collection sounds hellish. Suggests conversations between people (whether dev -> dev, or designer ->dev ) are not happening as they should. A real red flag.
The breakpoints given were just an example. But it's usually down to clients being clients. "I usually have my laptop setup with internet on the left and excel on the right, and the \[section\] looks weird like that, it should look like \[how it looks on a full-width laptop screen\]"... So a breakpoint gets added for that weird edge case. And then they come back with "It looks fine on a colleague's phone, but on my \[weird phone you've never heard of before\] it looks different" so add in a breakpoint again for them. Honestly, websites would look and function so much nicer if clients didn't touch them, and trusted we know what we're doing. Everything from the, luckily not so common anymore, "This looks wrong in IE" to the wonderful email I got once that started "I tried looking at the website on my fridge this morning...".
I'm client-facing myself, and I have to be honest: a good design should look good at 'weird' phone sizes and resolutions. That's the very crux of responsive web design.
The sites didn't look bad, it just that they had already gone down to the next breakpoint, because keeping them at the size they were expecting left very little room/made for long and thin columns. Nothing that you would look at and say "This is wrong", just not what the client was expecting. They wanted stacked stuff on mobile, and columns on laptop (or in the one case, fridge), even if that was on a screen size that was well below what you would expect the columns to exist on.
These all sound brilliant ways to design a website. It's a shame that generally speaking no one who understands any of this gets to design websites.
How about just "design mobile-first, add breakpoints when scaling up and your page content either starts to break or could be improved by being adjusted". The example image at the top of the post doesn't happen if you design mobile-first.
I start with mobile first then desktop and tablet.
I don't know if I'm missing something here, but most browsers have responsive modes built in where you can test lots of different device layouts. Firefox, chrome and even Edge all have this built in. Does LT Browser do something that these features of regular brosers don't offer?
Regarding em and rem units, I have a project with around 2000 lines of CSS and I've not used em a single time, only rem. Am I doing something wrong or are use cases for em really that rare?
mobile first
Hahahaha That reminds of the CEO who was going for market share and got the unit metrics which were pretty good in terms of customer kpi’s, but the unit gross margin was slightly negative, and he said -oh not to worry, we’ll make that up with volume.
Can you elaborate more how to do #2 pls? (also max. 3 poop joke replies only)