HTML5 Example

Mid of 2010 fellow StateOfSearch blogger Louis Venter had first look at the new and upcoming HTML 5 mark-up. Keep in mind that HTML 5 is not ready yet and it’s still a work in progress – officials say we’ll see it finalized by end of 2012 – but I’m pretty sure it’s more going to be 2013 or so. But that’s not the main thing I want to look at. I just thought it might be nice to point out some of the changes that can have an impact in regards to on-page SEO and how developers (and SEOs) currently do use existing elements and tags.

I found it to be extremely interesting, having a technical background, in which direction the usage of HTML 5 is heading. Even though, and I probably should have put this in my summary, I don’t think its ground breaking – but it does make a lot of sense.

New link-level attributes

As we’re in SEO, let’s have a look at links first: One change that caught my attention is some newly introduced relation attributes for hyperlinks. Similar to the widely known rel=”nofollow” there are some new ones like rel=”author” as well as rel=”license” put into the HTML 5 specification. The goal is being able to further describe link relations (in this case: who is the author or under what license has the content been published?). This is probably not going to change the way links are and have been working, however it won’t hurt to provide that extra info.

Table layouts vs. div containers vs. HTML5

In the very beginning of the WWW a lot of sites we’re using <table>’s to structure their websites (and some still do…). That decreased over time and especially with XHTML coming in, developers moved over and started using various <div> containers and organized those using CSS positions – which makes a lot of sense (you can keep content in order, don’t have the overhead of tables, etc.). Looking at “modern” websites a very classical approach is having a markup similar to this one:

With HTML 5 coming in we now do have tags to especially “mark” these different sections:

Image credentials: A List Apart: HTML 5

So the general approach is having the possibility to really describe parts and sections of a website using a pre-defined tag versus using <div>’s all over the place. This will – hopefully – result in a better understanding of the mark-up when search engines (but also screen readers and similar) access a website.

Updated usage of images

As of now, when it comes down to using images, SEOs heavily rely on using the appropriate alt-attribute to make images “understandable” (and maybe rank) in search engines. This would currently look like this:

Looking at a similar usage in HTML 5 it would eventually look like this:

So the <img>-tag changes from being a short-tag to really having a tag value; interesting stuff. In combination with the updated image tag there’s another element being introduced: <figure> – which can be used to create sub-titles and taglines, nice. And another addition / change in using images is the possibility to include them almost everywhere you want. For example within a paragraph <p> or a container <div>, this might look like this:

Changes in using headline tags

Combining the newly introduced <section> element all together with headline tags as well as with one or more paragraph’s it is now possible to bundle different areas (aka sections) and provide those with a dedicated headline. From HTML 5 on you don’t have to worry about the amount of <h1> tags because it’s seems perfectly valid to have more than one <h1>.

Updated and improved handling of media elements

If you’re not using YouTube to handle your videos you might have noticed that embedding self-hosted videos is a painful thing to do. This is going to be changed in HTML 5 – and same goes for audio. The specifications will introduce dedicated tags named <video> and <audio> to ease that. They’re not fully supported by browsers and search engines like Google, yet – but it’s worth playing around with it.

And the result?

The main thing that HTML 5 brings in is the ability to really use structured elements and therefore provide the possibility to classify contents depending on the tags “surrounding” them. That being said, if you do use those tags correctly, search engines have the chance to weight parts of a website differently by making use of HTML mark-up only.

And there is even more (a element for notifications, updated usage for tags like <em> or <strong>, etc.) so I strongly recommend you keep your eyes open for further stuff to come. And if (smaller) projects do provide the possibility to let you test parts of HTML 5, go for it.

Author: Bastian Grimm

Bastian Grimm (@basgr) is founder and CEO of Grimm Digital. He mainly works as online marketing consultant with a strong focus on organic search engine optimization (SEO). Grimm specializes in SEO strategy consulting, website assessments as well as large scale link building campaigns.
Source: http://www.stateofsearch.com

HTML5 Tags html5 seo,

James Forshaw

Summary

WebGL is a new web standard for browsers which aims to bring 3D graphics to any page on the internet. It has recently been enabled by default in Firefox 4 and Google Chrome, and can be turned on in the latest builds of Safari. Context has an ongoing interest in researching new areas affecting the security landscape, especially when it could have a significant impact on our clients. We found that:

1. A number of serious security issues have been identified with the specification and implementations of WebGL.
2. These issues can allow an attacker to provide malicious code via a web browser which allows attacks on the GPU and graphics drivers. These attacks on the GPU via WebGL can render the entire machine unusable.
3. Additionally, there are other dangers with WebGL that put users’ data, privacy and security at risk.
4. These issues are inherent to the WebGL specification and would require significant architectural changes in order to remediate in the platform design. Fundamentally, WebGL now allows full (Turing Complete) programs from the internet to reach the graphics driver and graphics hardware which operate in what is supposed to be the most protected part of the computer (Kernel Mode).
5. Browsers that enable WebGL by default put their users at risk to these issues.

WebGL

Throughout the history of the Web there has been a drive to allow greater interactivity and expressiveness in web content. Starting with the initial forays into scripting, extensive plugin capability and ActiveX through support for HTML5 functionality such as the video or canvas tags, more and more complexity has been provided in the browser by default.

At each stage in the evolution of the modern browser existing security tenets have had to be re-evaluated to ensure new functionality does not open up any serious attack vectors. As an example, before scripting was introduced there was no easy mechanism for a malicious page to gain access to another site’s content; therefore there would be no need for implementing a same-origin policy. Security decisions made during the early days of the browser may no longer be appropriate to modern advancements, especially ones regarding this cross-domain access of content.

While the theft of data is a serious issue the integrity of the browser and the host operating environment should also not be forgotten when introducing new technology. Sometimes the benefits may prove to be more of a curse. As an example take binary browser-plugin support (e.g. ActiveX or the Netscape Plugin Application Programming Interface). The support makes it very easy for third parties to extend the functionality of the browser and provide callable interfaces for web pages. This in turn opens the attack surface of the browser to potentially a larger corpus of code, some of which is almost certainly badly written. It might then become difficult for a browser vendor to secure the platform, as it might not even be their code which is an issue, leading to such band-aids as IE’s Killbits and Firefox’s plugin checker to block or inform the user an update might be necessary. In the end the only secure way to use such wide ranging native content is probably not to have it in the first place, but the general consensus at the moment is the benefits outweigh the security risk.

This leads to the topic of this blog post, WebGL. If it is something you have yet to hear of you almost certainly will soon. WebGL’s goal is to introduce an OpenGL derived 3D API to the browser, accessible through JavaScript from any Web page which wants to use it. The recently released Mozilla Firefox 4 browser has enabled support by default, as has Google’s Chrome browser since version 9 and Safari (WebKit) 5.

This in itself should not really be controversial, however the way in which it is implemented, coupled with the way current PC and Graphics Processor architectures are designed has led some to question the security of the approach. Context has performed some initial investigations into possible security concerns which seem to be inherent in the specification, leading to questions as to whether it should be currently available on supporting platforms, and if its benefits actually outweigh its risks.

Quick Overview of 3D Graphics Pipeline

First let’s start with a very simplified overview of how 3D graphics is implemented in most modern PC style architectures.

Figure 1 - Simple Diagram of Graphics Pipeline

At the lowest level is the Graphics Processor (GPU) hardware itself, this does not necessarily implement any specific API (almost certainly it is a proprietary interface developed by the manufacturer), however it should at least support all the functionality expected at the programming API level. Almost all modern 3D hardware contains individual programmable units (usually referred to as shaders), these can be individually programmed by the user-mode processes. The native format of the shader code is generally specific to the hardware vendor; however common languages exist to permit cross platform code to be developed.

Above the hardware is a driver which tends to run within kernel mode on the operating system; its job is to handle the low-level hardware aspects and to provide a standardised interface (e.g. WDDM) through which other components of the operating system can access the GPU.

Next is the scheduling, this could be implemented in a number of different locations, for example in the kernel driver itself, by the OS or entirely in user mode. Its responsibility is to share access to the GPU between individual programs running on the same machine. In a more traditional environment this would not be necessary because only one application (for example a windowing manager) would actually need direct access to the GPU at any one time. In a 3D scenario the requirement to directly access the shaders and memory to upload texture and geometry means this must be managed appropriately.

The final piece in the stack is the interface library, which is the main route through which user processes access the graphics library. This is the final level of abstraction, removing where possible any hardware specific functionality. Common interface libraries are Direct3D (which also has some kernel functionality) and the cross-platform OpenGL. They provide APIs to create the 3D geometry to be displayed, compilers to convert shader programs into a more suitable representation for the GPU and manage the allocation and uploading of texture information to video card memory.

The Trouble with WebGL

Based on the simplified description it is possible to go into what is currently the issue with the way WebGL is specified, designed and implemented. Traditional browser content would not normally have direct access to the hardware in any form, if you drew a bitmap it would be handled by some code in the browser with responsibility for drawing bitmaps. This would then be likely to delegate that responsibility to an OS component, which would perform the drawing itself. While this distinction is blurring somewhat with the introduction of 2D graphics acceleration in all the popular browsers it is still the case that the actual functionality of the GPU is not directly exposed to a web page. The salient facts are that the content is pretty easy to verify, has a measurable render time relative to the content, and generally contains little programmable functionality (at least which would be exposed to the graphics hardware).

WebGL on the other hand provides, by virtue of its functional requirements, access to the graphics hardware. Shader code, while not written in the native language of the GPU, are compiled, uploaded then executed on the graphics hardware. Render times for medium to complex geometry can be difficult to determine ahead of time from the raw data as it is hard to generate an accurate value without first rendering it; a classic chicken and egg issue. Also some data can be hard to verify and security restrictions can be difficult to enforce once out of the control of the WebGL implementation.

This might not be such an issue, except for the fact that the current hardware and graphics pipeline implementations are not designed to be pre-emptable or maintain security boundaries. Once a display list has been placed on the GPU by the scheduler it can be difficult to stop it, at least without causing obvious, system-wide visual corruption and instabilities. By carefully crafting content it is possible to seriously impact the OS’s ability to draw the user interface, or worse. The difficultly in verifying all content and maintain security boundaries also have potential impact on the integrity of the system and user data.

Up to now the manufacturers of graphics hardware haven’t really needed to worry about an un-trusted use case for their products. Certainly the issues of integrity and denial of service would be considerations even for native programs, but the developers will generally have a vested interest in making sure that their programs do not cause problems. A malicious actor would need to convince someone to install their bad code, at which point attacking the graphics hardware might be the least of the user’s worries. Graphics drivers are generally not written with security as their main focus, performance is likely to be most critical. Security costs a significant amount in both man-hours and monetary terms, there seems to be little incentive for the manufacturers to harden their products (potentially at the expense of performance) to support the WebGL in its current form.

Even if security issues are identified it is unclear what the patch strategy employed by the large GPU manufacturers would be. Searching Security Focus for either ATI or NVIDIA only produces a few publically disclosed vulnerabilities (dating back to 2008); a Google search for related security bulletins also does not bring up any information. Considering the complexity of the drivers and hardware interactions it seems hard to believe that there has never been an exploitable bug in their software which needed immediate remediation.

Of course the patching situation might not be helped by the typical restrictions on OEM products, especially laptops. Typically in these situations the reference driver provided by the GPU manufacturer is blocked from installing on a laptop, making any security update considerably more difficult to deploy.

During the development of WebGL it seems that all the browser vendors supporting it have encountered issues with certain drivers being unstable or crashing completely. The current work around for this seems to be a driver black list (or in Chrome’s case not running WebGL on Windows XP at all). (See https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers). This does not seem to be a very tenable approach long term.

Denial of Service

The risk of denial of service is one of the most well known security issues facing WebGL, not least because it is even documented in the current standards documentation (see https://www.khronos.org/registry/webgl/specs/1.0/#4.4). Basically because of the almost direct access the WebGL API has to the graphics hardware it is possible to create shader programs or a set of complex 3D geometry which can cause the hardware to spend a significant proportion of its time rendering. It is easy to trivialise client denial of service attacks when the only affected component is the browser process (there are numerous ways of doing this already), however in this case the attack can completely prevent a user being able to access their computer, making it considerably more serious.

In certain circumstances Context has observed the operating system crashing (i.e. Blue Screen of Death). These crashes can be benign (from an exploitability sense) to ones where the driver code has faulted causing potentially exploitable conditions. No further details of actual exploitable vulnerabilities or the code used to generate them is to be disclosed at this time.

Windows 7 and Vista seem to fair slightly better in this regard, if the GPU locks up for around 2 seconds the OS will force it to be reset. This stops all applications from using any 3D graphics during this period of reset. However these OSes also have a maximum limit to how many times this can happen in a short time window before the kernel will force a bug check (Blue Screen of Death) anyway (see http://msdn.microsoft.com/en-us/windows/hardware/gg487368.aspx).

Of course as it is a known issue there are efforts to mitigate it, for example the ANGLE project (http://code.google.com/p/angleproject/) includes a shader validator to eliminate simple infinite loop cases, which is used in Firefox 4 and Chrome. This validation cannot possibly block all cases leading to denial of service, especially when you can create large geometry and shaders which don’t contain loops but still take substantial amounts of time to execute.

At this point it would seem to be reasonable to provide a proof of concept; however Context did not need to even write one as Khronos provides one in their WebGL SDK. See https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/extra/lots-of-polys-example.html. This page has been found to completely lock the desktop on OSX, reliably crash XP machines and cause GPU resets on Windows 7.

Cross-Domain Image Theft

One of the fundamental security boundaries in the specification of the Document Object Model and browser handling of JavaScript is the domain boundary. This is to prevent content served from say, www.evil.com being able to access authenticated/trusted resources on www.mybanking.com. Whether content is permitted to be accessed across this boundary very much depends on the type of resource being accessed. This is sometimes referred to as “Right to Embed” vs. “Right to Read”. For example it is perfectly acceptable to embed an image from outside of your domain because the underlying APIs never gave you a mechanism to read the actual content (outside of image dimensions, and an indication of success or failure to load). On the other hand trying to use the XMLHttpRequest object to pull content from outside your domain (and therefore giving you access to the raw data) is generally not permitted.

Before the introduction of the ‘Canvas’ element, which is being standardised in HTML5 there were not many options for stealing the raw data of images cross domain. To combat this, an ‘origin-clean’ flag was implemented. This flag is initially set to true and is set to false if any cross domain image or content is used on the canvas (see http://www.w3.org/TR/html5/the-canvas-element.html#security-with-canvas-elements). Once the ‘origin-clean’ flag is false you can no longer call the APIs such as ‘toDataURL’ to extract the image content.

The WebGL API is built on top of the ‘Canvas’ element and so extends the concept of the flag to also encompass the use of cross-domain textures (see https://www.khronos.org/registry/webgl/specs/1.0/#4.2). This would be the end of it except for one slight issue. As already discussed with regards to denial or service it is possible to cause shading code and geometry drawing to take a non-trivial amount of time. One of the resources which a shader can directly access is the pixel data of textures, which once it reaches the shading code it no longer has any concept of origin. Therefore it is possible to develop a timing attack to extract pixel values even if we cannot read them directly. This can be done by changing how long a shader runs depending on the colour or brightness of a pixel and measuring the time the drawing process takes in JavaScript. This is a standard attack technique in the security field although it is most often used for breaking cryptographic systems. In relation to WebGL it has already been mentioned in a public mailing list that this could be an issue (see http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-March/030882.html).

Of course an attacker might not even need to extract the entire pixel data of the image for this to be of use. For example it could be used to compare a cross-domain image to another known image, returning a simple true or false value. As an example imagine a web site which returns a profile picture on a fixed URL, the content determined by the session cookie stored in the browser. An attacker might be able to compare this cross-domain image against a known list of profile pictures to identify when specific a specific person is using the malicious site.

Therefore as part of our investigations into WebGL a proof-of-concept has been developed to demonstrate the attack is practical (if a little slow). To access the PoC go here. It has been tested in Firefox 4 and Chrome 11, on Windows XP, Windows 7 and Mac OSX. It works best in Firefox. It should be noted that Context do not hold any of the data captured on the page, everything is done on the client. For those without a WebGL capable machine or browser there is also a short video here.

Figure 2 - Flow Diagram Showing Stages of Image Capture

This is something which we believe can only be fixed by changing the nature of cross-domain image access in the specification of WebGL. The could be achievable via blocking all cross-domain images or using something like CORS (http://www.w3.org/TR/cors/) to only permit specific image content to be accessed from certain domains.

Conclusions

Based on this limited research Context does not believe WebGL is really ready for mass usage, therefore Context recommends that users and corporate IT managers consider disabling WebGL in their web browsers.

While there is certainly a demand for high-performance 3D content to be made available over the web, the way in which WebGL has been specified insufficiently takes into account the infrastructure required to support it securely. This is evident from the development of ways to mitigate the underlying security issues by introducing validation layers and driver black-lists; however this still pushes much of the responsibility of securing WebGL on the hardware manufacturers. Perhaps the best approach would be to design a specification for 3D graphics from the ground up with these issues in mind.

Source : http://www.contextis.com

HTML5 Tags WebGL Browser Exploitation, James Forshaw, html5 security, WebGL security problem,

Each brush actually is for one corner, so just flip them in Your brush properties ( F5 to bring up brush options panel).

There are more than 400+ brushes out here, so I think You have a little list now to choose from!

  
       Download       |         Download         |       Download
  
        Download        |        Download        |       Download
  
        Download        |       Download         |        Download
  
       Download         |        Download        |         Download
  
        Download        |        Download        |        Download
  
        Download        |       Download          |       Download
  
        Download        |        Download        |       Download
  
        Download        |       Download          |      Download
  
        Download       |         Download        |        Download
  
        Download        |        Download        |        Download
  
        Download        |       Download         |         Download

Feel free to suggest your corner and border brush set in the comments below!

Source: http://www.1stwebdesigner.com

HTML5 Tags corner borders, Border Corner Brush Sets,

The CSS3 border-radius property allows web developers to easily utilise rounder corners in their design elements, without the need for corner images or the use of multiple div tags, and is perhaps one of the most talked about aspects of CSS3.

Since first being announced in 2005 the boder-radius property has come to enjoy widespread browser support (although with some discrepancies) and, with relative ease of use, web developers have been quick to make the most of this emerging technology.

Here’s a basic example:

This box should have a rounded corners for Firefox, Safari/Chrome, Opera and IE9.

The code for this example is, in theory, quite simple:

#example1 {
border-radius: 15px;
}

However, for the moment, you’ll also need to use the -moz- prefix to support Firefox (see the browser support section of this article for further details):

#example1 {
-moz-border-radius: 15px;
border-radius: 15px;
}

How it Works

Rounder corners can be created independently using the four individual border-*-radius properties (border-bottom-left-radius, border-top-left-radius, etc.) or for all four corners simultaneously using the border-radius shorthand property.

We will firstly deal with the syntax for the individual border-*-radius properties before looking at how the border-radius shorthand property works.

border-bottom-left-radius, border-bottom-right-radius, border-top-left-radius, border-top-right-radius

The border-*-radius properties can each accept either one or two values, expressed as a length or a percentage (percentages refer to the corresponding dimensions of the border box).

The Syntax:

border-*-*-radius: [ <length> | <%> ] [ <length> | <%> ]?

Examples:

border-top-left-radius: 10px 5px;
border-bottom-right-radius: 10% 5%;
border-top-right-radius: 10px;

Where two values are supplied these are used to define, in order, the horizontal and vertical radii of a quarter ellipse, which in turn determines the curvature of the corner of the outer border edge.

Where only one value is supplied, this is used to define both the horizontal and vertical radii equally.

The following diagram gives a few examples of how corners might appear given differing radii:

If either value is zero, the corner will be square, not round.

border-radius

The border-radius shorthand property can be used to define all four corners simultaneously. The property accepts either one or two sets of values, each consisting of one to four lengths or percentages.

The Syntax:

[ <length> | <percentage> ]{1,4} [ / [ <length> | <percentage> ]{1,4} ]?

Examples:

border-radius: 5px 10px 5px 10px / 10px 5px 10px 5px;
border-radius: 5px;
border-radius: 5px 10px / 10px;

The first set of (1-4) values define the horizontal radii for all four corners. An optional second set of values, preceded by a ‘/’, define the vertical radii for all four corners. If only one set of values are supplied, these are used to determine both the vertical and horizontal equally.

For each set of values the following applies:

If all four values are supplied, these represent the top-left, top-right, bottom-right and bottom-left radii respectively. If bottom-left is omitted it is the same as top-right, if bottom-right is omitted it is the same as top-left, and if only one value is supplied it is used to set all four radii equally.

Browser Support

At present Opera (version 10.5 onward), Safari (version 5 onward) and Chrome (version 5 onward) all support the individual border-*-radius properties and the border-radius shorthand property as natively defined in the current W3C Specification (although there are still outstanding bugs on issues such as border style transitions, using percentages for lengths, etc.).

Mozilla Firefox (version 1.0 onward) supports border-radius with the -moz- prefix, although there are some discrepancies between the Mozilla implementation and the current W3C specification (see below).

Update:Recent Firefox nightly versions support border-radius without the -moz- prefix.

Safari and Chrome (and other webkit based browsers) have supported border-radius with the -webkit- prefix since version 3 (no longer needed from version 5 onward), although again with some discrepancies from the current specification (see this article for further details of how older versions of Webkit handle border-radius).

Even Microsoft have promised, and demonstrated in their recent preview release, support for border-radius from Internet Explorer 9 onward (without prefix).

The -moz- prefix

Mozilla’s Firefox browser has supported the border-radius property, with the -moz- prefix, since version 1.0. However, it is only since version 3.5 that the browser has allowed elliptical corners, i.e. accepting two values per corner to determine the horizontal and verical radii independently. Prior to version 3.5, the browser only accepted one value per corner, resulting in corners with equal horizontal and vertical radii.

The syntax, from Firefox 3.5 onwards, for the main part follows the current W3C specification, as described throughout this article, prefixed by -moz-. The only major difference is in the naming of the individual border-*-radius properties, with the -moz- prefixed properties following a slightly different naming convention as follows:

W3C Specification	Mozilla Implementation
border-radius	-moz-border-radius
border-top-left-radius	-moz-border-radius-topleft
border-top-right-radius	-moz-border-radius-topright
border-bottom-right-radius	-moz-border-radius-bottomright
border-bottom-left-radius	-moz-border-radius-bottomleft

The Mozilla implementation also behaves slightly differently from the specification when percentages are supplied. You can read more on the Mozilla Developer Center here.

Cross Browser Examples

Here’s a few basic examples that should work in current versions of Firefox, Safari/Chrome, Opera and even IE9:

A B C D E F

#Example_A {
height: 65px;
width:160px;
-moz-border-radius-bottomright: 50px;
border-bottom-right-radius: 50px;
}

#Example_B {
height: 65px;
width:160px;
-moz-border-radius-bottomright: 50px 25px;
border-bottom-right-radius: 50px 25px;
}

#Example_C {
height: 65px;
width:160px;
-moz-border-radius-bottomright: 25px 50px;
border-bottom-right-radius: 25px 50px;
}

#Example_D {
height: 5em;
width: 12em;
-moz-border-radius: 1em 4em 1em 4em;
border-radius: 1em 4em 1em 4em;
}

#Example_E {
height: 65px;
width:160px;
-moz-border-radius: 25px 10px / 10px 25px;
border-radius: 25px 10px / 10px 25px;
}

#Example_F {
height: 70px;
width: 70px;
-moz-border-radius: 35px;
border-radius: 35px;
}

Additional Notes & Further Reading

The W3C Backgrounds and Borders Specification goes into further detail on how the corner is shaped (especially in circumstances where two adjoining border have different widths), the effect of border-radius on background images, color and style transitions, what happens when curves overlap and the effect of border-radius on tables.

This is best explained in the following sections of the specification:

• 4.4.1 Corner Shaping
• 4.4.2 Corner Clipping
• 4.4.3 Color and Style Transitions
• 4.4.4 Overlapping Curves
• 4.4.5 Effect on Tables

  HTML5 Tags corner borders,

Unwaivering

Unwaivering by Ippa, is a short story about true love – and is one of the first canvas based games which uses a game as art.

Use the right cursor to fight the wind up the mountain. Unwaivering uses the JawsJS canvas library.as

Play Unwaivering

Biolab Disaster

Biolab Disaster is a platform shooter built by Dominic Szablewski using his forthcoming ImpactJS engine.

Comments from the Author:

Biolab Disaster formulates the playable truth that it makes sense to create games for HTML5. Not only is the result on par with current Flash games, but also is the development process incredibly smooth and satisfying.

Play Biolab Disaster

Manic Spaceman

Shaw Young has created this impressive retro update of Manic Miner called Manic Spaceman. The game was created for a competition with his friends over who could create the best Manic Miner update within 8 weeks. Shaw created his entry using canvas.

As with all the retro classics, the game chucks you in at the deep end of the difficulty scale. Use the cursors to move left and right and the space bar to jump!

Play Manic Spaceman

Fred Jones in Adventureland

PurpleFloyd has recreated a platform game he originally built 15 years ago, updating it so it runs in web browsers using canvas and JavaScript. You play as Fred Jones as he makes his way through Adventureland and in to space.

Comments from the Author:

Nearly 15 years ago, when I was all of 15 years old, I wrote this little platform game which I have recently ported to Javascript/HTML5. It is a kind of Mario clone and at the time I named it “Fred Jones in Adventureland”… hmm, not a great name.

The platformer has 5 levels with a couple of different enemy variations, and obstacles such as falling platforms and plays smoothly throughout on the usual canvas supported browsers (the game supports Internet Explorer but runs slowly).

Play game

Another World JS

Gil Megidish has a bit of an obsession with Another World, the famous platform puzzle game from 1991 also known as Out of this World in North America.

Over the years, he’s ported the game to PSP, PS2, GBA and PC.. and now he’s ported it over to canvas!

There are a few graphical glitches within the game due to the nature of the port, but the version is playable with patience and a great example of what canvas can do!

For those of you who are stuck from the start, you’ll need to swing the cage to escape and find a gun to stand a chance of survival! If you’re looking for further guidance, there are many walkthroughs available. Start at Part 2.

Check out the Another World canvas game Play Another World JS

Berts Breakdown

Bert’s Breakdown, created by Paul Brunt, is a beautiful looking platform game where you have to go around the level collecting Euro coins while avoiding deadly spiders. While some of the coins are straightforward to collect on your route through the level, others can be found hidden in the clouds; and some require to use mushrooms as springs to reach higher areas.

This was Paul’s first venture using the HTML 5 canvas element, and although he had a few minor issues, he found that he could build what he needed “surprisingly quickly”. Paul claims, “the whole game, graphics and all, only took about 100 hours” – it sounds a lot, but when you check out the quality of the game, you can see where that time has been spent.

Works best in Chrome; and supports the Chrome Frame plug in for Internet Explorer.

To play the game, use the cursor keys to move left and right; and the space bar to jump.

Play Berts Breakdown

HTML5 Tags html5 game examples, canvas platform games,