Is this the intentional behavior?
Yes, because your fonts would be twice the size, your paddings and max-widths would be twice the size, so you need the query to trigger when appropriate for the CONTENT,
not the DEVICE!One of the biggest cock-ups you see in attempts to be "mobile friendly" is pre-planning fixed widths or certain widths for queries before you even have content plugged in.
The way I have always advocated it -- and seems relatively bulletproof -- is to start out with your largest layout with a max-width on the content area to prevent long likes from being hard to follow. You then narrow the window until something breaks, figure out how many EM that's add, add 5% wiggle room for browser and font differences, and there's your media query width to make your changes.
Lather, rinse, repeat until you're down below 16em.
(256px for 16px, the smallest phone you should need to worry about any time over the past decade)It's why idiocy like failwind goes bits up, and why so many front end dev's aren't qualified to code front ends, just as the artists under the DELUSION they are designers don't know enough to design a damned thing. If you are thinking a specific PX width for your media query breakpoints before you have content or a reasonable facsimile of future content, you're putting the cart before the horse. Utterly, totally, and completely bass ackwards!
Layout should be designed to the needs of the content within the device width, not to the needs of the device or some arbitrary pre-planned BS shoe-horning content into it where it doesn't fit.
that's why if you see something like
"@media(max-width:768px;) { // mobile friendly {
You're actually in all likelihood looking at developer ignorance, incompetence, and ineptitude.
Though the number of media queries I even use are dropping of precipitously thanks to flex, flex-wrap, min(), max(), clamp(), and so forth. We're starting to reach the point where media queries are not necessary for a hell of a lot more than the mobile (hamburger) menu.