Question? Leave a message!

How to use a CSS file in html

how to use a css reset and how to use a css template and how to use css media queries
Dr.LewisFinch Profile Pic
Published Date:15-07-2017
Website URL
Smashing eBook 19 Mastering CSS3 8This gave me a blank canvas to add visual enhancements. The index page shows the end of my day 1 work, as well as what unsupported browsers will display, the appearance of which is structurally intact and visually pleasing. More on this later, but the way I see it, older browsers aren’t penalized with a broken layout, and modern browsers are rewarded with a few visual bonuses. Part of implementing CSS3 is about planning ahead and designing websites that look fine as a fallback. Day 2 Starting with the base index page, I created a CSS3 page. It took 49 minutes to complete. Here is the CSS code (css3.css): /-CSS3 Started on 2/26/11 at 7:28 AM CST-/ h1 text-shadow: -3px 2px 0px 514d46; nav -moz-box-shadow: 0px 0px 12px rgba(88, 83, 74, .7); -webkit-box-shadow: 0px 0px 12px rgba(88, 83, 74, .7); box-shadow: 0px 0px 12px rgba(88, 83, 74, .7); background-image: -moz-linear-gradient(top, 5c5850, 48473e); background-image: -webkit-gradient(linear,left top,left bottom,color-stop(0, 5c5850),color-stop(1, 48473e)); background-image: -webkit-linear-gradient(5c5850, 48473e); background-image: linear-gradient(top, 5c5850, 48473e); nav a -moz-border-radius: 12px; -webkit-border-radius: 12px; border-radius: 12px; nav a:hover background-color: 3a3e38; background-color: rgba(47, 54, 48, .7); nav background-color: 070807; Smashing eBook 19 Mastering CSS3 9 background-color: rgba(7, 8, 7, .7); body background-image: -webkit-gradient(radial, 50% 10%, 0, 50% 10%, 500, from(FBF8E3), to(E6E3D0)); background-image: -moz-radial-gradient(50% 10%, farthest- side, FBF8E3, E6E3D0); learn_more, details img -moz-border-radius: 8px; -webkit-border-radius: 8px; border-radius: 8px; -webkit-box-shadow: inset 0px 0px 8px rgba(88, 83, 74, .2); -moz-box-shadow: inset 1px 0px 1px rgba(88, 83, 74, .2); box-shadow: inset 0px 0px 1px rgba(88, 83, 74, .2); learn_more a -moz-border-radius: 8px; -webkit-border-radius: 8px; border-radius: 8px; background-color: cc3b23; background-image: -moz-linear-gradient(top, cc3b23, c00b00); background-image: -webkit-gradient(linear,left top,left bottom,color-stop(0, cc3b23),color-stop(1, c00b00)); background-image: -webkit-linear-gradient(cc3b23, c00b00); background-image: linear-gradient(top, cc3b23, c00b00); a -moz-transition: all 0.3s ease-in; -o-transition: all 0.3s ease-in; -webkit-transition: all 0.3s ease-in; transition: all 0.3s ease-in; /-CSS3 Finished on 2/26/11 at 8:17 AM CST (49 minutes) -/ Smashing eBook 19 Mastering CSS3 10Day 3 I added visual enhancements by slicing and CSS’ing background images directly from the PSD. Even though there is less code, all of the extra app- switching and image-slicing added up to a total of 73 minutes to complete. Check out the page for the CSS image-based approach. Here’s the code (css.css): /-CSS (the image-based approach) Started on 2/27/11 at 12:42 PM CST-/ header background: url(../img/navbg.png) left top repeat-x; body background: e6e3d0 url(../img/radial_gradient.jpg) no- repeat center top; nav background-color: transparent; h1 background: url(../img/mercuryautomobiles.png) no-repeat center center;text-indent: -9999px; learn_more background-image: url(../img/learn_morebg.jpg); details img background-image: url(../img/detailsbg.jpg); learn_more a background: url(../img/learn_more_abg.jpg) no-repeat; .css3 background: url(../img/css3_hover.png) no-repeat center top; .smashing background: url(../img/smashing_hover.png) no-repeat center top; .trent background: url(../img/trentwalton_hover.png) no-repeat center top; .css3:hover Smashing eBook 19 Mastering CSS3 11 background: url(../img/css3_hover.png) no-repeat center -20px; .css:hover background: url(../img/css_hover.png) no-repeat center -20px; .smashing:hover background: url(../img/smashing_hover.png) no-repeat center -20px; .trent:hover background: url(../img/trentwalton_hover.png) no-repeat center -20px; .css background: url(../img/css_hover.png) no-repeat center -50px; /-CSS (the image-based approach) Finished on 2/27/11 at 1:55 AM CST (1 hour and 13 minutes)-/ Smashing eBook 19 Mastering CSS3 12Production Time Results So, we’re looking at a 24-minute difference: 49 minutes to add visual enhancements with CSS3, and 73 minutes to do it with images. For me, CSS3 was not only quicker but far more enjoyable, because I was focused on only one window (my CSS editor), unless I opted to pull some of the code from CSS3 Please. On the other hand, slicing images and switching from Photoshop to FTP to the CSS editor and back again was a hassle, and it did take longer. It’s also worth noting that I did my best to stack the deck against CSS3. I coded it first so that any initial hashing out would be done before heading into day 3. Also, the images I did slice are as optimized as I could reasonably make them: one-pixel repeating slivers, and medium-resolution image exports. Overall, 24 minutes may not seem like a lot of time, but this is a fairly simple page. Imagine how much time (and money) could be saved over the course of a year. What? Still not convinced?… File Size And Loading Time Results I took both of my pages over to Pingdom Tools to compare file size and loading times. Smashing eBook 19 Mastering CSS3 13Both pages are pretty fast, but CSS3 prevailed, with 10 fewer requests and a file size that was lighter by 81.3 KB. While loading times were close, the larger PNG files used on both pages accounted for most of the heft, which amounted to a .75 second difference on average. And when we’re talking 3 to 6 second loading times, those differences sure can add up. CSS3 CSS Difference Size 767.9 KB 849.2 KB 81.3 KB Requests 12 22 10 Smashing eBook 19 Mastering CSS3 14For argument’s sake, I created yet another version of the image-based CSS version, with a sprite containing all four images used in the original version, and then I measured loading times. This CSS Sprited version did improve things, taking HTTP requests from 22 to 19 and the overall size from 849.2 KB down to 846.7 KB. The way I see it, these differences are minimal and would have added to the development time, so it’s all relative. Without getting too sidetracked, I think the difference in loading times is significant. If a website gets 100 hits a day, the difference may not matter much, but on a higher traffic website the effect compounds. Shaving seconds or even milliseconds off the loading time of a website is no small improvement in user experience. The image-based approach could lead to upwards of a 15 to 27% drop in page traffic (based on a 5 to 9% per 400 ms rate). That’s a lot of dinero to lose. I wonder how much time and money could be saved by serving a CSS3 border-radius sign-up button on a website with as much traffic as Twitter’s. Smashing eBook 19 Mastering CSS3 15Another striking example is all the CSS3 that can be found in Gmail’s interface. The CSS3 gradients and rounded corners are there to increase page speed. Speaking of Gmail’s continued use of HTML5 (and CSS3), Adam de Boor had this to say about speeding up page rendering: Google’s current goal is to get Gmail to load in under a second. Speed is a feature.” And this: The company has found that using CSS3 can speed the rendering time by 12 percent. Convinced yet? No? Okay, I’ll keep going… Smashing eBook 19 Mastering CSS3 16inking About e Future WEBSITE UPDATES: THE EASY WAY AND THE HARD WAY CSS3 really pays off when it comes to making updates and future-proofing Web pages from a maintenance perspective. Looking at the Mercury Automobiles website, think about what would have to go into changing the height of the three-column car images or the width of the bubble hover states for the navigation. For the sake of a quick production, I sliced these images to match precisely. One option would be to open Photoshop, rebuild and resize the images, update the appropriate CSS properties, and upload. Another would be to plan ahead and slice “telescoping” images, making one end a short rounded corner cap and another longer image on the opposite end that slides to fill the interior space. You’ve probably seen and done this before: div class="border_box_top"/div div class="border_box_bottom" img src="your_content_here.jpg" / /div Smashing eBook 19 Mastering CSS3 17This isn’t ideal. While the technique comes in handy in a variety of instances, adding extra HTML just to achieve a rounded corner doesn’t seem efficient or sensible. WHAT IF YOU WANT TO GO RESPONSIVE? Serving different-sized images and changing the font size to suit a particular screen resolution simply couldn’t happen without CSS3. It’s wonderful how all of these new properties work together and complement each other. Imagine how time-consuming it would be to res-lice background images to accommodate varying image and font sizes that display at different screen resolutions. Yuk. e Take-Away For me, this simply proves what I’ve known all along: CSS3 pays off when it comes to production, maintenance and load times. Let’s revisit the numbers once more… Smashing eBook 19 Mastering CSS3 18CSS CSS3 Results Production 73 minutes 49 minutes CSS3 33% faster time Size 849.2 KB 767.9 KB CSS3 9.5% smaller Requests 22 12 CSS3 45% fewer Yes, this is just one experiment, and the outcome was influenced by my own abilities. This isn’t meant to finally prove that implementing CSS3 no matter what will always be the right way to go. It’s just food for thought. I encourage you to track development and loading times on the websites you work on and make the best decision for you and, of course, your client. We’re all concerned about browser compatibility, and opinions will differ. For me and most of my clients, this would be a perfectly acceptable fallback. Perhaps with more experiments like this that yield similar results, these statistics could be cited to both employers and clients. If a website could be produced 49% faster (or even half of that) with CSS3, imagine the benefits: money saved, earlier launch times, more time spent on adding “extras” that push the product over the top, not to mention a better browsing experience for everyone. Smashing eBook 19 Mastering CSS3 19Why We Should Start Using CSS3 And HTML5 Today Vitaly Friedman For a while now, here on Smashing Magazine, we have taken notice of how many designers are reluctant to embrace the new technologies such as CSS3 or HTML5 because of the lack of full cross-browser support for these technologies. Many designers are complaining about the numerous ways how the lack of cross-browser compatibility is effectively holding us back and tying our hands — keeping us from completely being able to shine and show off the full scope of our abilities in our work. Many are holding on to the notion that once this push is made, we will wake to a whole new Web — full of exciting opportunities just waiting on the other side. So they wait for this day. When in reality, they are effectively waiting for Godot. Just like the elusive character from Beckett’s classic play, this day of full cross-browser support is not ever truly going to find its dawn and deliver us this wonderful new Web where our work looks the same within the window of any and every Web browser. Which means that many of us in the online reaches, from clients to designers to developers and on, are going to need to adjust our thinking so that we can realistically approach the Web as it is now, and more than likely how it will be in the future. Sometimes it feels that we are hiding behind the lack of cross-browser compatibility to avoid learning new techniques that would actually dramatically improve our workflow. And that’s just wrong. Without an adjustment, we will continue to undersell the Web we have, and the Smashing eBook 19 Mastering CSS3 20landscape will remain unexcitingly stale and bound by this underestimation and mindset. Adjustment in Progress Sorry if any bubbles are bursting here, but we have to wake up to the fact that full cross-browser support of new technologies is just not going to happen. Some users will still use older browsers and some users will still have browsers with deactivated JavaScript or images; some users will be having weird view port sizes and some will not have certain plugins installed. But that’s OK, really. The Web is a damn flexible medium, and rightly so. We should embrace its flexibility rather than trying to set boundaries for the available technologies in our mindset and in our designs. The earlier we start designing with the new technologies, the quicker their wide adoption will progress and the quicker we will get by the incompatibility caused by legacy browsers. More and more users are using more advanced browsers every single day, and by using new technologies, we actually encourage them to switch (if they can). Some users will not be able to upgrade, which is why our designs should have a basic fallback for older browsers, but it can’t be the reason to design only the fallback version and call it a night. Smashing eBook 19 Mastering CSS3 21Selectivizr is one of the many tools that make it possible to use CSS3 today. There are so many remarkable things that we, designers and developers, can do today: be it responsive designs with CSS3 media queries, rich Web typography (with full support today) or HTML5 video and audio. And there are so many useful tools and resources that we can use right away to incorporate new technologies in our designs while still supporting older browsers. There is just no reason not to use them. Smashing eBook 19 Mastering CSS3 22We are the ones who can push the cross-browser support of these new technologies, encouraging and demanding the new features in future browsers. We have this power, and passing on it just because we don’t feel like there is no full support of them yet, should not be an option. We need to realize that we are the ones putting the wheels in motion and it’s up to us to decide what will be supported in the future browsers and what will not. More exciting things will be coming in the future. We should design for the future and we should design for today — making sure that our progressive designs work well in modern browsers and work fine in older browsers. The crucial mistake would be clinging to the past, trying to work with the old nasty hacks and workarounds that will become obsolete very soon. We can continue to cling to this notion and wait for older browsers to become outdated, thereby selling ourselves and our potential short, or we can adjust our way of thinking about this and come at the Web from a whole new perspective. One where we understand the truth of the situation we are faced with. That our designs are not going to look the same in every browser and our code will not render the same in every browser. And that’s the bottom line. Smashing eBook 19 Mastering CSS3 23Yaili’s beautiful piece My CSS Wishlist on Articles like these are the ones that push the boundaries of web design and encourage more innovation in the industry. Smashing eBook 19 Mastering CSS3 24Andy Clarke spoke about this at the DIBI Conference earlier this year (you can check his presentation Hardboiled Web Design on Vimeo). He really struck a nerve with his presentation, yet still we find so many stalling in this dream of complete Web standardization. So we wanted to address this issue here and keep this important idea being discussed and circulated. Because this waiting is not only hurting those of us working with the Web, but all of those who use the Web as well. Mainly through this plethora of untapped potential which could improve the overall experience across the spectrum for businesses, users and those with the skills to bring this sophisticated, rich, powerful new Web into existence. FOR OUR CLIENTS Now this will mean different things for different players in the game. For example, for our clients this means a much more developed and uniquely crafted design that is not bound by the boxes we have allowed our thinking to be contained in. However, this does come with a bit of a compromise that is expected on the parts of our clients as well. At least it does for this to work in the balanced and idealized way these things should play out. But this should be expected. Most change does not come without its compromises. In this case, our clients have to accept the same truism that we do and concede that their projects will not look the same across various browsers. This is getting easier to convince them of in these times of the expanding mobile market, but they may still not be ready to concede this inch on the desktop side of the coin. Prices might be adjusted in some cases too, and that may be another area that the clients are not willing to accept. But with new doors being opened and more innovation, comes more time and dedicated efforts. These are a few of the implications for our clients, though the expanded innovation is where we should help them focus. Smashing eBook 19 Mastering CSS3 25In short: • Conceding to the idea that the project will not be able to look the same across various browsers, • This means more developed and unfettered imaginative designs for our clients, • This could lead to increased costs for clients as well, but with higher levels of innovation and • Client’s visions for what they want will be less hindered by these limitations. FOR THE USERS The users are the ones who have the least amount invested in most of what is going on behind the scenes. They only see the end result, and they often do not think too much about the process that is involved which brings it to the screens before them. Again, with the mobile market, they have already come across the concept of varying interfaces throughout their varied devices. They only care about the functionality and most probably the style that appeals to them — but this is where their interest tends to end. Unless of course, they too are within the industry, and they may give it a second thought or more. So all this talk of cross-browser compatibility really doesn’t concern them, they really leave all that up to us to worry about. Smashing eBook 19 Mastering CSS3 26