A lot of the stuff I learn about CSS is just from inspecting websites created by other developers. So, when I’m surfing along and something catches my eye, I will inspect the element, and sometimes look at the style sheet to see what is going on behind the scenes.

Today, I was looking at a site and saw that the H1 text was a non-standard browser font. We have been doing the Google font import thing and I was wondering if the developer of this site had imported the font from Google. So I inspected the H1, saw that it was a custom font and then I went to the style sheet to see where it had been imported from… to my surprise, it had not been imported from Google or a paid web font repository. It was a font stored in a local directory on the web server. This approach would be the equivalent of putting a fonts directory in the theme folder in a wordpress site, then setting up the stylesheet to use fonts in there.

Here is the code which was used to add the font to the style sheet:


@font-face {
font-family: 'DirtyHeadline';
src: url('fonts/dirty_headline-webfont.eot');
src: local('?'),
url('fonts/dirty_headline-webfont.woff') format('woff'), 
url('fonts/dirty_headline-webfont.ttf') format('truetype'), 
url('fonts/dirty_headline-webfont.svg#webfontzwLyc702') format('svg');
font-weight: normal;
font-style: normal;

I did some research on this method, and here is a breakdown of how it works.

  • @font-face — This tells the browser it will be providing support for a non-standard font.
  • font-family: ‘DirtyHeadline’; — This is a friendly reference name for the font. It can be anything. It is used to call the font as in: h1{font-family:DirtyHeadline;}
  • src: url(‘fonts/dirty_headline-webfont.eot’); — IE 5+ only supports the eot format. This tell the browser the font location and file name

I’m going to put the next part on separate lines so it is easier to understand. It could be implemented this way and would work fine.

  • src: local(‘?’), — When a browser displays a font like this, it actually downloads the font into a local cache. This tells the computer to assign a fictional name to the font as it loads it into the local cache, to avoid any possible collisions with locally installed fonts on the computer.
  • url(‘fonts/dirty_headline-webfont.woff’) format(‘woff’), — The .WOFF format (Newer Mozilla Browsers supports this) and the path to the WOFF file
  • url(‘fonts/dirty_headline-webfont.ttf’) format(‘truetype’), — ., the .TTF format (Older Mozilla Browsers, Safari, Opera, Chrome) and path to the TTF file.
  • url(‘fonts/dirty_headline-webfont.svg#webfont’) format(‘svg’); — the .SVG format for iPhone, Newer Chrome, and Opera browsers.

And lastly,

  • font-weight: normal; — Defines the default weight of the font. Needed for webkit browsers.
  • font-style: normal; — Defines the default style (italic, underline, strikethough, etc.)
  • Without these, Webkit browsers will ignore any weight or style commands and the designer won’t be able to assign weight values to the font when assigning it to an element definition.

After this setup is completed in the style sheet, you can call the font anywhere you want using it’s friendly name (as you normally would when assigning a font to a class or element, font-family:DirtyHeadline;).

With this information, it is easy to see how custom fonts can be used on websites, loaded from a local directory. This means you can use any font you want, as long as you have it in each required format (for cross browser support). For any font you want to use, you need a directory containing the EOT, WOFF, TTF, and SVG versions. So, what’s the trick? Finding a font in all of those versions can be tricky, but here is a site that provides a ton of “Kits” that contain everything needed to implement the font with cross browser support, FREE:


My resources:

  • http://sixrevisions.com/css/font-face-guide/
  • http://www.css3.info/preview/web-fonts-with-font-face/

Check out our CMS Design Page for more information about how we can make your site better!

Data Annotations


You may have found code samples to generate your own Data Annotations handler for Web Forms.  You may have found incomplete or broken examples.  Stop.  Use this instead:  http://davalidation.codeplex.com/

You can do client validation in C# .Net using Data Annotations using this commonly referenced page by Gil Fink:


From this article, it is important to note that the DataAnnotationValidator class MUST be in a Server Control project and referenced as an Assembly.  It is possible that this can be resolved by putting the class in App_Code and removing Assembly from your Register directive:

Create a new Web Server Control Project in your Solution.  Delete the automatically created class file and replace it with the contents from the web page listed above.

Reference the new Assembly/Project in your original Project.


If you try the App_Code technique you will need to change:

<%@ Register TagPrefix=”val” Namespace=”Validator” Assembly=”dotNetValidator” %>

to <%@ Register TagPrefix=”val” Namespace=”Validator” %>

Unfortunately, the App_Code technique didn’t work for me in Visual Studio 2010, which doesn’t want to make an App_code folder.


NOTE:  Here is similar code for client validation in VB:


    I have not tried this code and don’t know if it suffers from the same problem.  Perhaps it doesn’t in VB.net.


Unfortunately, the C# code doesn’t work because it tests the class Type in the Assembly instead of in the calling Web Project.  This causes an InvalidOperationException error in GetValidatedType. (The returned Type is null.)

This problem was noticed by Alex Ford on stackoverflow:  http://stackoverflow.com/questions/5600707/how-do-you-do-web-forms-model-validation. However, the posted solution has the same problem and wasn’t explained in detail.  But is does accurately describe the problem.  And ultimately, this code cannot get the PropertyName validation info necessary.  Stick with the original code.

Data Annotations Solution

So, how do you request a Type check against the calling Assembly?  I found this:  http://generally.wordpress.com/2007/06/01/typegettype-and-referred-assemblies/. Which accurately describes how to dictate the Assembly to search for the Type.

Referring back to Gil’s original article, this syntax was used but not explained.  The calling Assembly , and due to the brief code provided did not state the behaviour or syntax of SourceTypeName.

When using SourceTypeName, you MUST indicate the class name and the calling assembly like this:

<val:DataAnnotationValidator ID=”valID” runat=”server” ControlToValidate=”MyWebControlToValidate” PropertyName=”MyClassVariableToValidate” SourceTypeName=”MyClassToValidateAVariable, MyApplicationAssemblyName” /



<val:DataAnnotationValidator ID=”valID” runat=”server” ControlToValidate=”FirstName” PropertyName=”FirstName” SourceTypeName=”Person, MyWebApp”


For a completely different approach and a complete NuGet package: amanek.com/building-data-annotations-validator-control-with-client-side-validation/

To validate a control before submit: http://www.codeproject.com/Articles/185943/Validation-in-NET-Framework-4

See our Contact Page for more information!