100% & chosen size method
Hey, let’s say you want a h1 tag to have a max width of 16ch on desktop, but on mobile you want it to have a width of 100%. Is there a way, perhaps using min/max, to define this without using a media query? Thanks in advance.
36 Replies
no, because
100% is absolutely meaningless
100% simply means "100% of the width of the parent"
that can mean 100% of the viewport because all parent elements have no width set
or it can mean something completely different
you can try to use clamp but i don't know if you will have good resultsI think this would work:
That's saying take whatever the minimum value is, either
16ch if 100% is > 16ch or 100% if 16ch > 100%but 100% of what?
that is the entire problem: 100% of what?
That's like someone asking you a question on the street and then you answer their question with "what's the meaning of life" 🤣
but it is an important point
he wants 100% on mobile and 16ch on desktop
does that mean that the parent element is wider than 16ch?
my phone is wider than 16ch
so, your example would still limit it to 16ch, depending on the parent
which may or may not be wider than 16ch
Huh good point, didn't really think about how small
16ch isi know
also, 16ch varied based on the width of the
0 of that font at whatever size
it's possible that 100% is smaller than 16chwhy not just set the width only for desktop*? Default of headings is block and will be 100%
he doesnt want to use media queries
thats just stupid
it is possible if we know the parents
Media query avoidance is just silly
i agree
There is not reason for it
i agree
but this seems to be someone determined to not touch media queries
there's no logic for that requirement, but well
I don't actively avoid them but if I can write something using
clamp or min / max I'd rather use that than a media query -- less lines I have to mentally sort through (even though it's trivial)Is it more readable though?
Like can you just go oh right this changes at X screen?
cause clamps def don't read that way and are a magic floating number in the middle that most people just guess on
Clamps for large large fonts sure.. makes sense if you always want them filling up the viewport maybe.
Also if you are using REM for your sizes in that clamp xD but that is a whole nother can of worms
That's true, but I'm looking at it as if you have something like:
And then with a
min or a clamp, we might be able to reduce each media query a little bit by not having it declared in there. It sounds stupid on paper but it's just how my brain works -- less cognitive load for mewell that is your issue
skill issue
I nest my media queries so 😉
you can do that?
Or you mean just like
always have if you use Sass but ya its in the css spec too
Ah yea it's nice but you gotta be careful with over nesting too sometimes
do you ?
Personal preference ig - i don't like having 4 layers of nesting
well again don't have skill issues
cause I never see that (or do that)
Again we have lots of freedom I don't get why anyone would tie their hands behind their back and start using their nose on the keyboard
lol yea i'm not saying anything is absolute just all personal preference to me and when I nest media queries sometimes I notice I'll be over nesting -- not something that's not easily corrected but something to look out for !!
Yea you have to be aware just like any language, over nesting typically means you could abstract.
I'd rather see someone nest media queries than actively try to avoid them though.
Also postCSS merge like media queries makes built CSS clean so those that say it adds* more code 😄 skill issues
I guess
I mean, the Linux kernel source-code has
\t (tab) set to 8 spaces if I recall
in order to discourage nesting too much
combined with the 80 character line limit
although some languages just makes nesting a requirementif you get too deep into nesting, you're doing something wrong or you need scss's magic
@at-root
and i though because it was the best that terminals could do at that time:
80 columns
24 rows
tab is 8 spacesim with you; although i dont actively avoid them, if i can make it through a project without one by making it responsive from the start, i prefer it. totally hear you on less cognitive overload.
seems more efficient that way for me personally but i dont judge anyone that does use mq (i would probably see what could be changed if they have 6-10 in a small project though). just shows how differently people code. i think i get comfortable in a certain flow when i know it works as well. i do appreciate nesting though so if there is just one element i need to change it is organized and sits there within the selector. and i like @container queries when i need them too.
for me, it's a lot easier to think about "at this size, it must look like this"
We follow readable practices for other code, I don't see CSS being any different'
clamps all over !== it
Also I don't like things changing every viewport pixel (unless its needed to ofc #depends)
im still very old and into the "phone - tablet - desktop - projector" division
I do agree with you do you, and you or your team can make these choices. To make it a "best practice" though I can't get behind.
best practice: write good code