I am not a front end dev but I have inherited a web page that uses media queries and aspect ratio so the content of the page grows proportionally to the size of the viewport, in this case a browser window. The problem is there is a paragraph on the page that is justified (flush to the left and right), so at certain sizes, the spacing between words is not aesthetically pleasing to my client. My question is what is standard practice for this sort of thing? Could one display the content at fixed sizes depending on the size of the browser window using media queries and min-width/max-width min-height/max-height settings, like so:
if the viewport size is < x, render content at fixed size a
else if viewport size is < y, render content at fixed size b
else if viewport size is < z, render content at fixed size c
else render content at fixed size d
?
Or?
The standard practice is to not use justified content which suites well to paper but most times not for screen.
What can you do, now you are here:
.content{
width:80%; /* dynamic value */
max-width:500px; /* fixed maximum */
/* center */
margin-left:auto;
margin-right:auto;
}
You need to edit the CSS selector to yours
Now you are mobile ready and with a maximum width you can have the "best" looking for your justified text (how often does it change?). You need to play around with the values to get an appropriate result.
You also can change the Values on larger viewport sizes:
#media screen and ( min-width:1024px ) {
.content{
width:70%; /* dynamic value */
max-width:1440px; /* fixed maximum */
}
}
Of course you also can leave out the dynamic values and use only fixed values.
thank you all for your responses. i just, at least for now and after many hours of reading and trying various things, solved the problem by simply changing one of the font-size settings just slightly. from 2vw to 1.98vw. although end user is happy, i want / need to understand what i've done. looks like it's time to learn front end work.
#media all and (max-aspect-ratio: 100/68){
...
table#main td#mainLeft table#logoMoto{
width: 30vw;
height: 66vw;
font-family: Arial, Helvetica, sans-serif;
--> font-size: 1.98vw; // was font-size: 2vw;
vertical-align: top;
}
...
}
Related
So I've applied for a front end job few months ago and got interviewed and they've given me a test task. One of the requirements of this task is that they want the website to be infinitely variable scalable like this one.
To quote the task description it says:
If you scale down the browser window, everything fits perfectly because everything scales in the same ratio. For that you have to work with percentage rates instead of px rates.
Now, my problem is I am a PX guy, I mean I build all of my projects using px and not that confident on using different unit such as em, vw, rem etc. Well I've use other unit like vh but I don't use it often.
So what's the best way to learn or any roadmap that'll help me to migrate from px to percentage. Should I just use tools like px to em?
Practice does make perfect
The short answer is... Start practicing using percentage-based units as that's how you'll learn the little catches. This is a good career move anyway as the idea of matching pixels to a design was crushed long ago with HiDPI screens, mobile devices, etc all rendering pixels differently.
Getting Started
Practically, you need a place to start and that means learning a few new CSS tools.
First
Use rem as a substitute for pixels.
Unlike an em that's relative to its parent font-size, a Rem is relative to the font-size of the root element (usually body) which means its GLOBAL. You can use rems everwhere (font-size, margin, padding, position, etc) and they're ALL based on the root size.
So let's say the root font size is 16px (typical browser default). That means 1rem = 16px. Now a 16px base isn't overly useful when you're doing math in your head. Jonathan Snook wrote about why this works years ago but the basic formula is set the base font size to 62.5% (of 16px) this means that 1rem = 10px and it's much easier to do the math.
Here's what that looks like in code:
body {
font-size: 62.5%;
}
h1 {
font-size: 2.4rem;
/* 2.4rem = 24px */
}
p {
font-size: 1.2rem;
/* 1.2rem = 12px */
}
.padding-left {
padding-left: 2rem;
/* 2rem = 20px */
}
You get the idea...
Fun tip: once you like the layout you can change the body font-size and make everything bigger or smaller. This is useful for things like a small screen where you want the fonts to be a bit larger
Next
CSS Calc() Is your friend. It's designed to help you do math operations on mixed unit values. For example, the browser can then do this type of math: 33.33% - 200px.
.element {
width: calc(33.33% - 20px);
/* maybe you need responsive columns with 10 px of padding on either side */
}
Finally
Start doing all your layout in percents. For example instead of a 3 column layout set to 300px wide (not responsive). You should make them 100/3 or 33.3333333% wide. Percents like this are always based on the parent so 100% = parent's width (regardless of the parent's units).
As a side note, I rarely need to use vh/vw, not because they aren't useful but in general, elements overflow their window in very predictable ways and percents are easier to wrap your head around.
vw and vh are going to be your best bet if it needs to be a percentage of the screen. rem and em are still relative to a starting point (i.e. body { font-size: 16px; } and scaled from there. vw and vh do have some issues on smaller device screens though, but it looks like your demo website has this issue. You can fix this with media queries, but it doesn't look like your example did, it "infinitely" scales as you mentioned.
After migrating a website to responsive html5 using media queries, I find that I still can't get the mobile iOS 7 safari browser to display the footer/main/header sections at the same width, despite their css being set to display:block and width:100%.
Examples:
http://i.imgur.com/QUxffNT.jpg
http://dev.shermanbrothers.com (username: devreview password: De3e3vfr4 ) [html5 update to site]
And a similar problem occurs even on an older version of the site:
http://i.imgur.com/1sS4WRZ.jpg
http://shermanbrothers.com [OLD version of the site with table-based layout, still has similar issues]
Now, I have some guesses as to -why- this is happening on mobile and not on the narrow windows of a desktop browser:
Some block level elements like the main/between-header-and-footer one have too much content to even shrink down to that 100%
Or perhaps using display:table on the middle section is allowing it to blow up larger than the other block & 100% width elements.
But I don't know what techniques to use to combat the problem.
- I can't even inspect the code via mobile to determine the reasons for the differences.
- setting a css max-width to images (eg max-width:100% ) within their container is not better.
So how can mobile-specific bugs, and mobile width/layout issues especially, be debugged & dealt with?
The tables are a huge headache for diagnosing this problem since there is so much markup to look through. However, the tables are not the reason why your layout is breaking (at least not with the markup I saw when I came across this question). Your problem is that you have so many fixed widths on images, text and table columns.
To fix this, you will have to set-up breakpoints in your media queries. Something like this for the images:
#media (min-width: Whatever is the smallest screen size the image will not break your layout) and (max-width: 1 pixel below the previous size where the image was so wide it broke your layout) {
.header-image {
width: whatever is the widest width that keeps it from breaking your layout; // This will change with smaller queries
height: auto;
}
}
And something like this for your fonts:
#media (min-width: Whatever is the smallest size the font will not break your layout) and (max-width: 1 pixel below the previous size where the font was so wide it broke your layout) {
.navbar-font {
font-size: whatever is the biggest font size that keeps the font from breaking your layout;
}
}
Alternatively for your fonts, you could tell them to wrap as the screen gets smaller, but then you would have to factor in their height as they wrapped:
.navbar-font {
white-space: pre-wrap;
}
Do something similar with the above to allow the width of your table columns to resize properly as well.
Also, follow #TylerEich 's suggestion and configure your viewports.
https://developer.apple.com/library/ios/documentation/AppleApplications/Reference/SafariWebContent/UsingtheViewport/UsingtheViewport.html
http://developer.android.com/guide/webapps/best-practices.html
Finally, check out BrowserStack for mobile browser testing.
This may not fix all of your layout issues, but it fixed the biggest ones I found. Table-based layouts are a pain to work with. Good luck :)
font-size
the top element of the footer columns (footer-flex) has a font-size: 10px. And the child element (.footer-block) has a font-size: 2em. This means the .footer-block elements have font-size: 20px. (10px(top element font-size) * 2em) = 20px. This causes big texts in your footer.
display
You're using float to align elements side by side which is a very bad practice. If you'd like to align elements properly you should select display: table-cell or display: inline-block. The difference is table-cell is just like <td> tag. Which means all the consecutive elements has the same height.
Because table-cell acts just like td tag the table-cell cannot have margins. If you'd like to have margins for your table-cell you need to provide a top element which is display: table with a style border-spacing. An example which is very proper for your case: http://jsfiddle.net/R3zDu/
As you can see there is no clear: both or float: blah definitions and clear css definition.
This doesn't mean "don't use float anymore". float's main purpose is to align the images in the texts/paragraphs.
clear all the float and clear: both styles.
apply table-cell method.
testing
I don't think there is a software that renders the page just like a mobile phone. On the other hand, if you have problems in iOS you can take a look at Safari browser in your PC or Mac which acts like iOS Safari in most cases (at least in your case).
Sounds like you need a mobile-friendly <meta> tag. Example:
<meta name="viewport" content="width=device-width, user-scalable=no">
Quote from the Mozilla Developer Network:
A typical mobile-optimized site contains something like the following:
<meta name="viewport" content="width=device-width, user-scalable=no">
The width property controls the size of the viewport. It can be set to a specific number of pixels like width=600 or to the special value device-width value which is the width of the screen in CSS pixels at a scale of 100%. (There are corresponding height and device-height values, which may be useful for pages with elements that change size or position based on the viewport height.)
The initial-scale property controls the zoom level when the page is first loaded. The maximum-scale, minimum-scale, and user-scalable properties control how users are allowed to zoom the page in or out.
There is a lot of code that needs to be redone.
Instead of being this painful, I highly recommend you to look into a framework like bootstrap or foundation. They both provide good template example to help you get started. Their media queries also work like a charm and they will help you cut lots of development time and some headache.
#head{
float:left;
width:100%;
}
#content_head{
display:table;
margin:0 auto;
}
#body{
float:left;
width:100%;
}
#content_body{
display:table;
margin:0 auto;
}
#footer{
float:left;
width:100%;
}
#content_footer{
display:table;
margin:0 auto;
}
If I was you, and don't want to do a complete overhaul, I would suggest you set:
<meta name="viewport" content="width=500px" />
And try fixing the things that float out of your 500px width (like the navigation).
This way, you don't have to do much work. The site is more or less a bit normal visible on a mobile. I studied your code a little, but it's a lot of working if you want to do it proper.
500px is somewhat ok for a mobile device, but you can tweak it to what you like, it isn't as nice as device-width but gives you a fair compromis between your pile of work to do and the general user experience. As long as you allow zooming (user scaling).
One other trick I suggest is to make the font a tiny bit bigger on mobile on some parts, like your brand nav. And form elements always minimal 16px so you don't get zooming on an iPhone when you focus a field.
#media all and (max-width: 767px) {
.brand-name-td{
font-size:1em;
}
input[type="text"],select,textarea{
font-size:16px;
}
}
Further, what's handy and improves the UX, there are some parts you just want to hide on a phone, use this:
#media all and (max-width: 767px) {
.hide-mobile{
display:none;
}
}
And just when you have some element you want to hide, add the class (divide by a space if you have more classes)
<td class="right-side-nav-container hide-mobile">...</td>
Regards
use diplay block and width to 100%, remove also float and max-width, min-width property.
Also you can simulate a mobile just by using a browser since you already have the viewport metadata. Just resize the width of the browser.
I picked up this handy little fix while browsing some random sites in firebug, it looks like what you're describing, why not give it a go and see if it works :P
$(function(){
// IPad/IPhone
var viewportmeta = document.querySelector && document.querySelector('meta[name="viewport"]'),
ua = navigator.userAgent,
gestureStart = function () {
viewportmeta.content = "width=device-width, minimum-scale=0.25, maximum-scale=1.6";
},
scaleFix = function () {
if (viewportmeta && /iPhone|iPad/.test(ua) && !/Opera Mini/.test(ua)) {
viewportmeta.content = "width=device-width, minimum-scale=1.0, maximum-scale=1.0";
document.addEventListener("gesturestart", gestureStart, false);
}
};
scaleFix();
});
I have a page which displays fine on the screen.
I have a css which then formats the screen for print and re-sizes the sections.
My problem is that the print layout has a margin of approximately an inch from the left of the page which makes 2 elements print off the page on the right hand side.
I could probably compress the contents from the right but I want to know if I can reduce the margin on the left (and basically center the contents)
I have set the body tag on print to margin:0; padding: 0; but this has no effect?
Is there another setting that controls print margins?
You can set the print margin (and landscape orientation) with CSS like:
#media print {
#page {
size: letter landscape;
margin: 4.0cm;
}
}
And the good news is, it works! (On Chrome. Not supported on other browsers though I did not test IE9.)
The margin must be in a unit that makes sense in print -- pixels are not allowed.
Chrome will not shrink the margin below a fixed minimum, which may be determined by the printer driver.
You could also try to set
margin:0; and padding:0;
to the html, main content div and p tags
and see if that helps.
Otherwise, your best bet is to set a specific width on your elements.
I'd like to try and convert my designs from pixels to ems. I've read so many tutorials that... and I'll leave it right there.
Starting with this as my base:
body {
font-size: 62.5%;
line-height: 1.4;
}
... now this is where I get lost...
Should I be defining my font-size like this:
div#wrapper { font-size: 1.5em; }
... or like this:
blockquote, li, p, dt, dd, etc { font-size: 1.5em }
And then the next thing I don't really understand is where ELSE should I be using ems in addition to font-size and line-height? I will be using a fixed-width layout using 960.gs.
line-height: 1.4em;
Probably isn't what you want. The line-height will stay at the same computed height for the size of an ‘em’ on that element, even when you change the font-size on a descendant element.
line-height has a special case where it allows a unitless number:
line-height: 1.4;
Which makes each descendant line-height depend on its own font-size rather than the ancestor's.
Should I be defining my font-size [on a wrapper or on many element types]?
Well that rather depends on what you're trying to do. With relative font-sizes it is generally best to keep the number of declarations down to a minimum, because they nest: that is, with your blockquote { font-size: 1.5em; }, if you put a blockquote inside a blockquote you'd get a font-size of 1.5*1.5=2.25em compared to the body font size. Is that what you want? Maybe, maybe not.
where ELSE should I be using ems
Anywhere you want the size of an element to respond to the user's preferred font-size. One common example would be something like:
#maintext {
width: 60%;
min-width: 8em;
max-width: 40em;
}
to try to restrict text lines to a reasonable column width when doing liquid layout.
But if you are limiting yourself to a fixed-width layout it may not make sense to make element widths font-size-dependent.
You may find How to size text using ems an interesting and helpful read. The thing that I try to remember is my conversion from ems to pixels.
In your example:
body {
font-size: 62.5%;
line-height: 1.4em;
}
1 em is equal to 10 pixels if the browser default text-size is 16px. The line height would then be equal to 14 pixels. Like bobince beings out, I would use a unitless line-height value.
To help you with your calculations, you can use an Em Calculator. It allows you to easily convert between ems and pixels.
The problem with em is that it is a relative unit. Inheritance and relativity don't mix well in HTML documents. What I do is use px for font size and box dimensions / positioning, but try to use em for line-height, margin / padding, etc...
I'm sure it's not the "proper" way to do it, but the system was pretty poorly designed from the start, if you ask me.
ems are relative, so if you set:
body {
font-size: .6em;
}
Everything will be relative to that.
Which means (and this is where my head starts to hurt too) that if an h1 has a default font size of 250% larger than most other text (p, li), the header will now be 60% of that default size. So it will still be 2.5 times bigger than the other stuff, but it will be 60% smaller than if you hadn't set the rule at all.
Now, if you then say that :
h1 {
font-size: 1.2em;
}
The h1 will now be 20% larger than what it would be if you hadn't set the rule, so it's 20% larger than the already shrunken down 60% smaller from the first rule. This means that it will no longer be in direct proportion to the browser's default for h1 and other elements.
So basically, you should set your font-size up front for the whole document (like in the first rule I showed), and this is your baseline. After that, you set how you want any individual elements to be sized in relationship to each other (basically in relationship to what they already are)...
So if you know you want all of the fonts in the #wrapper div to be 1.5em from their default, setting it there is perfect. But if you want to change the size of blockquote so that it's a tad smaller, you'd still set the rule for #wrapper, but then make a second rule for blockquote.
If you want to set up page width by using em's, follow this pattern provided by YUI development team
Divide your desired pixel width by 13; the result is your width in ems for all non-IE browsers. For IE, divide your desired pixel with by 13.3333 to find the width in ems for IE.
Here's an example of a custom page width of 600px, and here's what the CSS looks like:
600 px / 13 = 46.15 (non-IE browsers)
600 px / 13.33 = 45.00 (IE browsers)
#custom-doc {
margin:auto;text-align:left; /* leave unchanged */
width:46.15em;/* non-IE */
*width:45.00em;/* IE */
min-width:600px;/* optional but recommended */
}
regards,
I am trying to figure out what margins are best for readability and i figure it is best to use standard paper size and margins. I looked it up and its seems like 8.5 is standard. I looked up how to do basic CSS and hit a problem
margin-left: 1.5in;
margin-right: 8.0in;
I was excepting the left will start from 1.5 of the left side as well as right being 8in from the left side. It turns out right is 8in from the right ruining my page. How do i set it so the width of the text is 7inches no matter what resolution the user browser is on?
You could set the width of the body to 7 inches. But the browser will automatically lay out the text for you to fit the paper. So I would have set both the left and the right margins to 1.5 inches. You may use a separate CSS file for printing.
Take a look at the CSS Box Model and Media Type rules. The #page rule (for paged media) may also be of interest.
As has already been said, you should use the width property to define the width of the block-level element. You can then use padding and margin to pad the text and put a margin around its container.
Something like this will let you specify the document style for print:
#media print {
p {
font-family: times,serif;
font-size: 12px
margin: 1cm 2cm;
page-break-inside: avoid;
widows: 2;
orphans: 2;
}
}
I would recommend letting the printer software automatically determine the dimensions of the text based on the margins you specify and the page used to print. That way the user can more easily print on whatever dimension paper they want. Here are some print-specific CSS properties you may want to use to format the printed document.
And I believe serif fonts are easier to read on print (or so people say), so that might also be worth considering.
You're looking at it backwards: margin-right is the width in from the right-hand side of the viewport (or the piece of paper). So for a 8.5" piece of paper with 1" margins on all sides, you'd want:
body{
margin-left: 1in;
margin-right: 1in;
width: 6.5in;
}