I was wondering if there's a maximum number of breakpoints that a website should have. Just a way of seeing ifit has too many breakpoints which I believe is not a good sign, or is it?
The website I built has 8 breakpoints. Is it bad? Should I have less?
The site is a bit complex althought I tried to gather as much code as I could that has the same characteristic, like:
CSS:
nav ul li, table, video, section ul, footer, .botoes, #nome, #destaque {
margin: auto;
}
nav ul li, .lista p, .smilies {
font-size: 37px;
}
You should just keep it simple and use as few breakpoints as possible to achieve the wanted results. There is no absolute maximum number for this, as more complex websites probably require more breakpoints.
This explains good practices using breakpoints well.
Mobile-first design is something one should be aware though: Create your website for small screens first, and set breakpoints as the screen gets bigger, not the other way around. This is useful, because this way you let computers, which usually have more processing power than smartphones, handle breakpoints, and smartphones can just display the site "as is", without having to calculate large amounts of breakpoints.
Read more about mobile first
Related
I'm a novice programmer, only took one course in high school. I'm trying to make a website for my business, using c9.io to write- but can't figure out how to make my page adjust to any size. I've tried finding a solution online but can't seem to fix my problem- I'm completely stumped! Good luck and thanks!
HTML and CSS code below.
https://docs.google.com/document/d/1wl1Ui-vvB39ysCQd2B5-7Yl-gYRPdQ7hUyD_L-tDcs4/edit
Edit:
The problem has been fixed, here is the CSS code that I used:
.container4 {
width:99%;
margin-left: auto;
margin-right: auto;
text-align: center;
}
Media queries alongwith twitter bootstrap or flexbox are used to make websites responsive.
Media queries help you manage layouts for different devices say phones, tabs and desktop. Keep following in mind while writing css:-
Use ems/rems for margins/padding, avoid using pixels
2.use sass instead of pure css, its really easy to scale
I have a very large and complicated stylesheet. Because of the way I've built the organization of the styles, it would make sense to me to put in some media queries for smaller resolutions throughout the stylesheet, rather than group them all into one at the end like I normally see.
For example, here's some pseudo-code for what I mean:
.navbar { width: 300; height: 20px; background: gray; }
.navbar ul { etc etc }
#media screen and (max-width: 800px) {
.navbar ul { something to make it smaller..... }
}
.....30 some-odd lines later....
#contentblock { some styles }
#media screen and (max-width: 800px) {
#contentblock a { something that makes this one smaller and stuff }
}
^^Hope that all makes sense.
My question is: although I am allowed to do this, does it dramatically impact the load/processing time? Is it a memory hog that should be avoided by grouping all the media queries at the bottom of the sheet, or for the sake of my own convenience, I can go ahead and do it with minimal negative impact?
Negligible.
Have you not seen the big sites and their 30k+ line stylesheets? Browsers can load it very fast, it shouldn't make a difference whether or not they are grouped together.
The real difference is on your end. Make it so that it's efficient for you to develop. Personally I think it looks better for them to be next to related styles rather than on the bottom. But be mindful that newer styles override older ones, that may be where the practice of grouping media queries on the bottom came from.
Unless you're sending your code back in time to the AOL dial-up days, this will not have any noticeable impact on performance/processing time.
That being said, don't forget your order of operations. You'll have to be careful not to overwrite your media queries. Keeping them all at the end of the stylesheet helps in preventing that and ensures that your media queries are at the end of the cascade.
I'm about to start designing my site that I coded in php. It's a rather complex site...
Obviously, I want to make it suitable for all browsers and devices.
Should I code the CSS using fixed pixels for normal computer dimensions and when I'm done with that make another stylesheet for other devices such as iphone and ipad?
Or should I attempt to make an adaptive site that works with all resolutions? In this case, should I look into CSS frameworks? Any recommendations?
Here's some tips for designing a web page that works on ALL screen sizes. I'll delve a bit into media queries and other things too.
On web pages I've done in the past they usually have existing graphics (usually banners/headers, etc.). so I usually design the web site using a maximum width for example, if the banner image that already exists is 900px wide I'm going to make the page 900px wide, more specifically the content wrapper will be 900px wide and it's contents will sum to 100%.
Keep everything in a global content wrapper. This is the easiest way to ensure the page size stays 100% consistent.
The sum that makes up the wrapper should always amount to 100%. Fill the wrapper, but it will never go outside of it. You may have numerous columns or divisions, which you can size at any percentage up to a sum of 100. (like, col1 width="33%", col2 width="33%", col3 width="34%" = 100%)
Try to pick images that work for ALL screen sizes. There is no built-in way to swap to mobile images when working with responsive web design (there are javascript solutions), but pick an image that looks good when scaled down.
Avoid scaling an image up. This is why i tend to make the max page size the same size as a header image (if there is one). If the page has no images, 100% liquid layouts are very good too.
If the content wrapper is fixed, turn it into a percentage with a media query :D example below.
I'm going to write up a basic example of a MAX width 900px page with columns that works on any site mobile/desktop.
default-style.css
img
{
max-width: 100%;
height: auto;
width: auto; /* ie8 */
border: none;
}
.content_wrap
{
width: 900px;
margin-left: auto;
margin-right: auto;
height: auto !important;
}
/* Columns */
#column-wrap
{
float: left;
width: 100%;
}
#column-left
{
width: 30%;
float: left;
}
#column-middle
{
width: 35%;
float: left;
}
#column-right
{
width: 35%;
float: left;
}
default-queries.css
/* Turn it into a liquid layout at our max-width of 900px */
#media screen and (max-width: 900px)
{
.content_wrap
{
width: 100%;
}
}
/* most smart phones */
/* This query will turn all 3 columns into 1 column at 540px */
#media screen and (max-width: 540px)
{
#column-wrap
{
position: relative;
clear: both;
}
#column-wrap div
{
margin-bottom: 10px;
float:none; clear: both;
}
#column-left
{
width: 100%;
}
#column-middle
{
width: 100%;
}
#column-right
{
width: 100%;
}
}
Now for the html :D
index.html
<!DOCTYPE html>
<html>
<head>
<link href="default-styles.css" rel="stylesheet" />
<link href="default-queries.css" rel="stylesheet" />
</head>
<body>
<div class="content_wrap">
<div id="column-wrap">
<div id="column-left">
<p>HELLO I"M LEFT COLUMN</p>
</div>
<div id="column-middle">
<p>HELLO IM MIDDLE</p>
</div>
<div id="column-right">
<p>RIGHT</p>
</div>
</div></div>
</body>
</html>
So this is a most primitive example of a responsive web site. Using the class content_wrapper at a fixed width of 900px (because the biggest image im using may be 900px). But when the screen is smaller than 900px, we switch from fixed to liquid via media query switching to a liquid width will allow our images to scale down, our text to wrap, and a whole bunch of other great things!
But, there's more to it than that. That's all we need to do if the page only has linear content, but most pages have different columns to make the most of large screen sizes. This is where media queries REALLY come in handy. If you study the columns, their sum takes up 100% of the content_wrap at all times. And they will scale down for a small website, but they will be really really tiny. This is why I make another media query for smaller screens and eliminate the multi-column layout. Simply clearing the floats and making each column have a width of 100%, will allow for a much more efficient mobile layout.
Anyway, really long answer but hopefully my views/opinions on how to properly design a website with CSS/HTML (php, ASP.net, MVC, etc, can all be thrown in there too) will get you started! Design with a wrapper, media queries, no upscaled images, and images that look good scaled down are really good practices IMO ;)
I like fixed width pages! They are more universal and prevent over-scaled images Media queries in CSS3 take care of responsiveness ;)
I usually DON'T do mobile-first designs, but that's just my personal preference. I see no advantage to one way over the other
As stated in another answer, for non-CSS3 browsers response.js works very well
As usual, it depends. If you think your site is going to be accessed by many devices then you probably want to look at responsive design: http://johnpolacek.github.com/scrolldeck.js/decks/responsive/ and http://www.alistapart.com/articles/responsive-web-design/ for more details.
The recommended approach is to take a 'mobile first' approach to the styling, so it works well with little markup for mobile devices and then progressively enhance for other devices with larger resolutions.
You may want to use frameworks or hand-code it - that's something of a personal choice.
If you have significantly different needs for different devices, you may want to create entirely different sites for mobile, similar to the current BBC news for instance, although it's worth noting that many sites including BBC are moving to responsive techniques, so this is a trend that is being adopted more and more.
It's also worth considering which browsers your audience will be using. As you reach back into older IE versions especially you'll need to look at javascript techniques such as the respond.js library to allow media queries to work.
The two aren't mutually distinctive.
The two approaches are generally:
Multiple stylesheets, media queries decide which one to load.
Use fluid measurements (percentages) so the site is fluid.
In reality, you often end up using a bit of both.
There are many issues with trying to do this, one particularly being that older IE doesn't support media queries, and renders everything all the time.
Frameworks are good, but you may find them restrictive. There are many around, and they all basically do the same thing, so just google Responsive CSS framework and see what you find.
I'd also recommend looking into SASS at this point - I use it so I can auto generate an IE stylesheet that has the 960px width version with no media queries, whilst generating another sheet with all the queries in.
Already been answered, I see, but I think what I've got to say is relevant...
Most sites do both a desktop site and a mobile site. Desktop sites are almost always fixed width, with a maximum width at about 1000px. This is starting to change, though, you will see more adaptive sites than in the past. Mobile sites need to have an adaptive width, because of all the crazy different resolutions on all the various phone models out there. I recommend that the smallest width the mobile site should work at is about 320px, because most modern phones are at least that width.
As for mobile detection, take a look at PHP Mobile Detect, it's what I use, and it works pretty well. You just throw in
<?PHP
if ($detect->isMobile()) {
header('Location: /path/to/mobile/site');
} else {
header('Location: /path/to/full/site');
}
?>
at the very top of the first page. You should use a seperate splash page that redirects to something like index2.htm so that users can choose to view the desktop site if they want. It saves you a lot of trouble trying to figure out how to set cookies...
I recommend making an adaptive or responsive that can maintain its look across multiple device resolutios. With that being said CSS framework will be your option so your html file is not filled with your topic content and style code.
This is a duplicate from UI.StackExchange.com:
https://ux.stackexchange.com/questions/1004/mixing-percent-and-fixed-css
Should you ever apply percentage and fixed CSS together? Will it cause problems, and if so what kinds?
Does mixing degrade browser render performance?
Will mixing give you weird results on initial load with progressive rendering browsers?
Below is just a dumbed-down example of mixed usage, it could be any mixture. I am not looking for validation of the example. I have heard you should never do what I have in the example below, so I am trying to find out if using CSS in this manner is an issue.
Example mix usage:
<style>
.container
{
width:300px;
}
.cell
{
width:25%;
}
</style>
<table class="container">
<tr>
<td class="cell"><td>
<td class="cell"><td>
<td class="cell"><td>
<td class="cell"><td>
</tr>
</table>
+1 Good question. You may want to have a look at this article: "Fixed-width, liquid, and elastic layout" It goes over fixed width layout (em) and elastic layouts (%), and if you click to go to the next page it looks at 'Elastic-liquid hybrid' - where width: is set one way, with max-width: set the other. I know the article linked to above isn't exactly what you asked, but it's an example of mixed use within a single CSS style.
Edit: After some further reading I did find a quite a few contradictory opinions on the subject. I found several articles that held the idea that "you just can’t mix up pixels and percentages". Though, for the most part, these sites were fairly dated. When I narrowed the search to only articles that have been put up within the past year, things changed a bit. There were still a few opinions against mixing, but they typically didn't explain why, and seemed to of the "I always heard it was a bad idea" variety.
The majority of more recent information that I've found on the topic seems to indicate that mixing percentage with fixed widths is a perfectly acceptable practice, as long as it's done with an understanding of the results.
see:
"Fixed vs. Fluid vs. Elastic Layout: What’s The Right One For You?" (Jun 2009)
"For A Beautiful Web: Changing Man Layout"
...
Full Disclosure: I've been a mixer for many years, without really knowing whether my approach was 'correct.'
This should help clear up when it is ok to mix percent and pixels and when it is not.
Mixing percent and pixel widths wouldn't be a problem when you do it as in your example;
.container
{
width:300px;
}
.cell
{
width:25%;
}
When it becomes a problem is when you reverse the order;
.container
{
width:25%;
}
.cell
{
width:250px;
}
In this case, if the browser window (or the parent of .container) is less than 1000px, 25% on .container will be less than 250px and cause .cell to overflow .container.
It also becomes a problem when you mix percent and pixels in the case of width plus padding;
.container
{
width:300px;
}
.cell
{
width:100%;
padding: 10px;
}
This will cause .cell to have a width of 320px (100% + 10px + 10px), and overflow .container.
Let me know if that helps clear things up.
The way you have it is fine. Each cell calculates to 75px. The only times you have to be careful with percentages is when rounding kicks in.
In your example, if you're container was 303px, each cell would evaluate to 75.66666px and round up to 76px, for a total of 304px which would be larger than the container. That one pixel causes all kinds of trouble.
From the research I have done, it appears how you target your CSS(id,class,universal...etc) is most important in browser render performance.
Efficiently Rendering CSS
Writing Efficient CSS for use in the Mozilla UI
Optimize browser rendering
I can't find any documented evidence with test cases to prove this. Could you point us to where you read about this?
I find mixing the two quite useful and I see it a lot out in the wild on reputed / high traffic sites also.
The only issue that mostly affects older browsers and IE is rounding. Have a read here:
http://ejohn.org/blog/sub-pixel-problems-in-css/
http://agilewebmasters.com/robert/percentage-rounding-and-sub-pixel-perfection/
How does one go about establishing a CSS 'schema', or hierarchy, of general element styles, nested element styles, and classed element styles. For a rank novice like me, the amount of information in stylesheets I view is completely overwhelming. What process does one follow in creating a well factored stylesheet or sheets, compared to inline style attributes?
I'm a big fan of naming my CSS classes by their contents or content types, for example a <ul> containing navigational "tabs" would have class="tabs". A header containing a date could be class="date" or an ordered list containing a top 10 list could have class="chart". Similarly, for IDs, one could give the page footer id="footer" or the logo of the website id="mainLogo". I find that it not only makes classes easy to remember but also encourages proper cascading of the CSS. Things like ol.chart {font-weight: bold; color: blue;} #footer ol.chart {color: green;} are quite readable and takes into account how CSS selectors gain weight by being more specific.
Proper indenting is also a great help. Your CSS is likely to grow quite a lot unless you want to refactor your HTML templates evertime you add a new section to your site or want to publish a new type of content. However hard you try you will inevitably have to add a few new rules (or exceptions) that you didn't anticipate in your original schema. Indeting will allow you to scan a large CSS file a lot quicker. My personal preference is to indent on how specific and/or nested the selector is, something like this:
ul.tabs {
list-style-type: none;
}
ul.tabs li {
float: left;
}
ul.tabs li img {
border: none;
}
That way the "parent" is always furthest to the left and so the text gets broken up into blocks by parent containers. I also like to split the stylesheet into a few sections; first comes all the selectors for HTML elements. I consider these so generic that they should come first really. Here I put "body { font-size: 77%; }" and "a { color: #FFCC00; }" etc. After that I would put selectors for the main framework parts of the page, for instance "ul#mainMenu { float: left; }" and "div#footer { height: 4em; }". Then on to common object classes, "td.price { text-align: right; }", finally followed by extra little bits like ".clear { clear: both; }". Now that's just how I like to do it - I'm sure there are better ways but it works for me.
Finally, a couple of tips:
Make best use of cascades and don't "overclass" stuff. If you give a <ul> class="textNav" then you can access its <li>s and their children without having to add any additional class assignments. ul.textNav li a:hover {}
Don't be afraid to use multiple classes on a single object. This is perfectly valid and very useful. You then have control of the CSS for groups of objects from more than one axis. Also giving the object an ID adds yet a third axis. For example:
<style>
div.box {
float: left;
border: 1px solid blue;
padding: 1em;
}
div.wide {
width: 15em;
}
div.narrow {
width: 8em;
}
div#oddOneOut {
float: right;
}
</style>
<div class="box wide">a wide box</div>
<div class="box narrow">a narrow box</div>
<div class="box wide" id="oddOneOut">an odd box</div>
Giving a class to your document <body> tag (or ID since there should only ever be one...) enables some nifty overrides for individual pages, like hilighting the menu item for the page you're currently on or getting rid of that redundant second sign-in form on the sign-in page, all using CSS only. "body.signIn div#mainMenu form.signIn { display: none; }"
I hope you find at least some of my ramblings useful and wish you the best with your projects!
There are a number of different things you can do to aid in the organisation of your CSS. For example:
Split your CSS up into multiple files. For example: have one file for layout, one for text, one for reset styles etc.
Comment your CSS code.
Why not add a table of contents?
Try using a CSS framework like 960.gs to get your started.
It's all down to personal taste really. But here are a few links that you might find useful:
http://www.smashingmagazine.com/2008/08/18/7-principles-of-clean-and-optimized-css-code/
http://www.smashingmagazine.com/2008/05/02/improving-code-readability-with-css-styleguides/
http://www.louddog.com/bloggity/2008/03/css-best-practices.php
http://natbat.net/2008/Sep/28/css-systems/
Think of the CSS as creating a 'toolkit' that the HTML can refer to. The following rules will help:
Make class names unambiguous. In most cases this means prefixing them in a predicatable way. For example, rather than left, use something like header_links_object2_left.
Use id rather than class only if you know there will only ever be one of an object on a page. Again, make the id unambiguous.
Consider side effects. Rules like margin and padding, float and clear, and so on can all have unexpected consequences on other elements.
If your stylesheet is to be used my several HTML coders, consider writing them a small, clear guide to how to write HTML to match your scheme. Keep it simple, or you'll bore them.
And as always, test it in multiple browsers, on multiple operating systems, on lots of different pages, and under any other unusual conditions you can think of.
Putting all of your CSS declarations in roughly the same order as they will land in the document hierarchy is generally a good thing. This makes it fairly easy for future readers to see what attributes will be inherited, since those classes will be higher up in the file.
Also, this is sort of orthogonal to your question, but if you are looking for a tool to help you read a CSS file and see how everything shakes out, I cannot recommend Firebug enough.
The best organizational advice I've ever received came from a presentation at An Event Apart.
Assuming you're keeping everything in a single stylesheet, there's basically five parts to it:
Reset rules (may be as simple as the
* {margin: 0; padding: 0} rule,
Eric Meyer's reset, or the YUI
reset)
Basic element styling; this
is the stuff like basic typography
for paragraphs, spacing for lists,
etc.
Universal classes; this section
for me generally contains things
like .error, .left (I'm only 80%
semantic), etc.
Universal
layout/IDs; #content, #header,
or whatever you've cut your page up
into.
Page-specific rules; if you
need to modify an existing style
just for one or a few pages, stick a
unique ID high up (body tag is
usually good) and toss your
overrides at the end of the document
I don't recommend using a CSS framework unless you need to mock something up in HTML fast. They're far too bloated, and I've never met one whose semantics made sense to me; it's much better practice to create your own "framework" as you figure out what code is shared by your projects over time.
Reading other people's code is a whole other issue, and with that I wish you the best of luck. There's some truly horrific CSS out there.
Cop-out line of the year: it depends.
How much do you need to be styling? Do you need to change the aspects of alomost every element, or is it only a few?
My favorite place to go for information like this is CSS Zen Garden & A List Apart.
There are two worlds:
The human editor perspective: Where CSS is most easily understand, when it has clear structure, good formatting, verbose names, structured into layout, color and typesetting...
The consumer perspective: The visitor is most happy if your site loades quickly, if it look perfect in his browser, so the css has to be small, in one file (to save further connections) and contain CSS hacks to support all browsers.
I recommend you to start with a CSS framework:
Blueprint if you like smaller things
or YAML for a big and functional one
There is also a list of CSS Frameworks...
And then bring it in shape (for the browser) with a CSS Optimizer (p.e. CSS Form.&Opti.)
You can measure the Results (unpotimized <-> optimized) with YSlow.
A few more tips for keeping organized:
Within each declaration, adopt an order of attributes that you stick to. For example, I usually list margins, padding, height, width, border, fonts, display/float/other, in that order, allowing for easier readability in my next tip
Write your CSS like you would any other code: indent! It's easy to scan a CSS file for high level elements and then drill down rather than simply going by source order of your HTML.
Semantic HTML with good class names can help a lot with remembering what styles apply to which elements.