I'm trying to design a fluid / responsive web design using bootstrap. I'm trying to design the layout so that it'll fit in many devices. My question about setting height to a layout element, such as the header or footer. I've got it in pixels right now, but I would like to know if I should be using some other form of measurement.
I'm probably over-thinking this, but I'd like to make sure I'm doing this the right way. Thanks in advance!
Avoid setting a height whenever possible. You can often get around - and preferably so - using padding on the element in question, and/or margin values on the element's children.
If you absolutely need to define a height, use min-height so that it'll grow as its children take up more vertical space.
Many times people fall back to defining static height values because the elements are also using float and add height to get content flow and backgrounds back. This is rather poor practice and if this is the case you should consider looking into methods of clearing floats.
Probably pixels are the best option if you have a lot different devices. Other measurements to consider:
em (1em equals default font size)
% (of the screen)
em and % is the good solution for fluid / responsive web design.
I will suggest for media query css
#media only screen and (max-device-width: 480px) {
}
Related
I was given a Figma design of a webpage. The Figma page width was 1825px. The width of my laptop is 1080px. Suppose a text in Figma page has font-size 20px. How do I convert it to my laptop so that the ratio is maintained?
I can't use a percentage because I'm using flexbox. And when I try using percentage what it does is takes the percentage of its parent container rather than the entire body.
I also tried using VW. Calculated the view width based on the 1825px breakpoint and implemented that. The issue is that the pixels are getting distorted in this approach.
Also, This answer Typography using VW got lots of upvotes means VW works, Then why am I facing the issue?
I'm using react and I don't want any javascript solution. Is there any way to solve this using CSS only?
Are you sure you need to do it? Font size usually changes when breakpoint is reached.
But if you really need to do it, you may set the font-size based on viewport width.
So if 20px font-size on 1825px width is desired ratio then you need to set font-size to 0,01vw to preserve the ratio across all screen sizes.
The easiest way would be to use media queries.
https://developer.mozilla.org/es/docs/CSS/Media_queries
You can also try other units like vw (view width), rem (relative to the font size of the root element), etc...
https://www.w3schools.com/cssref/css_units.asp
I'm currently trying to make a responsive navbar (and it works, is responsive), but at some window size, it becomes too big. So I tried to use #media (max-width) to block its growth at some point. Unfortunately, when I use px to describe new fixed size, the navbar is now affected by scaling of the page (ctrl+mouse wheel), and I'm trying to avoid this behavior.
Is there a workaround to my problem?
Little hard to understand your question, but any good navbar should scale width wise for a page. I kinda sounds like you set the height style to a percentage rather than pixel amount.
<div style='height:80px;width:100%;'>Content</div>
This makes a horizontally scaling bar, with a constant heigjht
I don't feel that neat's grid is truly fluid. A fluid grid would scale well all the way from mobile to a large tv screen such as 1920x1080. However the way that neat and bitters end up working creates a $max-width variable which is default set at 1088. Even if you change this however there is a size that the website will stop being fluid, the max-size. I feel a fluid layout would constantly grow and shrink no matter the size of the screen.
Currently my way around this is by using fill-parent
.outer-container {
#include fill-parent;
}
This works but it feels hacky, is there no way using neat to properly create a fully fluid grid? Setting max-width has it's limit.
You don't need to use outer-container on an element that's supposed to fill the entire viewport. The only thing that mixin does is centering an element, clearing its floats and giving it a max-width.
In CSS, element are width: 100% by default, so there is no need to specify anything if that's the expected result.
The 'fluid' part of Neat refers to the fact that it does't use fixed widths, but percentages.
I've built a dynamically sized grid layout that can adapt to reasonably in any sized resolution (phone, tablet, desktop) and handle resizing, all while being near pixel-perfect (sorry, I'm OCD -- and I say "near" because my math is broken right now and you can't fit two evenly sized elements inside of an odd sized container without padding being 1px off on one side).
Anyway, below is a link to what I've hacked together with JavaScript. It's an example of what I'm trying to pull off. Resize the width of the bottom pane a bit to see what I'm going for.
http://jsfiddle.net/langdonx/uFW2C/2/
It has some ugly manual JavaScript that's since been ported to Angular, but still the ugly JavaScript that calculates all the styles remains.
So my question... can I pull this off with strictly CSS? Or a lot more CSS and a lot less JavaScript? And by this I mean dynamically sized cells based on the width of the screen?
Here are the business rules:
Max cell width: 320px
Minimum # cells per row: 2
this might be impossible with CSS, so I'd be fine with settling on Min Cell Width: 178 for Chrome on my Galaxy Nexus(whose portait mode is 360px wide)
Cell border: 5px with a 2px outline
Visible margin between cells: 3px (margin is actually 5px, but outline bleeds out)
In this example, I'm redrawing the cells on resize every time, but in my Angular version, I believe that just the styles get updated. That said, I could probably get away with redrawing a table on resize, but I'd only have to calculate the cell width based on the document width, and well... I wouldn't be thrilled to use a table. =[
-end mad rant
Media queries
CSS media queries might get you pretty close to a CSS-only solution.
The key concept here is using different layout grids based on the width of the browser, to vary the number of columns.
Media queries are the natural CSS way to change the layout based on the browser width. And they require no JavaScript. If you use a set of media queries -- each one targetting a different range of browser widths -- to control which layout grid is used, then all each grid has to do is be responsive -- percentage widths for each column, and let the content stretch to fill the column width.
Responsive Design
The question then becomes: Is it possible to automatically stretch each piece of content to fill the column using CSS alone? That depends on the type of content, how it's expected to behave when it stretches, and if there's any room for compromise with the graphic design.
Typically, the graphic design for a responsive website has to be tailored to suit the limitations of Responsive Design (with the graphic designers having a rough idea of what's feasible and what isn't). But... whatever can't be done automatically, can be done using JavaScript.
Relevant search terms for attempting to stretch the content: Responsive Design, Adaptive Content, Fluid Grid
Note: "Columns" in this case may simply mean the percentage width used for the floated containers for each piece of content. It doesn't have to mean "physical" columns, in the traditional sense.
What are good and recommended uses of percentage values for vertical CSS declarations?
In other words, under responsive design, are we overlooking something where % would be beneficial over em?
Because it seems that for most situations (except for cases where you want all sides equal; credit), em would be better served than %, consider:
Using percentages for the horizontal values of padding, margin or border of elements in CSS is fairly standard — especially in responsive web design. For example, take margin-left: 7.2% and padding: 0 5%. It also makes sense: the wider the screen, then the space will increase proportionally.
One can do the same for the vertical values:
margin-top: 5%;
padding: 10% 0;
border: 1% 0 2% 0;
As expected, an increasing viewport width will increase the corresponding vertical spaces.
However, in the cases I've come across, it can look a bit odd — unfitting to the design. It seems that em values may be better served.* But, on the other hand, where would it be beneficial to use percentages?
* Since these won't increase with the width of the screen, but will increase according to the font size of the page.
I don't think there's any right or wrong answers to this question. It really does depend on your design.
As you noted, % values, even on vertical-based properties on margin & padding, are still relative to the width of the document. So if your design requires even padding, then % values all round are great.
But, if the design is content oriented, and you're still using % values on the horizontal properties for responsive design, % might not be the best for the vertical properties. You may, for example, want the padding-top to be exactly the height of 1 line of text. So you'd use ems.
But I digress; it really does depend on your design and personal preference.
Yes, depending on the situation just like any other css practice.
Say you have a container div that uses 100% of the screen height and you have a header you want to appear at the top of your div. You could say margin-top: 15px on your header, which works, but then if I come and view it on my phone it will look very squished.
So instead you say margin-top: 10% then no matter what screen I come and view your site on your header is always 10% from the top of the div. which means the relative flow of your layout will always be the same.
The general rule is this: For any valid css you can write there is a use-case where it would be the best way to go about achieving your design goal. Forget anyone who says "Never use negative margins" or "always avoid absolute positioning" or any of the other crap they throw around.
I have been pondering this question as well recently and after reading around the internet the 'rule of thumb' I'm beginning to lean on is as follows. First, the reason why % is good responsive design for the horizontal axis is because as we all know the width of your browser can vary greatly depending whether the user is on a phone or computer. The vertical axis is different however because while it can also vary like the horizontal axis, many webpages are created for a vertical scroll and the user is expecting to scroll down. In such cases a little more vertical scrolling due to less responsive ems is fine.
To answer your question based on that assumption, a time in which you would use % for the vertical margin is when you have a design where you don't want to make the user scroll much to see a part of the page. Specific examples might be a single-page web app where you don't want any scrolling or a header or initial page content such as a picture that you would want the user to see in its entirety without having to scroll down.