Some thing quick, simple and fun this time. A drop down menu, built solely with HTML and CSS, that is functional back to IE7, and animated for browsers that support CSS3 transitions. See the end-product, here. Let’s get going…
First, the HTML structure.
<menu id="mainmenu">
<ul>
<li>
<a href="#">Main 1</a>
<ul>
<li><a href="#">Sub Menu 1-1</a></li>
<li><a href="#">Sub Menu 1-2this a long one goes for a while</a></li>
<li><a href="#">Sub Menu 1-3</a></li>
</ul>
</li>
<li>
<a href="#">Main 2</a>
<ul>
<li><a href="#">Sub Menu 2-1</a></li>
<li><a href="#">Sub Menu 2-2</a></li>
<li><a href="#">Sub Menu 2-3</a></li>
<li><a href="#">Sub Menu 2-4</a></li>
<li><a href="#">Sub Menu 2-5</a></li>
<li><a href="#">Sub Menu 2-6</a></li>
<li><a href="#">Sub Menu 2-7</a></li>
</ul>
</li>
<li>
<a href="#">Main 3 this one goes for a while and does not wrap</a>
<ul>
<li><a href="#">Sub Menu 3-1</a></li>
<li><a href="#">Sub Menu 3-2</a></li>
<li><a href="#">Sub Menu 3-3</a></li>
<li><a href="#">Sub Menu 3-4</a></li>
</ul>
</li>
<li>
<a href="#">Main 4</a>
<ul>
<li><a href="#">Sub Menu 4-1</a></li>
<li><a href="#">Sub Menu 4-2</a></li>
<li><a href="#">Sub Menu 4-3</a></li>
<li><a href="#">Sub Menu 4-4</a></li>
</ul>
</li>
</ul>
</menu>
A menu tag to provide semantic context, with a top-level unordered list to provide structure for the top level of the menu, and nested unordered lists to provide structure for the drop-down (or sub) menus.
Now, let’s do the layout with some basic CSS.
menu ul {
padding: 0;
margin: 0;
list-style-type: none;
}
#mainmenu {
width: 55em;
}
#mainmenu > ul > li {
float: left;
width: 25%;
}
#mainmenu a {
display: block;
padding: 0.5em;
background-color: black;
text-decoration: none;
color: white;
font-family: arial;
text-overflow: ellipsis;
overflow: hidden;
white-space: nowrap;
}
Here we eliminate the default margins and padding, and bullets, for the unordered lists that make up our menu. Then we float the list items for the top level menu to the left. We also set a width for the menu, and divide this width equally (25%) among the four sub-menus. At this point we should have the items lining up correctly, with top level items going from left to right, and their corresponding sub-menu items rendering beneath.
We’re also going to do our aesthetic styling on the hyperlinks, as this will allow for the link/visited/hover/active behavior to take up the entire space of the list items in he menu. To do so, simply specify the hyperlink (“a”) elements to be display blocks, and set any padding/margin on them. We also set the default background color, font face and text color here, as well as setting the text-overflow to ellipsis in case the text is longer than our width.
We can now hide the sub-menus and get ourselves into our default state simply by adding this CSS:
#mainmenu > ul > li > ul {
height: 0;
overflow: hidden;
}
We just set the height of our sub-menus (he nested unordered lists) to 0, and hide any overflow so it’s not visible. (We could use “display:none” here and also have it function, but this won’t work in conjunction with the animated effect we will add shortly).
So, to get our menu functional so the corresponding sub-menu displays when you hover over a main menu item, it’s simply a matter of setting the height to it’s appropriate height:
#top > ul > li:hover > ul {
height: auto;
}
#mainmenu > ul > li:hover a {
background-color: dimgray;
}
#mainmenu ul li a:hover {
background-color: gray;
}
We also set the background color to change to indicate the hover over menu item and sub-menu item states. At this point we have a fully functional drop down menu that works on browsers back to IE7. And with no JavaScript!
Finally, we can animate the “dropping down” of the menu with a simple CSS3 transition. We are going to do this on the “max-height” property of the nested unordered lists by setting them to have a max-height in the hover state that is greater than any possible height for our sub-menus. In the default/non-hover state it will have a max-height of 0. And we’ll set a transition for the max-height property to create the animated effect:
#mainmenu > ul > li > ul {
height: 0;
overflow: hidden;
max-height: 0; /*start state of animation/transition*/
transition: max-height 0.5s ease-in;
}
#mainmenu > ul > li:hover > ul {
height: auto;
max-height: 10em; /*end state of animation/transition*/
}
So the question may come up as to why we didn’t simply apply the transition to the sub-menus’ height attribute. The quick answer is it doesn’t work, at least not if we set the height to “auto”. Even if it were to work, and you may be able to get it to work if you set the heights of the menu items to a specific value, it may still not provide the ideal behavior. By animating to the same “max-height” for each sub-menu, you ensure they sub-menus move at the same speed regardless of height differences.
And why not remove height altogether since we’re relying on max-height for the animation? Just a matter of preference for how the menu works when you mouse off the main menu item. If we remove height, then you also see the menu animating to a closed/hidden state, which to me looks awkward, especially when another sub-menu is animating open at the same time. Try it, and you may see what I mean.
And that’s it, an animated drop down menu with no JavaScript. What I haven’t done is test this on mobile devices, though for that we may want to restructure the menu with a media query. A possible future addendum for this article.
I have done numerous courses online, from college courses with proctored exams, to continuing education online (e.g., ed2go), to the free Aquent Gymnasium courses (which are very well done), to courses I paid for that were not so good. I generally find that online courses provide a convenient means of receiving instruction, while enforcing a structured approach to your learning, if they are done well.
So I was quite pleased to take on the opportunity to review the Packt Publishing video course HTML5 Game Development by Makzan. Though I have developed a Windows 8 game with HTML5, I don’t consider myself a game developer and I very much looked forward to finding out what I could learn from this course. (As a disclaimer, I received the course for free from Packt in return for this review).
The course, which as of this writing can be downloaded for $33.99 from the Packt website, comes in the form of an archive that contains two more zip files. The first zip file contains the video files–40 in total which make up 8 lessons of 5 sections each–as well as a brief user guide (9 pages, pdf format) which explains the contents of the course and how to navigate it, a briefer pdf (1 page) that explains how to provide feedback to Packt, and some web pages that allow you to browse the course. The second zip file contains the source code in the state it should be after each video (i.e., 40 folders of source code).
Course Navigation
Lesson Navigation
Course Overview
With other courses I’ve taken, I’ve found those courses that deal with a specific technology are less likely to become dated quickly than those that deal with a number of technologies and have dependencies on others, such as browsers. This course would fall into the latter.
And of course it goes without saying you get out of a course what you put into it. It takes effort, and a good course will motivate you to make that effort.
So, to start, let’s deal with some of the up front claims in the marketing literature, and set realistic expectations. If you read the Packt download page or the course overview that comes with the course, you will see the claim “Build two HTML5 games in two hours with these fast-paced beginner-friendly videos.” The 40 videos themselves have a total running time of two hours, so it is more accurate to say you can watch someone explain how they built two games over two hours. I coded along with the course and I found that each of the 8 individual sections easily took me over two hours a piece to complete, and depending on issues I came across, it could be twice that or longer. The five individual videos that make up each section tended to be in the 2 to 3 minute range each (with a few over 4 minutes and some under 2 minutes), which are nice little chunks to work on at any one time. The Packt website does provide a sample video (Section 5, Video 4) that is a fair representation of what you can expect from the videos that make up the course:
And in terms of “beginner-friendly” I suppose it depends on what you are a “beginner” of. If you read further on in the overview it states “Some basic knowledge of HTML, JavaScript, and CSS would be useful.” Personally, I think you probably need more than some basic knowledge of these technologies to get something substantive from the course, or else I suspect you’d be just copying quite a bit of code without any real understanding as to what is going on. At a minimum, I would recommend you have a good understanding of CSS specificity, the box model and positioning; as well as an understanding of the JavaScript module pattern and prototypal inheritance. Understanding how to use your browser’s dev tools–especially the debugger and console–will also prove extremely helpful in debugging the inevitable typos and errors you introduce into your code. And at one point I even had to use the profiling tools to determine the origin of a memory leak, but hopefully you’ll be spared that. So, I would say, if you have solid web dev skills and are a “beginner” to HTML5 game development, then you could find this course “friendly.”
In terms of HTML5 game development, the focus of this course is developing games on the canvas element using the EaselJS library. In the video, the IDE you see being used is Sublime Text 2, and the browser is Safari on a Mac. If you want to keep things simple and run into as few problems as possible, then I recommend you use Safari and version 0.5.0 of EaselJS (you can find this in the source code folders that come with the course).
If you are more adventurous, like I was, then you may want to download the latest version of EaselJS (0.7.1 at the time of this writing) and use the browser of your choice, which I suspect would be Chrome for many of you. Now be forewarned, some of the EaselJS code written in the videos no longer works with the latest version of EaselJS. So if you are adventurous, make the EaselJS documentation your friend. Also, I came across some cases where code that works in Safari has some slightly different results, or in one case doesn’t work, in other browsers. More on that later.
To deal with issues like these, one thing I’ve seen useful for students in the ed2go and Aquent Gymnasium courses are discussion areas focused on each lesson, where students help one another work their way through the inevitable pain points. If Packt were to provide such discussion boards I believe they may find it enhances the learning experience for their customers.
The course, itself, teaches by example by showing the development of a couple games: in the first three sections you develop a simple card game where you win by clicking randomly placed cards in numbered order, and in sections four through eight you develop a more adventurous 1980’s arcade-style game in which you jump from platform to platform collecting coins while avoiding rotating saws. Any guesses as to which one is cooler?
You are not provided any additional exercises, reading material, quizzes, or exams to reinforce your learning.
Basically, it’s like learning with pair programming, except your partner won’t respond to any questions. And she does a lot of pasting of code chunks. (Where did she copy those from? We never do find out). Though you can make her repeat her statements at will via rewind, and pause the video to take the time to read those pasted code chunks.
You can see the two games I built with my paired video partner here and here. If you want to be motivated, focus a bit more on the second game, which I admit was a cool experience to build.
So yes, I did manage to successfully build the games taught in the course in spite of all I noted I ran into. And please don’t get me wrong, I did get a lot out of this course. I feel it was worth my while and I’m pleased with what I got out of the effort I put into the course. Though, and I repeat, you will have to put effort into the course to get a lot out of it.
What do I feel good about that I learned?
the pre-loading graphics pattern shown
the structure taught for modeling objects for a game
collisions and gravity were introduced
how running and a “camera” that follows the runner is implemented was cool to learn
what’s involved in building sprite sheets for animations
building a progress bar for pre-loading the games resources
There are also many topics just briefly touched on that the course did not go into a lot of depth. For example, getting your first game ready for mobile only really involved quickly coding the meta viewport tag, which is fine if this is all you find you have to do to make your game mobile ready (sorry to say not all mobile devices are going to have the same aspect ratio). At least you have a starting place from which to investigate more.
Later on in the course we are shown how to create sprite sheets from a Flash animation (swf) by utilizing the Zoë tool. Unfortunately, the course does not include the swf files, so we cannot try creating the sprite sheets, ourselves.
Some gotchas I’ll also warn you about, in case you do decide to do the course, so you have less to work through than I did (this is beyond the differences between EaselJS o.5.0 and 0.7.1):
in section two, one line of code sets the “innerText” of an element. Of course, this doesn’t work in Firefox. You’ll be fine if you stick with “innerHTML”.
in section 3, the call to createjs.Bitmap() will result in a same origin security issue if you are developing with Chrome and not hosting your work on a web server. I got around this by restarting Chrome with that protection disabled.
I also found in section 3 with Chrome, Firefox and IE I could not get the background images for the tiles to display reliably when then the game first loads. They would appear when I clicked on the first tile, though the issue went away once I put the game on a web server (except for mobile IE, where I still see it).
again in section 3, I downloaded a font from the exact same location done in the video. And tried to convert it into a web font on fontsquirrel, as was done in the video. And fontsquirrel complained the font file was corrupted. I ended up finding a similar font, elsewhere on the web, that fontsquirrel didn’t complain about.
in section 4, video 3, there is a line of code that is needed that is not shown in the video for method updateView(). If you go to the code for the course, you’ll find it (or you can probably figure it out with the debugger, as I did).
also, in section 4, when the code is shown in the video for building the platform, you will see that p.GameObject_initialize is not called in the definition of p.initialize (see below screen shot). Do this and you’re in for an ugly surprise come section 6. In section 6, the game code is written to loop back to the beginning once your player dies. After a few loops you will notice the game starting to get sluggish. This is even more pronouncedwithEaselJS version 0.5.0 than with the versionofEaselJS I used. I did a quick heap allocation profile and saw the allocation of objects increasing over time with noticeable jumps when the game restarted. Memory leak! It took a bit of investigation for me to nail down just what was causing this. (I’ll save what I did during that investigation for the subject matter of another blog post).
Do you see p.GameObject_initialize() being called in p.initialize()?
Beyond that, there are a number of differences between the current version of EaselJS and the version used in this course. I’d be happy to share my notes on these differences with anyone interested in those.
So, how should I summarize all this? I would say if you are someone who has solid knowledge/experience with web technologies, especially JavaScript and CSS, and little experience developing games for the canvas element, and you are willing to put in some effort, you will get your money’s worth from this course. You won’t pick this stuff up in a couple hours, short of having mastered osmosis. If you have basic JavaScript and CSS abilities, my suspicions are you will pick up some knowledge, but for a lot of the stuff you code you won’t really understand what is going on, and you may get very frustrated if you miss a line of code or make a typo and your debugging skills are not up to snuff. Or even if you do pinpoint the origin of the error, will you understand the issue? Or, I suppose if you are really motivated, you could learn how to use the dev tools, and dig into these technologies, in parallel with the course. Obviously some extra effort, but you got to learn that stuff at some point.
As for the issues I ran into, well, I can assure you that you will run into these issues in other courses that involve multiple interdependent technologies that are changing rapidly. That is where things like discussions boards and folks helping one another out come in handy, and would make a fine compliment for Packt to offer with their courses.
My current place of employment is growing quite rapidly, and as such is doing quite a bit of hiring. This means I, and others, end up doing quite a bit of interviewing. One of the questions one of my coworkers asks in interviews involves how analog clocks work. A few months back, I was thinking about this while doing some reading about CSS3, and naturally the thought of building an analog clock with CSS3 came to mind.
I say naturally as it has evidently come to mind for quite a few people as a useful academic exercise to flex their CSS3 muscles on. A quick Google search for “css3 analog clock” comes back with a hearty handful of such renderings. One in particular I like is “CSS3 Analogue Clock without using Images” by Matt Walker, as it renders the clock face solely with HTML5 and CSS3; ie, he uses no images. It takes an approach similar to how I did, using common digits rather than Roman numerals, and rotating them appropriately with CSS3 transforms. I particularly like how Matt went beyond the simple clock face and built up the entire clock body with CSS. Pretty cool stuff!
Aesthetically speaking, my clock is not nearly so fancy. One of the challenges I did present to myself when building this clock, however, was to make it responsive. That is, to use relative measures and have it (re)size itself appropriately to the width of the viewport. What I’d like to discuss here is the technique I used to make it responsive. If you want to test its responsiveness, resize your browser. Or if using a mobile device, rotate it. The other thing I did differently was utilize requestAnimationFrame to have the second-hand scroll smoothly, as opposed to doing one second ticks/jumps. I won’t get into that, here (but do feel free to check out the code).
Basically, responsive design involves building an HTML UI utilizing relative CSS measures and appropriate breakpoints, usually defined with media queries, to make the UI resize elements, show/hide elements, and basically structure itself appropriately based on the width of the viewport. But I’m assuming you’re aware of all that. If not, Ethan Marcotte’s seminal article on Responsive Web Design can provide you with more details on how it generally works. (If you check it out, be sure to resize your browser while at the start of the article and watch what happens to the lead image). Or if you want the nitty-gritty details on responsive design, including handling images and tables, Aquent Gymnasium offers an outstanding free course on the topic.
If you try resizing your browser to a width under 480px you should see the size of the clock shrink in a responsive manner relative to the width of the viewport. You should also notice it has a maximum width of about 480px when increasing the width of the viewport.
There’s nothing radical with how I implemented it. Every HTML element that makes up the clock has its size defined in ems, such that the size of the child elements are relative to the size of their parent elements up to the one top level div. I can then reset the size of the clock by simply setting a single CSS property on the top level div–the font-size–and this changes the size of each child element proportionately. Some code may make this clearer.
Our top level element is #clock, with four immediate children nested whose purposes are self evident. I think we can simply focus on #clock and #center to come to understand the technique used.
In the CSS, I set the base font size for the body to 16px (which is generally the default you would get, anyway), and then define the CSS for our elements sizing them using em as our measurement.
For #clock, the CSS makes our div round with a diameter of 30em (by setting border-radius to 50%, and the width and height to 30em). It is important to note that #clock inherits the font-size of 16px from the body, as this means 1em for #clock is, by default, 16px. As far as the ems for the child elements, we only care that em is a relative measure to em for #clock. For instance, #center represents the dot at the center of the clock face. We give #center a diameter of 2em, so we can center it by positioning its “upper left corner” relative to #clock‘s “upper left corner”14em from the left and 14em from the top.
So what we have at this point is a circle with a diameter of 480px (30em x 16px) that has a black dot in its middle whose diameter is 32px (2em x 16px). If we make our viewport width less than 480px at this point, our circle and dot sizes don’t change correspondingly.
So let’s say we tried setting the font-size for #clock to 10px. What we should find is the diameter of our circle is now 300px (30em x 10px), and the dot now has a diameter of 20px (2em x 10px), and is still centered in our circle. Since #clock is our top level element, by setting font-size to 10px, we have defined the size of an em to 10px for all elements that make up the clock (so long as we don’t specify the font-size of any child elements to a physical measure). And note that since we defined how we positioned our dot (#center) in ems as well, it remains in the center when we change the font-size of #center. So changing the size of our clock is as simple as changing the font-size of our top-level element for the clock.
At this point, it should be becoming apparent how we’ll make the clock responsive. The most obvious way would be to define a media query for a viewport width of 480px and greater that sets the font-size of #clock to 16px, and define other breakpoints at lower viewport widths (less than the width) with correspondingly lower font-sizes for #clock. And that should work, though you’ll only have the width (diameter) of the clock maximized when the viewport width matches exactly our media queries.
Alternatively, I took an approach of resetting the font-size of #clock with a handler for the window resize event:
function setSize() {
var b = $("html, body"),
w = b.width(),
x = Math.floor(w / 30) - 1,
px = (x > 15 ? 16 : x) + "px";
$("#clock").css({"font-size": px });
}
$(document).ready(function () {
setSize();
$(window).on("resize", setSize);
});
So now when we resize the browser window to below 480px, we see the size of our clock resizing proportionately for all widths, much like you’d see an image responsively resize when you set the max-width of it.
Now you may be thinking I’ve only demonstrated resizing a circle and a dot proportionately. Well, the technique demonstrated here will work for all elements that make up the clock so long as you are sure to size and position them with ems. (Setting the rotation angle with CSS transforms does not need to change as the angles involved don’t change as the size does). But given that, If you are interested in seeing how I got my analog clock fully built and functioning, the un-minified CSS and JavaScript are here and here.
So there you have it: a technique you can use to build a responsive analog clock with CSS and JavaScript. Comments? Thoughts? Love? Rage? Please share.
front-end fu 