Tag Archives: css

Simple Responsive Web Design

Just completed my first pass at making my site http://greggrichter.com, ‘Responsive’. For those not familiar with the term, it simply means that I am optimizing my site to dynamically change it’s layout depending on the screen size and device type you are accessing it from.  So users who come to my site from a smart phone will see the site optimized for their device.  Where as someone accessing the site from a traditional PC with a screen size of say 1000px wide, will receive a different view of the site.  This is of course a different approach than redirecting users to a mobile specific version of the site like you might see when you go to The Seattle Times. In that method, users that access http://seattletimes.com from an iPhone will be redirected to http://mobile.seattletimes.com for a layout optimized for their device.  Two completely separate pages.  The Responsive method I’m implementing serves up the same page for all device and screen sizes and dynamically adjusts the content and layout as specified. *note, at the time of this blog post, I have not implemented the same responsiveness to this blog.  Let’s call that phase 2.

For this initial pass, I took a very simplified approach. First, I had no desire to completely change the existing fixed width layout and code for my site so I left it as is. Second, I then used media queries to present new layout’s for pixel width breakpoints that I determined through trial and error. For now, I am only targeting traditional smart phone width’s and tablets in portrait mode as the site as-is renders fine in landscape mode. I will at some point need to add in even more breakpoints as the small tablet devices like the Kindle Fire and soon to be released iPad mini, will introduce a new set of users.

If I were to create a site from scratch I would be using fluid grid layouts with images that scale and up and down.  But again, I am retrofitting my existing site and want a simple and effective approach.

My three layouts then are:

greggrichter.com on a standard laptopExisting. Which looks great on anything at least 911px wide.

 

 

 

 

Large tablet portrait. Let’s be honest and call it an iPad. Anything less than 910px wide, but greater than #3, which is…

 

 

 

 

 

greggrichter.com on an iphoneSmart phone. Which I have set at anything less than 595px wide as the break point but actually the content is only about 286px wide.  I just center it.  Soon I’ll put another breakpoint in at 300px and build a mini-tablet layout for the 300 – 595px range.

 

 

 

 

To implement this is extremely simple. For each one of the breakpoints listed above, I added a media query to the end of my style sheet in the following format:

@media screen and (max-width: 910px){}

Within the two {} brackets, I grab my already established elements, id’s, classes, etc and apply new style rules to them. Only screens with a width of less than what I specify will render it.

Order matters here, so do these in order from top to bottom with biggest screen size at the top and smallest at the bottom.

For my smart phone view, I actually removed quite a bit of content like an image slideshow and other items and simply achieved this by using the CSS style ‘display:none’ on elements I didn’t want to be shown. Word of warning, just because you are using ‘display:none’ doesn’t mean you aren’t still downloading the entire page contents to the device… you are. I can get away with this on my site because I kept it extremely light to begin with.

You’ll also need to be sure and add a meta viewport tag to your header as follows:

<meta name=”viewport” content=”width=device-width, initial-scale=1.0″ />

If you want to get in deep with Responsive Web Design, then buy this book.

Also, here is a great article in Wikipedia on RWD, http://en.wikipedia.org/wiki/Responsive_Web_Design.

And here is a link to my sites stylesheet. Scroll to the bottom to see the media query pieces. http://greggrichter.com/css/gsr.css

Lastly, if you want to see RWD in action, load my main page, http://greggrichter.com from a browser on your laptop or desktop and then resize the browser from biggest to smallest, and watch the content change dynamically.

Embedding Custom Fonts in to Web Pages


If you commonly hear people shouting "WTF?" when accessing your web pages, it's likely that they simply want to know, "Where's The Font?".   As in, why is the entire page in Arial, or Times New Roman, or Helvetica, or Verdana, or Georgia...?
I have been elbow deep in custom font's for my latest project (in Development) and thought I would put together a short article compiling what I've learned.

1st - a little preachin'.  Stop using images as a replacement for text.  If you have important text like a business name, a primary function, a description of a business or event, etc, making that an image instead of using text significantly hampers your SEO (Search Engine Optimization).  Search Engines like Bing, Google, and Yahoo, primarily use the actual text on your page for SEO.  Images are not text.  Only text is text.  Of course there are times when a text image is absolutely necessary (logos, super-rich graphic design of text, etc), but all of your h tags (h1, h2, etc) should be text.  And that means, don't just hide the text with CSS and put a background image in it's place... search engines don't like this and see it as potentially deceptive.

2nd - go get your font on.  There are a ton of font websites out there with all sorts of cool fonts available for free or a minimal charge (read the licensing agreement for these fonts).  I like sites like dafont.com and/or searching 'font' in places like Smashing Magazine archives.

3rd - the font file types.  For embedding custom fonts on to your web page, there are 3 file types you need to know and love  (.ttf .otf .eot).  In a nutshell, .ttf and .otf are fine and dandy for Firefox, Chrome, Safari, and Opera... but of course, not Internet Explorer.  To embed custom fonts in IE, you need use the .eot file format.  Why?  Because that's what one guy in Redmond decided.

4th - conversion to the dark side. 99% of the fonts you are going to find on the internet are going to be in the .ttf format.  So before we get to writing our CSS you must convert your .ttf files to .eot files so your pretty custom fonts will work across all browsers (using both the .ttf and .eot files).  A quick Google search for font converters will lead you to sites like here or here.

5th - upload. For this example, we'll assume you found a cool font called fancyFont.ttf and have successfully converted to a .eot file. From here, create a folder in your ROOT directory titled 'font' and upload your fancyFont.ttf and fancyFont.eot files to this place.

6th - the CSS. At the top of your CSS doc we are going to specify the @font-face selector like this:

@font-face{
font-family: 'fancyFont'; /*This is the name of the font that you will call later*/
src: url('/font/fancyFont.eot'); /*Calling the font for IE. List this one first*/
src: local('fancyFont'), url('/font/fancyFont.ttf') format ('truetype'); /*non IE browsers*/
}

The above code basically tells IE, hey go look at this URL for my custom font. After that it tells all the other browsers to look for the font on the local machine first and if not found to go to the URL as well.

7th - call the font. Now call your font in the CSS doc using your HTML element that your corresponding text is located in. So, if you want all paragraphs on your web page to display your new fancyFont you would write it in the CSS doc like so:

p { /* p being the HTML paragraph element */
font-family: 'fancyFont'; /*when calling the font use quotes and don't list the file type ext*/
}

Items of note...

Case matters. Your web page will distinguish between FANCYFONT.TTF and fancyfont.ttf.  Whatever your file is saved as, should be how you write it in your CSS.

Space matters. As a matter of best practice.  Eliminate spaces in your file names.  fancy font.ttf will cause you more problems than fancyFont.ttf.

Weight matters. Some fonts will look exactly as you intended in one browser and oddly thicker or thinner in another.  A specific example I have is one font that looks exactly as intended in Google Chrome, but quite thick (or heavy) in Firefox.  Adding the string 'font-weight: lighter;' to my CSS for the corresponding element fixed the problem in Firefox while not changing the weight at all in Chrome.

Size matters.  A lot of these custom fonts look dramatically different when only 18px big vs. 60px big.  Flaws in the design and inconsistency between characters become quite evident when the characters get big.

Now go get your font on.

Gregg - http://richterwebdesign.com