GETTING STARTED WITH THE HTML5 TRACK ELEMENT

The track element provides a simple, standardized way to add subtitles, captions, screen reader descriptions and chapters to video and audio.

Tracks can also be used for other kinds of timed metadata. The source data for each track element is a text file made up of a list of timed cues, and cues can include data in formats such as JSON or CSV. This is extremely powerful, enabling deep linking and media navigation via text search, for example, or DOM manipulation and other behaviour synchronised with media playback.

The track element is currently available in Internet Explorer 10 and Chrome 18+. Firefox support is not yet implemented. In Chrome, track element support must be enabled from the chrome://flags page.

http://www.html5rocks.com/en/tutorials/track/basics/

When can I use...

Compatibility tables for support of HTML5, CSS3, SVG and more in desktop and mobile browsers.

http://caniuse.com/

normalize.css

Normalize.css is a small CSS file that provides better cross-browser consistency in the default styling of HTML elements. It’s a modern, HTML5-ready, alternative to the traditional CSS reset.

• Normalize.css project site
• Normalize.css source on Github
• Normalize.css documentation
• Normalize.css demo

Normalize.css is currently used in some form by HTML5 Boilerplate, Twitter Bootstrap, GOV.UK, Tinker.io, CSS Tricks, and many other frameworks, toolkits, and sites.

Overview

Normalize.css is an alternative to CSS resets. The project is the product of 100′s of hours of extensive research by @necolas and @jon_neal on the differences between default browser styles.

The aims of normalize.css are as follows:

• Preserve useful browser defaults rather than erasing them.
• Normalize styles for a wide range of HTML elements.
• Correct bugs and common browser inconsistencies.
• Improve usability with subtle improvements.
• Explain the code using comments and detailed documentation.

It supports a wide range of browsers (including mobile browsers) and includes CSS that normalizes HTML5 elements, typography, lists, embedded content, forms, and tables.

Despite the project being based on the principle of normalization, it uses pragmatic defaults where they are preferable.

Normalize vs Reset

It’s worth understanding in greater detail how normalize.css differs from traditional CSS resets.

Normalize.css preserves useful defaults

Resets impose a homogenous visual style by flattening the default styles for almost all elements. In contrast, normalize.css retains many useful default browser styles. This means that you don’t have to redeclare styles for all the common typographic elements.

When an element has different default styles in different browsers, normalize.css aims to make those styles consistent and in line with modern standards when possible.

Normalize.css corrects common bugs

It fixes common desktop and mobile browser bugs that are out of scope for resets. This includes display settings for HTML5 elements, correcting font-size for preformatted text, SVG overflow in IE9, and many form-related bugs across browsers and operating systems.

http://nicolasgallagher.com/about-normalize-css

Canvas

High performance HTML5 content in Metro-style Apps

Metro style apps in Windows 8 have all the performance benefits of IE10 when showing Web content. In Metro style apps, Web content is always JIT compiled and hardware-accelerated. Other platforms do not provide the same level of performance in apps. For example, Cocoa apps on iOS offer significantly worse JavaScript performance (via the UIWebView control) than the same content running in Safari. These Cocoa apps do not enjoy JIT compilation, and these apps cannot show and use Web content the same way the browser on the system can:

Testing configuration: http://www.webkit.org/perf/sunspider/sunspider.html.
iPad: 1st Gen, iOS 5.0.1.
Windows 8: Developer Preview, Dell Optiplex 745, 64-bit OS.
Kindle Fire v1.

http://blogs.msdn.com/b/ie/archive/2012/02/07/high-performance-html5-content-in-metro-style-apps.aspx

LayoutUnit

Background

To better support zooming, both on desktop and mobile devices, we are currently working on adding subpixel layout support WebKit. To do this we are changing the rendering tree to use subpixel units, called LayoutUnit, instead of integers to represent locations and sizes.

This working is currently being undertaken by  Levi Weintraub and  Emil A Eklund, please talk to us directly or ask on webkit-dev or #webkit if you have any questions and/or concerns.

LayoutUnit & Subpixel Layout

LayoutUnit¹ is an abstraction used to represent the location or size of a render object in fractions of a logical pixel, it is used primarily for layout and hit testing. The current implementation represents values as multiples of 1/60th pixel². This allows us to use integer math and avoids floating point imprecision.

Even though layout calculations are done using LayoutUnits the values are aligned to integer pixel values at paint time to line up with device pixels. While most modern graphics libraries support painting with subpixel precision, this results in unwanted anti-aliasing. When aligning to device pixels the edges are aligned to the nearest pixel and then the size is adjusted accordingly. This ensures that the bottom/right edge and the total width/height is at most off-by-one. 

https://trac.webkit.org/wiki/LayoutUnit

Differences Between jQuery .bind() vs .live() vs .delegate() vs .on()

Using the Bind Method

The .bind() method registers the type of event and an event handler directly to the DOM element in question. This method has been around the longest and in its day it was a nice abstraction around the various cross-browser issues that existed.

The .bind() method will attach the event handler to all of the anchors that are matched! That is not good. Not only is that expensive to implicitly iterate over all of those items to attach an event handler, but it is also wasteful since it is the same event handler over and over again.

Pros

• This methods works across various browser implementations.
• It is pretty easy and quick to wire-up event handlers.
• The shorthand methods (.click(), .hover(), etc...) make it even easier to wire-up event handlers.
• For a simple ID selector, using .bind() not only wires-up quickly, but also when the event fires the event handler is invoked almost immediately.

Cons

• The method attaches the same event handler to every matched element in the selection.
• It doesn't work for elements added dynamically that matches the same selector.
• There are performance concerns when dealing with a large selection.
• The attachment is done upfront which can have performance issues on page load.

Using the Live Method

The .live() method uses the concept of event delegation to perform its so called "magic". The way you call .live() looks just like how you might call .bind(), which is very convenient. However, under the covers this method works much different. The .live method attaches the event handler to the root level document along with the associated selector and event information. By registering this information on the document it allows one event handler to be used for all events that have bubbled (a.k.a. delegated, propagated) up to it. Once an event has bubbled up to the document jQuery looks at the selector/event metadata to determine which handler it should invoke, if any. This extra work has some impact on performance at the point of user interaction, but the initial register process is fairly speedy. 

The good thing about this code as compared to the .bind() example above is that it is only attaching the event handler once to the document instead of multiple times. This not only is faster, but less wasteful, however, there are many problems with using this method and they are outlined below.

Pros

• There is only one event handler registered instead of the numerous event handlers that could have been registered with the .bind() method.
• The upgrade path from .bind() to .live() is very small. All you have to do is replace "bind" to "live".
• Elements dynamically added to the DOM that match the selector magically work because the real information was registered on the document.
• You can wire-up event handlers before the document ready event helping you utilize possibly unused time.

Cons

• This method is deprecated as of jQuery 1.7 and you should start phasing out its use in your code.
• Chaining is not properly supported using this method.
• The selection that is made is basically thrown away since it is only used to register the event handler on the document.
• Using event.stopPropagation() is no longer helpful because the event has already delegated all the way up to the document.
• Since all selector/event information is attached to the document once an event does occur jQuery has match through its large metadata store using the matchesSelectormethod to determine which event handler to invoke, if any.
• Your events always delegate all the way up to the document. This can affect performance if your DOM is deep.

Using the Delegate Method

The .delegate() method behaves in a similar fashion to the .live() method, but instead of attaching the selector/event information to the document, you can choose where it is anchored. Just like the .live() method, this technique uses event delegation to work correctly. 

If you skipped over the explanation of the .live() method you might want to go back up and read it as I described some of the internal logic that happen.

The .delegate() method is very powerful. The above code will attach the event handler to the unordered list ("#members") along with the selector/event information. This is much more efficient than the .live() method that always attaches the information to the document. In addition a lot of other problematic issues were resolved by introducing the .delegate() method. See the following outline for a detailed list.

Pros

• You have the option of choosing where to attach the selector/event information.
• The selection isn't actually performed up front, but is only used to register onto the root element.
• Chaining is supported correctly.
• jQuery still needs to iterate over the selector/event data to determine a match, but since you can choose where the root is the amount of data to sort through can be much smaller.
• Since this technique uses event delegation, it can work with dynamically added elements to the DOM where the selectors match.
• As long as you delegate against the document you can also wire-up event handlers before the document ready event.

Cons

• Changing from a .bind() to a .delegate() method isn't as straight forward.
• There is still the concern of jQuery having to figure out, using the matchesSelectormethod, which event handler to invoke based on the selector/event information stored at the root element. However, the metadata stored at the root element should be considerably smaller compared to using the .live() method.

Using the On Method

Did you know that the jQuery .bind(), .live(), and .delegate() methods are just one line pass throughs to the new jQuery 1.7 .on() method? The same is true of the .unbind(),.die(), and .undelegate() methods.

Pros

• Brings uniformity to the various event binding methods.
• Simplifies the jQuery code base and removes one level of redirection since the .bind(),.live(), and .delegate() call this method under the covers.
• Still provides all the goodness of the .delegate() method, while still providing support for the .bind() method if you need it.

Cons

• Brings confusion because the behavior changes based on how you call the method.

http://www.elijahmanor.com/2012/02/differences-between-jquery-bind-vs-live.html

Touchy.js

Because some things just need to be touched.

Touchy.js is a simple light-weight (1.15 kb compressed) JavaScript library for dealing with touch events in the browser. With no dependencies, just add the script to your page and start hacking.

https://github.com/jairajs89/Touchy.js

FileWatcher

Synopsis

Currently, there is no cross-platform solution that allows a front-end developer to alter some code (flavor agnostic) and immediately see the result occur in the browser.

This is a poor man's solution to solving that problem half way. The code base has been split up into two halves; a script that watches specific URL's for any content changes and another script which gathers the resources used on the page.

This script is the first half.

How It Works

FileWatcher is a constructor function that keeps a in-object cache of the contents of files. When a file is added to the watcher, it is pushed into a queue.

When a watcher is started, it takes the first item from the queue and fires an XHR or one of its cousins (cross-browser down to IE5.5) to fetch the content of a resource.

If the content has never been seen before, it is added to our cache. If there is a change, trigger the listeners.

Next, the file is added back to the queue to be watched. Then, one second later (or whatever the delay is) the next item is pulled from the queue and the process begins again.

Develop with a hands-free refresh

FileWatcher was initially built with a sister script called ResourceCollector. When these scripts are used together, they allow for webpages to dynamically refresh whenever there is an HTML change and seamlessly update images and CSS.

https://github.com/twolfson/File-Watcher

Serenade.js

Serenade.js is yet another MVC client side JavaScript framework. Why do we indulge in recreating the wheel? We believe that Serenade.js more closely follows the ideas of classical MVC than competing frameworks and has a number of other advantages as well:

• Super pretty, powerful yet logic-less template language
• Data bindings keep your views up-to-date without any extra work
• Powerful caching features
• Absolutely no dependencies, everything works without jQuery
• No need to inherit from base classes anywhere (though you can if you want)

https://github.com/elabs/serenade.jshttp://elabs.se/blog/33-why-serenade

EasyXDM – Crossdomain javascript done right

Cross-domain requests are frowned upon by browser vendors and with good reason – they are a huge security vulnerability. XSS vulnerabilities are one of the biggest nightmares for web security experts. Those ugly things can do anything from stealing user data to plastering their browser with popup ads. Worse yet, they can appear on your site through no fault of your own!

And yet, sometimes all you really need is to do a controlled cross-domain request and all your troubles go away. Maybe you’re crating an embeddable widget for the wordpress dashboard, or just want to list github repositories on your website without taxing the server. Or a bookmarklet. A sharing widget maybe?

Here are just some of the hacks we’ve all used before:

• JSONP – execute arbitrary unchecked code right in your app
• iframes – communication through URL fragments, changing window names and just generally create a big unmaintainable mess
• proxies – a long client-server-API-server-client roundtrip
• URL fragments – let’s just populate the browser history with a bunch of odd #something entries, OAuth2 uses this

To add insult to injury, not only do all these hacks come with a bunch of problems of their own – they don’t even solve the problem. All of them restrict what you can send (small-ish strings only), how it should be encoded and generally come with big latencies.

There’s a better way. Something all the big players are already using but you don’t know about it. In fact until a week ago I didn’t either and I follow the web tech scene pretty closely.

EasyXDM

EasyXDM gives you the ability to make cross-domain requests securely from a client to a server and even from a client to a client. The real beauty of it is that it can even open a socket-like device that you can use to communicate rather efficiently … in every browser. Even IE6.

http://www.zemanta.com/fruitblog/easyxdm-crossdomain-javascript-done-right