If you don’t already know what DRM is, you should probably google it. Digital Rights Management is the way in which software companies attempt to protect their copyrights by preventing access or copying, requiring online authentication for software, limiting installations, and restricting purchased downloads, etc.

There is a lot of controversy on the subject of DRM, and entire organizations have been created to fight against it. Companies have tried denying its use, and been caught in the lie. Some publishers agree that it’s too restrictive and don’t use it. Gamers the world over are tired of having to deal with it.

One of the best quotes I’ve seen on the subject was shown to me by a colleague on twitter: “DRM is a fence the consumer has to climb, while pirates drill a hole and go through. The more DRM the higher the fence is and the harder it is for the consumer, while the pirates still just go right through.”

In my blog I go into a little more detail about the effects of DRM, the perspective of gamers and of manufacturers, and the reality that is somewhere in between. You can find the full post here: Is DRM ruining the Gamer’s Experience?

You can also find another perspective on the subject posted by one of the people I interviewed for the piece, a game reviewer and fellow member of the BGC here: DRM or not DRM, that is the question

Enjoy the reads, and feel free to post your own thoughts!

Also, if you’re interested in the level of DRM on your games, check out this site: Reclaim Your Game

In September I took a class on teambuilding for my Game Design Degree. I went into the class thinking it’d be slack… after all, I’ve led teams before, use teams at work, and micromanage game guilds (much to their annoyance). What actually happened is that I learned WHY I do the things I do, and I also learned some valuable lessons about the team dynamic and my own weaknesses.

I want to say, first off, that I was blessed with an awesome assigned team. We were all willing to work hard and spend the time to succeed, and we all had the skill and drive to get through our class goals. We meshed well, and had no major destructive moments. I found, though, that even with a near perfect team there are hurdles to overcome. Let me elaborate…

Communication

We emailed each other maybe three times a week, sometimes more. We all had access to Skype for instant messaging, and some of us used it often. We also held our meetings in Skype chat at least twice a week, some of which where more than 6 hours long when we went into power mode…

That is not enough.

The problem with online collaboration is that so much gets missed in the cold voids between typed words that it takes much longer to get your point across, and that point often needs to be reinforced and refined over and over again. Some of us had that level of communication through Skype chat, as we messaged each other throughout the day to ask questions or pass along information. Other members of the team answered emails and showed up at the meetings, but had a definite lack of presence between those times. We communicated well when we communicated, but it wasn’t nearly often enough to reach our full potential.

Another aspect of team communication that is absolutely essential in online environments is getting to know your team. You may think that socializing is a waste of time, but let me put it to you this way… When you use instant messaging, much of the tone and emotion of the conversation comes from knowing the person typing to you. When you encounter a new person online you don’t know when they’re joking, holding back, angry, busy, or anything else until you get used to reading the signs in the way they type. Without this, there can be no real trust between teammates. You will always be second-guessing each other.

Conflict

The communication topic leads nicely into the topic of conflict, primarily because much of the conflict you’ll see between online teams stems from failed communication…

+ I didn’t understand what you meant…
+ I thought we talked about doing it this way instead…
+ I didn’t get copied into your email…
+ I wasn’t at the meeting…
+ The kids were distracting me and I missed what you were saying…
+ I thought you only wanted a reply if I disagreed…
+ I thought you were joking about that…
+ Nobody told me that we had an emergency meeting…

Conflict is inevitable in an online environment. There are a few different ways to handle it, with variable effectiveness, and I’ve pointed out the obvious…

Procedure

There are many procedures created to draw out conflict and help solve it. The web is infested with advice and helpful techniques. Many do not apply to online collaboration. Fail.

The best “procedure” I’ve discovered (hindsight is 20-20) is the idea of team assessment. However, I would personally make it a bit less of an exercise than the texts I’ve read describe. In the most simple terms, a team assessment is the act of deciding how well your team is doing, what they’re doing right, what they’re doing wrong, and what they could do better.

If I took this class again, I would have the entire team do a quick assessment at the end of each week or so. Have each team member write down one thing the team is doing well, one thing the team is doing poorly, one thing for EACH team member to improve upon, and one thing THEY personally need to work on. This way each member comes up with something not only for the entire team, but for themselves. It brings out their own weaknesses and makes them take a good hard look at their participation. It’s also an excellent way to broach a sensitive subject, if you discuss these assessments at the next team meeting.

There are, of course, many ways to document or assess conflict. What works for some may not work for others. The point is to try to draw out the problems before direct confrontation is required.

Confrontation

At first glance, this seems like the same thing as conflict, but in reality it’s “elite” conflict because confrontation implies the conflict is being brought out into the open where it can be potentially solved. Confrontation can result from a team member voicing concerns, from a flare-up of suppressed conflict, or from a third person catalyst that brings all parties together.

Many people shy away from confrontation. How many of us like to be the bad guy in a group? To be the rat? To be the whiner? Maybe you’re afraid that your peers will take offense and you’ll lose credibility with them? Maybe it just isn’t worth the effort? There are a few things I’d like to point out about the choice to avoid confrontation… First, you are damaging the effectiveness of the team, because latent conflict will either stagnate and hold your team back, or eventually explode. Secondly, if your teammates are petty enough to hold constructive criticism against you they aren’t the kind of colleagues that will be a positive contribution to your career anyway.

The thing to remember about confronting the team or a team member, is to be PROFESSIONAL. Never take personal shots, never insult, never yell or swear, never be rude. Anger or accusing behavior only results in more of the same. When you confront a person, state the problem and possibly why it’s a problem, and try to respectfully suggest a solution.

Mediation

When all else fails… when parties are hostile or uncooperative… when things escalate… seek a higher power. Find a neutral party that both sides will listen to, and present your case as clearly and unbiased as possible. A mediator may not be able to fix everything, but it never hurts to get some sound advice, or an outside viewpoint.

The Non-Team Player

My final subject is dealing with the team member that refuses to be a team member. We only experienced the hint of this kind of behavior in our team during class, but a hint was enough to get us talking about it, and thinking about it.

There will often be that one person who doesn’t return emails, doesn’t show up at the meeting, doesn’t talk during the meeting, doesn’t do their work… You know the kind. How do you get them to participate?

Take Out the “Optional”

Don’t make participation based on their initiative. Tell them when to be at the meeting. Ask for their opinion directly in meetings. Assign them tasks. We are not all the same, and some of us need a bit of prodding to get started. If this works, great! If not…

Discuss Participation

This is where the team assessments come in. Bring the subject of participation up in the meeting. Stress that each member is responsible to contribute to the project. Don’t accuse, and don’t name names. Make it a broad statement, and they’ll figure out you’re talking about them. Still not working?

Confrontation

Confront the person. Professionally and respectfully explain, either in person or as a team, that their participation is required. Clearly state your expectations, and allow them to speak. Don’t jump down their throat, but be clear that the behavior isn’t going to be tolerated. Always keep your temper, and if the meeting is getting out of control, end it and either return when heads have cooled, or move on to the next step.

Removal

Sometimes, no matter how hard you try, there’s no reconciling with a person. Once this is clear, take measures to remove the person from the team. Consult higher authorities if necessary, and drop the dead weight. This is an extreme solution, only to be used when there’s no other way to solve the problem. While it may result in tougher deadlines, more work for the remaining team members, and high emotions… it will benefit the team overall.

Concluding Thoughts

I’m no expert. This article is merely the hindsight of a normal team member. Hopefully someone can find this and learn from my experiences. All professions have their versions of “crunch time”, not just the gaming industry. Teams can use all the help they can get.

I don’t wish to alarm you too much but try running the following script on your web server.

With any luck, you’ll see “Wednesday 1 February 2040 00:00″ displayed in your browser. If you’re seeing a date in the late 60’s or early 70’s, your PHP application is probably at risk from the Y2K38 bug!

What is it?

Y2K38, or the Unix Millennium Bug, affects PHP and many other languages and systems, those which use a signed 32-bit integer to represent dates. The furthest date which can be stored is 03:14:07 UTC on 19 January 2038. Beyond that, the left-most bit is set and the integer becomes a negative  number.

So it is 28 years away and I’m sure you think it’s crazy to worry about it now. However, developers thought that way about the Millennium bug in the 1970’s and 80’s.
The worst thing is any web application which handles long-term future events could be at risk. For example, a typical mortgage runs for 25 years. Pensions and savings plans can be far longer, these are all going to be affected unless something is done first. The good thing is that it is very easy to fix.

The Future is 64Bit

The future of all computers is 64Bit, yes and without doubt servers and web applications should be going that way to. If you are a lucky one to already be running under the 64Bit architecture with a 64Bit complied PHP then you are actually fine.
The reason 64Bit works is that a signed 64Bit number gives a maximum future date which is 21 times greater than the current age of the universe, 292 Billion Years.
You can probably sleep well if you know your financial application is going to be running on a 64Bit system.

Changing systems sounds like hard work, is there an alternative?

Yes! Fortunately the smart people at PHP introduced a new DateTime class in version 5.2, DateTime does not suffer from Y2K38 problems and will happily handle dates up to December 31, 9999. I might have paid off my Student Loan or Mortgage or by then!

It may not be worth upgrading existing applications, but you should certainly consider the DateTime class when planning your next project.

(Edit, Variable bug in second script.)

Well this article has been a while in coming. One of the side effects of freelancing is that, sometimes, you have to set aside some of your other projects to let yourself meet client deadlines. Fortunately I have been making progress with this article throughout this time, and I’m finally in a position to dedicate some time to getting this article live.

In case you haven’t been following the series, in Parts 1 & 2 I have been dealing with some of the basic aspects of HTML5, covering the aspects of HTML5 support in Part 1 and discussing the changes that exist between XHTML and HTML5. Today’s article focuses on what I believe to be an interesting topic, how to convert an already existing XHTML Site into an HTML5 design.

Quite some time ago now I asked on Twitter for suggestions about sites that I could use as the basis of this article. David Hatch, the person responsible for the hosting of this very site, suggested another of his sites as the basis of the article. MiniGameReviews is a web site that reviews games in 140 characters or less, rating them on a scale of 0 to 9.

Small Steps – Clean Slate

There are two ways to go about converting a site. You can either work through manually converting the existing code over, or you can recode things from scratch. Whilst it might seem odd to recode something that already exists, it is my experience that it’s generally less problematic in the long term, and can be much easier to develop quickly. It’s also the approach that I will be taking with this article.

Over Time I’ve put together a series of templates that I make use of for helping me develop sites. These templates cover elements of both HTML and CSS. Some aspects of the design are based on the 960 Grid System to help in terms of layout, as well as Eric Meyer’s CSS reset modified to handle the new HTML5 Elements. At this point we have two files, which look like the following:

HTML5 Template

<!DOCTYPE html>
<html>
	<head>
		<meta charset="utf-8" />
		<title></title>
		<!--[if lt IE 9]>
		<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
		<![endif]-->
		<link type="text/css" rel="stylesheet" media="screen" href="style.css" />
		<link rel="shortcut icon" href="" />
		<meta name="description" content="" />
		<meta name="keywords" content="" />
		<!--<meta name='robots' content="noindex,nofollow" />-->
	</head>

	<body>

		<script src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js" type="text/javascript"></script>
		<script type="text/javascript">
			$(function() {

			});
		</script>
	</body>
</html>

This provides for the basic structure of a site’s design. It covers the HTML5 DOCTYPE as well as the majority of the head section of the site, with some added jQuery script capabilities added in just before the end of the site. This is done to ensure a quick loading time for the content of the site, which stands out to me as the most important aspect of any site.

CSS

 /******** GLOBAL RESET ********/
/* http://meyerweb.com/eric/tools/css/reset/ */
/* v1.0 | 20080212 */
html,body,div,span,applet,object,iframe,h1,h2,h3,h4,h5,h6,p,blockquote,pre,a,abbr,acronym,address,big,cite,code,del,dfn,em,font,img,ins,kbd,q,s,samp,small,strike,strong,sub,sup,tt,var,b,u,i,center,dl,dt,dd,ol,ul,li,fieldset,form,label,legend,table,caption,tbody,tfoot,thead,tr,th,td,header,section,footer,aside,nav,article,figure {margin:0;padding:0;border:0;outline:0;font-size:100%;vertical-align:baseline;background:transparent}

body {line-height:1}

header,section,footer,aside,nav,article,figure {display:block}

ol,ul {list-style:none}

blockquote,q {quotes:none}

blockquote:before,blockquote:after,q:before,q:after {content:''}

/* remember to define focus styles! */
:focus {outline:0}

/* remember to highlight inserts somehow! */
ins {text-decoration:none}

del {text-decoration:line-through}

/* tables still need 'cellspacing="0"' in the markup */
table {border-collapse:collapse;border-spacing:0}

/******** 960 GRID ********/

.container_12,.container_16 {margin-left:auto;margin-right:auto;width:960px;overflow:hidden}

.grid_1,.grid_2,.grid_3,.grid_4,.grid_5,.grid_6,.grid_7,.grid_8,.grid_9,.grid_10,.grid_11,.grid_12,.grid_13,.grid_14,.grid_15,.grid_16 {display:inline;float:left;margin-left:10px;margin-right:10px;width:auto}

.container_12 .grid_3,.container_16 .grid_4 {width:220px}

.container_12 .grid_6,.container_16 .grid_8 {width:460px}

.container_12 .grid_9,.container_16 .grid_12 {width:700px}

.container_12 .grid_12,.container_16 .grid_16 {width:940px}

.alpha {margin-left:0}

.omega {margin-right:0}

.container_12 .grid_1 {width:60px}

.container_12 .grid_2 {width:140px}

.container_12 .grid_4 {width:300px}

.container_12 .grid_5 {width:380px}

.container_12 .grid_7 {width:540px}

.container_12 .grid_8 {width:620px}

.container_12 .grid_10 {width:780px}

.container_12 .grid_11 {width:860px}

.container_16 .grid_1 {width:40px}

.container_16 .grid_2 {width:100px}

.container_16 .grid_3 {width:160px}

.container_16 .grid_5 {width:280px}

.container_16 .grid_6 {width:340px}

.container_16 .grid_7 {width:400px}

.container_16 .grid_9 {width:520px}

.container_16 .grid_10 {width:580px}

.container_16 .grid_11 {width:640px}

.container_16 .grid_13 {width:760px}

.container_16 .grid_14 {width:820px}

.container_16 .grid_15 {width:880px}

.container_12 .prefix_3,.container_16 .prefix_4 {padding-left:240px}

.container_12 .prefix_6,.container_16 .prefix_8 {padding-left:480px}

.container_12 .prefix_9,.container_16 .prefix_12 {padding-left:720px}

.container_12 .prefix_1 {padding-left:80px}

.container_12 .prefix_2 {padding-left:160px}

.container_12 .prefix_4 {padding-left:320px}

.container_12 .prefix_5 {padding-left:400px}

.container_12 .prefix_7 {padding-left:560px}

.container_12 .prefix_8 {padding-left:640px}

.container_12 .prefix_10 {padding-left:800px}

.container_12 .prefix_11 {padding-left:880px}

.container_16 .prefix_1 {padding-left:60px}

.container_16 .prefix_2 {padding-left:120px}

.container_16 .prefix_3 {padding-left:180px}

.container_16 .prefix_5 {padding-left:300px}

.container_16 .prefix_6 {padding-left:360px}

.container_16 .prefix_7 {padding-left:420px}

.container_16 .prefix_9 {padding-left:540px}

.container_16 .prefix_10 {padding-left:600px}

.container_16 .prefix_11 {padding-left:660px}

.container_16 .prefix_13 {padding-left:780px}

.container_16 .prefix_14 {padding-left:840px}

.container_16 .prefix_15 {padding-left:900px}

.container_12 .suffix_3,.container_16 .suffix_4 {padding-right:240px}

.container_12 .suffix_6,.container_16 .suffix_8 {padding-right:480px}

.container_12 .suffix_9,.container_16 .suffix_12 {padding-right:720px}

.container_12 .suffix_1 {padding-right:80px}

.container_12 .suffix_2 {padding-right:160px}

.container_12 .suffix_4 {padding-right:320px}

.container_12 .suffix_5 {padding-right:400px}

.container_12 .suffix_7 {padding-right:560px}

.container_12 .suffix_8 {padding-right:640px}

.container_12 .suffix_10 {padding-right:800px}

.container_12 .suffix_11 {padding-right:880px}

.container_16 .suffix_1 {padding-right:60px}

.container_16 .suffix_2 {padding-right:120px}

.container_16 .suffix_3 {padding-right:180px}

.container_16 .suffix_5 {padding-right:300px}

.container_16 .suffix_6 {padding-right:360px}

.container_16 .suffix_7 {padding-right:420px}

.container_16 .suffix_9 {padding-right:540px}

.container_16 .suffix_10 {padding-right:600px}

.container_16 .suffix_11 {padding-right:660px}

.container_16 .suffix_13 {padding-right:780px}

.container_16 .suffix_14 {padding-right:840px}

.container_16 .suffix_15 {padding-right:900px}

At this point there’s no content and a rather excessive amount of CSS code to handle all of it. CSS Frameworks tend to result in a lot of excessive code but this is something to deal with later, by removing any unnecessary code from the CSS after the project is completed.

Why after? Whilst you may think that you know what you want to use in your design, things may change, or evolve, over the course of the design. It’s better to not need something and have it than need something and for it to not be there.

Adding Structure & Content

Now that we have the basic elements of the site in place, we can start to add in some actual structure and content into the design. One of the nice things about making the move from XHTML to HTML5 is that, for the most part, the content of the site can be easily reused, which very little effort required. This is exactly the case with this site, converting a few div elements into headers, sections asides and articles and the vast majority of the HTML layout is complete. At this point, even without styling, you can see the comparisons between the shapes and layout of the site.

From this point, all that remains is the CSS styling to provide the look and feel to the site, making it look like the original design. For the most part this is the same as with the HTML elements of the site, changing a few divs into other elements to ensure they are styling the right elements as well as, in this case, adjusting some numbers to match with the changes I made to the layout, making use elements fit together properly. With that, the process is pretty much complete. The current version of the site is available to be viewed here and the HTML5 version of the site can be found here.

Conclusions

On the whole there’s not a great amount of difference between a site coded using XHTML and a site produced using HTML5. There are a few differences, mainly with the elements used for site structure. Whilst there are other advances made with HTML5, such as audio and video elements, they aren’t used in this particular design.

Google announced some quite amazing technology upgrades yesterday, introducing a new search indexer called “Caffeine”.  Googles Indexer is the way in which they find and organize the entire Internet into the list we are used to seeing on Google.

To everyone that uses Google on a daily basis, and lets face it that IS Everyone, this means the results will be more on topic and apparently up to 50% faster.

There reasoning behind building the whole system behind Google again was down to the web “blossoming” and growing, this means they can now keep on top of things and even search in real time.

“To keep up with the evolution of the web and to meet rising user expectations, we’ve built Caffeine. The image below illustrates how our old indexing system worked compared to Caffeine:”

Google continues to grow in every way and are not only set on their new products and services but are determined to stay the Internet search engine of choice and make things better for everyone.

The scary thing about what Google said is about the amount of data they index and process  each day, “If this were a pile of paper it would grow three miles taller every second” or “You would need 625,000 of the largest iPods to store that much information; if these were stacked end-to-end they would go for more than 40 miles”
So apparently Google have some unused iPods going now, who would like one?..

The Official Release

In my previous article I covered the support the most common browsers have when it comes to HTML5, and how to work around some of the biggest problems you’re likely to encounter with some browsers. Today we’ll be taking a closer look at the actual changes HTML5 will bring to coding websites, and how easy it is to prepare to use HTML5 in your current and upcoming projects.

HTML5 – What’s New?

HTML5 introduces, changes and, in some cases, removes things. It streamlines some old elements and expands into new, more semantic areas. As I mentioned in the last article, there are new elements to help you set up basic areas of the site, such as the header, navigation, sidebars, content articles and footers. But there is a great deal more available. Let’s take a look, shall we?

Back to Basics – DOCTYPE

Some of the following may look familiar to you:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

What’s that? They do? Any web designer who knows anything about coding understands the necessity of having a DOCTYPE declared for a web site. It helps to ensure things work properly in browsers, and lets them know what’s coming up in the code. HTML5 has a DOCTYPE too, though I’m sure this doesn’t shock you in the slightest. But things have changed. Things have improved. Want to see the HTML5 DOCTYPE? Here it is:

<!DOCTYPE html>

Complicated, isn’t it? All it does is tell the browser that it’s viewing an HTML document, and you’re golden.

Letting things go to your <head>

The head section of the site is an important one. It contains a great deal of information about the site, including information about the character set that your site is using. It also contains some important information that is useful for helping identify & display your site, covering things such as your title, your style sheets, favicon and information about the content of the site, in the form of meta tags and descriptions. Some people, though not all, use it as an area to place their JavaScript.

HTML5 helps strip away some elements from this section, and helps streamline others. Below is an example of the code for a pretty standard XHTML Site:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
		<title>Page Title</title>
		<link type="text/css" rel="stylesheet" media="screen" href="site.css" />
		<link rel="shortcut icon" href="" />
		<meta name="description" content="" />
		<meta name="keywords" content="" />
		<meta name='robots' content="noindex,nofollow" />
	</head>

Let’s compare that to how the template for my own site demos looks, just for comparison purposes, shall we?

<!DOCTYPE html>
<html lang="en">
	<head>
		<meta charset="utf-8" />
		<title>Page Title</title>
		<!--[if lt IE 9]>
		<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
		<![endif]-->
		<link type="text/css" rel="stylesheet" media="screen" href="style.css" />
		<link rel="shortcut icon" href="" />
		<meta name="description" content="" />
		<meta name="keywords" content="" />
		<meta name='robots' content="noindex,nofollow" />
	</head>

There’s not a whole lot of difference between the two. The HTML5 declares the language is in and also specifies, in less space, the character set that will be used. The remaining content remains pretty much identical regardless. It should be noted, just for ease of use, I have continued using the self-closing / at the end of elements as was the norm with XHTML. This isn’t required with HTML5, it’s just something I have grown accustomed to over the years.

Wait… I spy JavaScript!

That’s correct, you do. I covered in the last post that Internet Explorer doesn’t currently support HTML5 in any version currently available. The workaround for it consists of some JavaScript which forces these browsers to recognise the elements. Support for HTML5 elements is a part of Internet Explorer 9 but, so far as I am aware, there is no release date set yet. This means that if you hate JavaScript, HTML5 is currently off limits to you.

Most people, however, are all about the <body>

Cheap pun I know, but when it comes to web design it is almost all about the body. Your users don’t see your header. They don’t see your CSS or your JavaScript. What they do see, however, is the body content of your site and the effects of your styling and your JavaScript. So what has changed here?

In the grand scheme of things, not a whole hell of a lot. Everything you used before in creating a web site will work exactly the same in HTML5 as before. It’s part of the beauty of it all. You don’t need to learn anything new, but it adds a great deal of new tools to your set. Let’s take a look, shall we?

Out with the old (and in with the new)

HTML5 doesn’t change the game a whole lot with regards to layout and structure. It merely neatens things up and makes things more consistent. To do this there are several elements removed in the HTML5 specification but, to be honest, I’ve not encountered many of them at all in recent years and none are likely to be missed. The list of removed elements in HTML5 consist of:

• basefont
• big
• center
• font
• s
• strike
• tt
• u
• frame
• frameset
• noframes
• acronym
• applet
• isindex
• dir

Honestly, I’m not going to be missing any of these elements as they have either been irrelevant for quite some time, courtesy of CSS, or superseded by newer technologies. As much as there has been stuff removed, there have also been some new elements added in that you are able to use. Some exist to make laying out your design more semantically, some exist to make your contents easier for search engines to understand and some, such as the video and audio tags, exist to make it easier for you to add multimedia to a page. The main new elements that you should concern yourself with, at this point, are:

• section
• article
• aside
• header
• footer
• nav
• figure
• figcaption
• video
• audio
• time

Whilst there are several others, several of these aren’t currently supported enough to make them usable. I would expect this to change over the coming months. In addition to new elements there are also new attributes for elements. Whilst many of these aren’t supported yet, or are self explanatory, it is possible to make use of some of them to help future-proof your code.

This is especially true with form elements, as unsupported input types default to text inputs when they are unsupported in current browsers. It should be noted that this can cause problems with certain JavaScript Plugins from libraries such as jQuery and Mootools, as these often specify which elements they support.

New Ways to Embed

HTML has always provided way to provide various types of content. Images are as simple as using the img tag. HTML5 looks to expand beyond this introducing methods to embed both audio and video in web pages. This area of the HTML5 spec is currently undergoing some shifts and is a topic I intend to cover at a later date in more depth.

Coming Soon!

I had intended to cover the ins and outs of making the shift to HTML5 in this article. Clearly this hasn’t happened. In writing this article I believed that it was getting to be a bit unwieldy in terms of length and structure, covering too much in one go. As a result I will be covering shifting from XHTML to HTML5 in my next article, paying more attention to the code aspect rather than discussing what has changed.

References

• Anne van Kesteren. 2010. HTML5 differences from HTML4. [ONLINE] Available at: http://www.w3.org/TR/html5-diff/#backwards-compatible. [Accessed 28 May 10].

We have all been developing websites using standard computer fonts or as we know them Web Safe Fonts and all was okay, Everybody was happy with the classics of Verdana, Arial or even push it with Times New Roman, this is a quick insight into new and relatively new services appearing on the internet that help us as designers embed new and exciting fonts into our designs.

Cufon

Then like many others I found Cufon, which is a handy font application that allows you to take your fonts and create a javascript include file to then render your fonts on your web page. They only asked that any Javascript scripts generated from your fonts be a font that is free for use or is one you own.

This is a very useful Web Font generator to use with custom fonts from your collection and there are instances where this is needed.
The only downside that can be seen is the loading of extra JavaScript files, which depending on how many fonts you wish to embed or use, could mean there are several extra files the site needs to load before it is displayed increasing on overhead load.

View

Conclusion
The freedom to use whatever fonts is very nice with Cufon, for my demo I just found a free to use font called Worstveld Sling which I downloaded here http://www.dafont.com/worstveld-sling-ext.font
I found the documentation very helpful in what to do and how to setup my new font.

TypeKit

A system that I have not used very much if at really at all, the reason for this is Typekit is a account based service that starts from a 1 website free account and only allows 25,000 views and 2 fonts to be used, all the way up to a $100.00 account a year that allows 1 million views on unlimited websites and fonts.
This could be a very easy way to get premium Web Fonts on any websites you design, as for now I am very limited in its usage, but have spent some time during the writing of this post creating some demos and using the scripts.

View

Conclusion
I found typekit quite a confusing system to use because of the way that the package manager handled my requests and I could not find definitive instructions on how to integrate typekit into my site beyond being given the scripts and told “use these”.
I struggled with the understanding of selector but after a couple of minutes everything did start working and the result cannot be argued with, the system works well and the fonts do seam to appear in most browsers.
The font I used in my typekit demo was called Scrivano.

@font-face

@font-face would be one of the oldest and most supported Web Font technologies and is even supported by such browsers dating back to Internet Explorer 5.5 days (1999), which was seen as a surprise even back then. This is because the Internet Explorer browser has a bad reputation in what web technologies it supports, such troubles have been seen with PNG images, HTML5 & CSS3 support, which have always arrived a lot later than other browsers, even then the older versions were still about and would ignore these new technologies, rendering websites broken or buggy.
The @font-face team developed a system in which you could select from a large array of fonts free for use and then embed them into your websites Style Sheet then using basic CSS techniques, no extra loading no extra images or rendering, just a font.

Although recently the @font-face team said on a press release that they would be stopping support for hosting their selection of fonts due to the release of the Google Font Directory Service. The @font-face team admits this was a blow to their service but they will return in the near future with some new and exciting features and a new direction.

Since finding the @font-face service and using it for a couple of projects I found myself liking how easy it is to use and include into my web projects. To help with this and to make the use of more fonts i found the @font-squirrel service to be most helpful, you can browse a selection of hundreds of free fonts and then download a package which included the required css and font files, they even give you a font-generator option where you can upload your own font and it will check it and generate all the necessary code so you can just embed the CSS code into your sites and have your custom fond.

View

Conclusion
@font-face would be one of my favorite web font technologies to date and I have used it on several developments, and with @font-squirrel I find the integration of @font-face web fonts to be a very easy task, @font-squirrel has an array of font choices and all it takes is one pick and it downloads the font files to work on all browsers and the CSS code which makes each font work.
A brilliant technology with a top font service.
The font used in this demo was called College http://www.fontsquirrel.com/fonts/College

Google Font Directory

Finally I have come to Google Font Directory web font service, This is the new boy to the field and has only appeared in the last couple of weeks. But being that this is a Google service many people see it as a major improvement upon the existing @font-face service. As all fonts will be hosted by Google with their intelligent scripts if another site has used a font that you use it does not need to be downloaded again because your browser has already learned this font. This is a major benefit to using the Google Font Directory service and is why it seams many people will be turning that way in the near future.

As it sits at the minute the Google Font Directory only consists of 18 fonts with many variants, this is soon to grow and expand and with some simple CSS code just like the @font-face technology Google will begin to produce and provide fonts for your future websites quickly and easily.

View

Conclusion
As this is the first time I have used Google’s Web Fonts, I was amazing surprised as to how easy it actually was to use, Though @font-face is very simple to use and is a widely supported CSS tag, Google WebFonts just makes it much easier, so much so it is easier to use than @font-squirrel. Google only ask you embed their css file and they even give instruction on how to simply @import it to existing stylesheets, then you just call the font in basic a CSS font-family tag just like normal with @font-face
The font I used for this demo was Tangerine and is available from the web fonts directory.

Overall

I have posted these 4 popular web font services available on the internet and i’m sure they are all in very wide usage worldwide, and even though some were trickier to use than others don’t just take my word for it try them for yourselves.

I did not notice any speed differences between these technologies but I am led to believe that Cufon and Typekit change the fonts after or even during the page load and you can see the font change however the @font-face technology does not seam to, this due to the fact the browser it loading the font in alongside the website structure thus the custom font appears right away.

Note
These are the top services I have used or even just considered using, I am sure there are many other Web Font services or technologies out there, so don’t take offense that I may have left your favorite out, instead leave a comment and I will continue my research into web fonts.

360 #NinjaGaiden2 Get too slash limbs off other Ninjas,learn new skills. The boss fight,everything you learnt before is useless.Too HARD. 2

This article is one of a series that I plan on covering, regarding HTML5. Over the series I plan to take a look at various aspects of HTML5, be it browser support, how you can start working with it now or how to get HTML5 Video working across browsers, with support for those who don’t yet support these tags.

Browser Support – Here & Now

Today, as the title suggests, I’ll be dealing with the support offered by the most common browsers, and what we can do for those browsers that don’t support HTML5 currently. The browsers that I’ll be covering are:

• Firefox
• Safari
• Chrome
• Opera
• Internet Explorer 6
• Internet Explorer 7
• Internet Explorer 8

Whilst IE6 isn’t a modern browser and many designers/developers have an intense dislike for it, including myself, it is an unfortunate reality that it is still a common browser and thus it is a browser that we need to keep in mind when developing using HTML5.

Firefox, Chrome, Safari & Opera

I have bundled these four browsers together as, from my own experience, the current versions of these browsers support the important parts of HTML5 pretty consistently. These include the new semantic tags used for laying out elements: header, nav, section, article, aside, figure and footer. They do, however, typically need to be pointed in the right direction when it comes to styling them. Fortunately this is a simple task, completed by adding the following CSS into your stylesheet.

header,
section,
footer,
aside,
nav,
article,
figure {
	display:block;
}

This code will ensure that all elements that should be displayed as block by default are displayed as block when pages load. This will almost certainly be a default in future versions of browsers.

Older Browsers

Older browsers, as well as browsers that are rarely updated, really are the problem children when any new standard is released, as they cannot be developed to support features that have yet to be created. It’s quite understandable but I thought I’d go into a little detail about what the result of this is.

As pointed out already, the current versions of these browsers all support, to some extent, HTML5. The problem with older browsers is that they don’t see, or register, HTML5 elements. This can cause problems when using elements such as header, section or pretty much any of the elements I have mentioned so far, as they make up an important part of sites developed using HTML5.

This causes a really tragic breakage, for lack of a better work, of the design of a site. Without the styling of such features a design can, and quite possibly would, fall apart. Fortunately these browsers are very good in terms of updating their software, ensuring that such incidents are very much the exception than the norm.

Internet Explorers 6, 7 & 8

Internet Explorer has a mixed reputation, as the browser has become increasingly good, or less bad, over the past several years and, with Internet Explorer 9, will become even better, with full HTML5 support. That, however, is the future. I’m discussing the here and now in terms of support for HTML5.

I’ll keep it brief for you, there isn’t any. Currently Internet Explorer does not support HTML5 in any way, shape or form. Fortunately, there’s a way to force Internet Explorer to acknowledge the existence of HTML5 elements, which has both upsides and downsides.

That’s right, the solution for Internet Explorer’s lack of HTML5 support is dependant upon JavaScript. How does JavaScript help? JavaScript has a rather nice command, document.createElement(), which when used in the <head> section of the site forces the browser to acknowledge that the element created can be styled. An example of how this can be done would be:

document.createElement('article');
document.createElement('footer');
document.createElement('header');
document.createElement('hgroup');
document.createElement('nav');

The code above would force Internet Explorer to acknowledge the existence of the 5 elements mentioned. Personally I would recommend that you look into making use of Remy Sharp’s fantastic HTML5 Enabling Script, which is also available on Google Code, which spares you from having to manually create each element.

An alternative that you could make use of Modernizr, which is useful for much more than making HTML5 work for Internet Explorer, having the capability to detect what features a browser supports using JavaScript.

Anyway, that’s it for today’s post. My next HTML5 post will look at how you can start using HTML5 now, covering what has changed and will cover a guide on making the switch from XHTML/HTML4 to HTML5.

PC #GuildWars Over 7579 hrs playtime.Wonderful setting,graphics,sound & interesting skills. It really should be played before #GuildWars2 9