Facebook launched an HTML5 Showcase for developers today and I was excited to see that two projects that Mozilla has
worked on in the past 9 months were featured: Mozilla’s Mark Up and Mozilla’s Web O Wonder.
HTML 5 coupled with CSS is emerging as the new hot development language. I am delighted to announce that we have created six complete lessons that cover the most interesting and dynamic new features of HTML 5 that are ready to drop into a web development or intro programming course. Each lesson comes with instructor PowerPoint slides, a complete reading assignment with hands-on examples, including the files and assets to use in each assignment. A single lesson has enough content for a 75-100 minute class session, and the hands-on examples are great for either a lab session or homework assignment.
The six lessons are:
Lesson 1 – Defining HTML 5
Lesson 2 – Fundamentals of HTML 5, XHTML, and CSS
Lesson 3 – Introduction to CSS Layout
Lesson 4 – Using HTML 5 Markup
Lesson 5 – Working with Canvas
Lesson 6 – HTML 5 Multi-Media and Drag and Drop
This content is available to faculty (and students/hobbyist/pros) at no charge and can be downloaded from here: http://www.mis-laboratory.com/faculty/
With these lessons it is easy to update your curriculum (or resume) with the latest technology. Not faculty or a student? These lessons are a great way to self-study and get up to speed on the latest development language.
by Eric Rowell HTML5 Canvas Planets Image Map
Demo here: http://www.html5samples.com/Files/planets.html
<script src="http://www.html5samples.com/Files/kinetic2d-v1.0.4.js">
</script>
<script>
window.onload = function(){
var kin = new Kinetic_2d("myCanvas");
var canvas = kin.getCanvas();
var context = kin.getContext();
var showImageMap = false;
var displayText = "";
context.fillStyle = "red";
context.font = "20pt Calibri";
var planets = {
Mecury: {
x: 46,
y: 126,
radius: 32
},
Venus: {
x: 179,
y: 126,
radius: 79
},
Earth: {
x: 366,
y: 127,
radius: 85
},
Mars: {
x: 515,
y: 127,
radius: 45
}
};
var imageObj = new Image();
imageObj.onload = function(){
kin.setDrawStage(function(){
// draw planets
context.drawImage(imageObj, 0, 0, canvas.width, canvas.height);
for (var key in planets) {
var planet = planets[key];
this.beginRegion();
context.beginPath();
context.arc(planet.x, planet.y, planet.radius, 0, Math.PI * 2, false);
this.addRegionEventListener("mouseover", function(){
displayText = key;
});
this.addRegionEventListener("mouseout", function(){
displayText = "";
});
if (showImageMap) {
context.fill();
}
context.closePath();
this.closeRegion();
}
// draw display text
context.save();
context.fillStyle = "white";
context.fillText(displayText, 10, 30);
context.restore();
});
var checkbox = document.getElementById("checkbox");
checkbox.addEventListener("click", function(){
showImageMap = !showImageMap;
kin.drawStage();
}, false);
};
imageObj.src = "planets.png";
};
</script>
There is many new features in in HTML 5 and one of them is being able to drag a file from File explorer (Windows or any OS) into the web browser and handling the drop event via script (Javascript in this case). If you’re a Google Mail user you are likely familiar with this feature as Google lets users to attach files to emails using Drag and Drop.
Of course as always not every browser supports the new feature. There are approx. 90% of web browsers support Drag and Drop, including Internet Explorer 7 and above, Firefox 4 and above, Chrome etc but it is strange that Internet Explorer 9 does support Drag & Drop but not with files.
The HTML 5 page I am using is quite simple:
<html> <head> <title> HTML 5 Drag & Drop demo</title> <link href="style.css" rel="stylesheet" type="text/css" /> <script src="/Scripts/modernizr-2.0.6-development-only.js" type="text/javascript"> </script> </head> <body> <div id='dropTarget' style='height: 100px; width: 100%; background-color: Lime; text-align: center'> Drop files here</div> <ul id='images'> </ul> <script src="Scripts/jquery-1.6.4.js" type="text/javascript"> </script> <script> </script> </body> </html>
Note that I used a <div> with an Identification of dropTarget to drop the files from explorer and there is an <ul> with Identification images where the result will be displayed. Moreoever I used jQuery but the jQueryUI droppable function doesn’t support dragging and dropping files from the explorer at this moment.
I used addEventListener() to add 2 handle event drag over and drop.
$(function () {
if (Modernizr.draganddrop) {
var dropTarget = $(‘#dropTarget’)[0];dropTarget.addEventListener(‘dragover’, function (e) {
e.preventDefault();
});dropTarget.addEventListener(‘drop’, function (e) {
e.preventDefault();if (e.dataTransfer.files === undefined) {
// IE doesn’t support file drops yet.
$(‘#dropTarget’).text(‘Drag & Drop of files is not supported’);
return;
}$.each(e.dataTransfer.files, function () {
var file = this; 2
$(‘<li>’).text(file.name).appendTo(‘#images’);
});
});
}
else {
$(‘#dropTarget’).text(‘Drag & Drop is not supported’);
}
});
The dragover event is real simple, all we need to do is prevent the browser from doing it’s default behavior.
The drop event is more interesting. First of all we need to check the passed argument to see if the is a files array on the dataTransfer object. In the case of Internet Explorer 9 this is not the case. Next we can use the $.each() function as a convenient way of handling the file drops. In this
case all I am doing is showing the file name in the list.
Once upon a time, audio on the web lived primarily in the world of third-party browser plug-ins like Flash, QuickTime and Silverlight. This was not a bad world, but it had its issues.
For one, most plug-ins require the user to install them, but not all users are willing (or able) to install them. Also, many players built with these plug-ins are inaccessible, making it difficult for folks who use assistive technologies to access the audio or alternative content.
Then there are the front-end design hassles like trying to get a dropdown menu to display on top of a plug-in-based player. And let’s not forget that to build a custom player with these plug-ins requires knowledge and expertise in that SDK.
Today, we have another option: HTML5 <audio>. This new element allows you to deliver audio files directly through the browser, without the need for any plug-ins. It works much like the tried-and-true <img> element, embedding the audio file into a web page via the src attribute:
Not only does native audio deliver independence from plug-ins, it can be targeted with CSS and JavaScript. This means that creating a custom player is simply a matter of writing HTML, CSS and JS. It also means more front-end control for responsive, dynamic designs and potentially better accessibility.
As far as browser support goes, <audio> enjoys support by all of today’s latest browsers, including mobile browsers for iOS 4+, Android 2.3+ and Opera Mobile 11+.
Sound good? Then let’s get started adding embedded audio in our web pages!
To add a simple audio player to your web page, all you need is a single line of markup:
This includes the src attribute I already discussed, which embeds the specified audio file into the page. It also includes the controls attribute, which tells the browser to use its default control interface for audio.
As you can see in Figure 2, each browser has a different default for player controls but all include the basics: play/pause toggle, timeline progress bar and volume control.
Beyond src and controls, <audio> has several other attributes you can utilize to further modify how your audio file will load and play.
The Boolean autoplay attribute is one that I don’t recommend using because it specifies that the audio begin playing as soon as the page loads. This is a usability no-no for most scenarios, so exercise restraint in using this attribute.
If you do decide to utilize autoplay, please be sure to include the controls attribute (or roll your own custom controls) so that your users can stop the audio or reduce volume.
crossorigin is used to indicate if an audio file is being served from a different domain. This is a very new attribute introduced for all media elements (<video> and <img> too) to address playback issues with Cross-Origin Resource Sharing (CORS).
Depending on the scenario, crossorigin can be declared with an empty string or with CORS settings attribute keywords: user-credentials or anonymous.
Another Boolean attribute, loop, tells the browser to loop the audio when playing. Like autoplay, I’m not a particular fan of this attribute because it takes control away from the user. But if you must use it, I recommend including the controls attribute alongside loop.
mediagroup is another relatively new attribute that is used to tie together multiple media files for synchronized playback. Each media element with the same keyword value for mediagroup is, essentially, linked and can be manipulated for playback via the DOM.
This attribute is valid for all media elements, so it is possible to link audio to audio, as well as audio to video and video to video.
The Boolean attribute muted does just what it says: mutes the audio file upon initial play. The user can then override this if volume controls are provided.
The preload attribute suggests how the browser should buffer the audio, according to the specified value:
preload="auto" (same as the Boolean preload in the example) leaves it up to the browser to decide whether to begin downloading.preload="metadata" tells the browser to download information like tracks and duration, but to wait to buffer the audio until the user selects play.preload="none" tells the browser that no audio information should be downloaded until the user activates the controls.Make note that not all browsers support all of these attributes and that the specification itself is still changing. That means you have to experiment, test and stay up-to-date on the spec.
As I already mentioned, <audio> is well supported by modern browsers. But what about users who aren’t on modern browsers? Depending on your audience, there could be a fair percentage of your users who can’t access your audio content. For those users, <audio> offers fallback content, which is contained within the opening and closing <audio> tags:
For browsers that don’t support <audio>, this fallback content is what displays to the user, while browsers that do support native audio ignore the fallback and display the player.
In this example, I chose to include some explanatory text and a link to download the audio file for my fallback content. But you can pretty much include any content you want to serve to those users, including HTML.
HTML5 <audio> makes it (arguably) easier for an average front-end developer like me to add audio to web pages. And it opens up a world of possibilities for better media accessibility as the specification evolves.
Unfortunately, like the world of plug-ins, native audio has its issues too.
To keep audio content for the web at reasonable sizes for streaming and download, audio data is compressed/decompressed using codecs. Different codecs transform the audio into different formats that offer good quality with minimum bitrates.
So far, there is no single standard for audio codecs in the HTML5 specification. This means that some browsers support some formats, while other browsers support others:
Fortunately, <audio> is set up to handle multiple file formats:
As you can see in this example, to declare multiple audio files, you first drop the src attribute from <audio>. Next, you nest child <source> elements inside <audio>, each of which specifies a different file format via the src attribute.
A browser will read the first-listed <source> and, if it supports the specified file format, the audio player will render on the page. If the browser doesn’t, it moves on to the next <source> element.
In the event the browser doesn’t find a <source> file format it can support, it will fail and playback won’t be possible:
But this is where you can take advantage of fallback content, which must be nested within <audio> and after all <source> elements:
In this example, a browser will first check if it supports <audio>. If it doesn’t, it goes straight to the fallback content.
If it does support <audio>, it next checks for support of file formats, starting with the first <source> and proceeding until it reaches a supported format. In the event no listed formats are supported, the fallback content displays.
In terms of which file formats to include, it isn’t necessary to have all formats listed in Figure 3. Including just MP3 and OGG will cover all your bases for modern browsers supporting HTML5 <audio>.
Regarding source order, it technically doesn’t matter which audio file format is listed first. That said, I usually include my OGG <source> first. It is the higher-quality file, compared to MP3, and I want browsers that support both to get the OGG first. Also, there was a bug in older versions of Firefox where if the first <source> format was MP3 it failed, so listing OGG first can avoid triggering this bug.
In addition to specifying multiple audio formats, it is also good practice to specify MIME types for each audio file:
By specifying a MIME type for each audio format, it helps the browser know what type of content it will be dealing with. This can speed up <audio> rendering because the browser won’t have to download the files to determine content type.
Also, some browsers won’t play audio without the correct MIME type. For example, Safari 5.1 (at least as of this writing) will fail to play any audio if the first-listed <source> is an unsupported format like OGG without a specified MIME type.
During my experiments with <audio> I encountered one of the more frustrating aspects of delivering native media: server support for MIME types. Though you can specify the MIME type for each audio format directly in your markup as seen in the example above, this doesn’t guarantee that your web server supports those MIME types.
And if your server doesn’t support a given format, you won’t have playback … something I discovered (not quickly enough) when an <audio> implementation that worked on my local system failed on the live web server.
I’m am the furthest thing from a expert on server configurations, but I have found success circumventing these MIME type issues by updating my sites’ .htaccess files to reference the correct file types. And the HTML5 Boilerplate.htaccess file is a fantastic template to start with.
HTML5 is still new to so many developers. So maybe you aren’t quite ready to take the leap headfirst into <audio>? Or perhaps you have concerns about your users on browsers without <audio> support?
I completely understand wanting the best possible experience for all your users, regardless of their browsers. Fortunately, you can ease into HTML5 <audio> and gracefully degrade the experience for users on older browsers.
As I mentioned, <audio> fallback content can include HTML. And that means it can include a Flash <object> for browsers that don’t support <audio>:
In this example, the browser will first check if it supports <audio>. If it doesn’t, it will fallback to the Flash audio player (provided the plug-in is installed).
If the browser does support <audio>, it will proceed through the <source> elements until it finds a supported format. In the event no supported format is listed, the browser will fallback to the Flash player (again, if the plug-in is installed).
Now, what if Flash isn’t supported? That’s when you use the fallback’s fallback:
Simply nest your Flash fallback content within the <object> and after all <param>s. Browsers that don’t support HTML5 audio or Flash will fallback to this content, in this case some explanatory text and a link to download the audio.
Another way you can transition to HTML5 audio is to use a pre-built player. Many players today give you options to choose different skins for the player and even skin on your own via CSS. Additionally, several HTML5 media players are already built with Flash fallback content. Here are a few to check out:
To say this is the tip of the iceberg when it comes to native audio is an understatement. This article focuses on the core markup and syntax for embedding audio into your web pages. But the true power of native audio is the ability to target it using JS and CSS.
You can make your own custom player. You can visualize audio. You can generate audio on the fly. And these are just some of the early experiments.
As you experiment further with <audio>, please check out these resources:
<video> now!Much of what this article discusses for HTML5 <audio> applies equally to <video>. As media elements, they share many of the same attributes and follow a similar syntax. <video> is also subject to many of the same issues as <audio> — specifically multiple file formats and MIME types — and benefits from the same solutions.
Anyone hoping to pronounce Flash dead as Adobe transitions to the brave new HTML 5 world will have been disappointed, based on the company’s MAX Conference last week.
That said, there is evidence of a partial transition towards HTML. The big story in this respect is Adobe’s acquisition of Nitobi, creators of the PhoneGap tool for building mobile applications from HTML and JavaScript. Nitobi chief executive Andre Charland gave a brief demonstration of PhoneGap on stage at MAX.
Adobe also talked up Edge, its tool for creating HTML 5 animations which is now in its third preview, and showed CSS Regions and CSS Shaders, two projects it has worked on in the form of contributions to the open source Webkit HTML engine, and in the case of CSS Shaders a submission to the W3C.
CSS Shaders is influenced by the work Adobe did on Pixel Bender for Flash, and enables CSS Filter Effects to be extended with shaders that process the 3D geometry and the colour of pixels.
At a MAX session, Adobe also showed how Flash Professional, its designer-oriented authoring tool for Flash, is becoming an authoring tool for
HTML as well. Subject to limitations, you will be able to publish a Flash Professional project to HTML and JavaScript, with partial conversion of
ActionScript to JavaScript, in the next major Flash Professional release.
Is Adobe then retreating from Flash? Not so fast. Certainly there was more HTML content at MAX than in previous years, and these sessions were among the most popular, but if you look in detail at the session list, you will find that Flash predominates. The biggest splashes at the day two keynote were Flash-related.
The Flash content at MAX was dominated by a trio of new technologies delivered in Flash Player 11 and AIR 3. AIR (Adobe Integrated Runtime) creates a means to run desktop and mobile apps that use Flash as a runtime engine.
The first is Stage 3D, formerly known as Project Molehill, a 3D hardware-accelerated API for Flash. An implementation for mobile is expected early next year. Coding for Stage 3D is a specialist task – as with other 3D libraries such as Open GL – but the results are impressive. In the MAX
day two keynote Epic Games announced that its Unreal Engine for game developers is coming to Flash. “We chose as our demo a fully playable level from Unreal Tournament 3 and it turned out to look even better than the version we shipped on Xbox 360 and PlayStation 3, with improvements like global illumination, better shadows, and god rays!” said Epic vice president Mark Rein.
A related project is the open-source Starling Framework, which uses Stage 3D for accelerated 2D graphics and is easier to use.
The second key new feature is the Captive Runtime for AIR. This lets you bundle the Flash player into a native executable, in a similar manner to the packager Adobe created for iOS to overcome Apple’s Flash ban. The late Steve Jobs may have done Adobe a favour. Despite the inherent inefficiency of shipping each app with its own player, the captive runtime makes AIR more attractive to developers, since from the user’s perspective it removes the Flash dependency. Captive Runtime support is in AIR 3 and works for all supported desktop and mobile platforms except iOS, which still has the packager. Currently the iOS packager is apparently better optimised, but this will change in future updates.
The third feature of the trio is that native extensions are now available for AIR, making the runtime truly extensible for the first time. Adobe’s implementation makes these challenging to write, but easy to consume, since they are packaged as libraries, which from the Flash end look similar to a .SWC, a standard Flash and ActionScript library. ActionScript is the Flash programming language, a kind of forked version of JavaScript.
Native extensions have an .ANE extension. Internally, a native extension has an ActionScript interface, plus one or more implementations for different platforms. Each implementation is also written in ActionScript, but can also make use of an ExtensionContext class to access native code. The native libraries themselves are typically written in C or C++, or Java in an Android library, though other languages are possible and one of Adobe’s examples calls Microsoft .NET. They are not sandboxed. The main limitations are that they cannot re-implement ActionScript classes, and placing native user interface controls on the Flash surface is not supported.
There are several areas where native extensions will prove useful. These are making use of otherwise inaccessible device features, reusing legacy code or existing libraries, and improving the performance of critical code. Since they are easy to distribute and have developer-friendly ActionScript APIs, we can expect to see a proliferation of native extensions some of which will be widely adopted. Taken together, these three technologies make AIR more interesting than before, particularly as a cross-platform mobile toolkit. It is significant that the six new tablet apps, including Photoshop Touch, that were previewed by Adobe at MAX are built with Adobe AIR but delivered using the captive runtime, and
make heavy use of native extensions.
MAX attendees also heard about new features coming to future versions of Flash. Among the most significant is concurrent programming for ActionScript. This will look similar to JavaScript’s web workers, and while it will not give developers complete freedom to use multiple threads, it will be relatively safe and easy to code.
What about PhoneGap then, which is also a cross-platform toolkit for mobile? A good question, and one that Adobe will only answer in vague terms. “If you are building a rich game, use Flash. If you are building data-driven applications that are fundamentally pulling source from an end service into an application you can use HTML 5 and PhoneGap to get on those devices,” Adobe’s senior vice president David Wadhwani told me. Note, though, that he said “can use” to allow for the fact that mobile AIR also covers that second scenario, though currently on a smaller range of devices.
Adobe is hedging its bets, and the fact that it remains the Flash company may make it an uncomfortable home for Nitobi employees
with their commitment to HTML and JavaScript rather than proprietary runtimes. Charland is aware of that tension, though he remarks in a blog post: “If you doubt Adobe’s intentions, it’s important to consider how Adobe makes money – it’s from tools, services and solutions, not shipping runtimes.
“Flash also remains important for web developers who need a consistent cross-browser platform for rich applications. Some came to MAX anxious for reassurance that Flash will not be abandoned. “It would be like returning to the browser wars,” one developer told me.
That reassurance was evident at MAX. Flash is not dead, though it is becoming a specialist resource rather than something to stick on web pages to spice them up. Thank goodness
http://www.theregister.co.uk/2011/10/13/flash_not_dead_for_adobe/ By Tim Anderson
Check out these HTML 5 Forms products:
Instant Form Pro – The Best Form Creation Software For Marketers
Create questionnaires, surveys, contact forms, job applications, testimonial generators, database entry forms and more in seconds Installs in minutes and can be used on unlimited sites. Embed in WordPress blogs or any html page. Affiliates earn 50
Instant Form Pro – The Best Form Creation Software For Marketers
A tutorial on Html 5 and CSS 3. I go over some of the new functions for html5, embedding audio and video and also using form validation with html5. I also go over New features for css covering border radius and drop shadow using only css. If it helps you out at all subscribe to my blog: ryanconn.com
Video Rating: 5 / 5