ie10

All posts tagged ie10

With IE10 in Windows 8, we reimagined the browser. we designed and built IE10 to be the best way to experience the full Web on Windows. Consumers can now enjoy more touch-friendly, fast and fluid Web applications with the updated IE10 engine included in the Windows Release Preview. this sixth Platform Preview of IE10 delivers improved performance and support for touch-first HTML5, as well as a new power-optimized, touch-friendly Adobe Flash Player that enables content on compatible Web sites to play in the Metro style Web browser. IE10 also sends the “Do Not Track” signal to Web sites by default to help consumers protect their privacy.

this video shows some of the performance and touch improvements in the sixth IE10 Platform Preview, part of the Windows Release Preview.
(This video is also available on Channel 9)

You can read more about the improvements to the Metro style browsing experience on the Building Windows 8 blog. the remainder of this post discusses the underlying HTML5 engine.

Windows 8 includes one HTML5 browsing engine that powers both browsing experiences (the Metro style one and desktop one) as well as Metro style applications that use HTML5 and JavaScript. the common HTML5 engine provides consistently fast, safe, and powerful support for Web standards and the Web programming model, for both browser experiences as well as for Metro style applications.

Consumers experience this power with responsive, touch-friendly pages that safely take full advantage of the underlying hardware. some examples that you can try at the IE Test Drive site with the Consumer Preview include the Chalkboard Benchmark for common touch actions like panning and zooming and a multi-touch capable Web page for manipulating photos and images. You can read the full list in the IE10 developer guide.

Touch-friendly Adobe Flash in Metro style Internet Explorer 10

The Windows 8 Release Preview includes a new power-optimized, touch-friendly Adobe Flash Player. Adobe Flash content on compatible Web sites will now play in Metro style IE10. Metro style IE10 with Flash on Windows 8 enables people to see more of the Web working with high quality, especially compared with the experience in other touch-first or tablet experiences.

We believe that having more sites “just work” in the Metro style browser improves the experience for consumers and businesses alike. as a practical matter, the primary device you walk around with should play the Web content on sites you rely on. Otherwise, the device is just a companion to a PC. Because some popular Web sites require Adobe Flash and do not offer HTML5 alternatives, Adobe and Microsoft worked together closely to deliver a Flash Player suitable for the Metro style experience.

Both IE10 on the Windows desktop and Metro style IE use the same integrated Flash Player, with no need to download or install an additional player. IE10 on the desktop provides the same full Flash support as previous versions of IE that relied on the Flash Player plug-in, and continues to support other plug-ins. the Metro style browser continues to provide no support for other separate ActiveX controls or plug-ins.

While any site can play Flash content in IE10 on the Windows desktop, only sites that are on the Compatibility View (CV) list can play Flash content within Metro style IE. we place sites with Flash content on the CV list if doing so delivers the best user experience in Metro style IE with those sites. for example, how responsive is the content to touch? does it work well with the onscreen keyboard, or affect battery life? Do visual prompts comply with the Metro style user experience guidelines? Sites that rely on capabilities (e.g. rollovers and P2P functionality) that are not supported within the Metro style experience, and don’t degrade gracefully in their absence, are better off running in IE with Flash on the desktop. Site developers continue to control the content they serve to browsers. Developers can send HTML5 content to Metro style IE, or express their preference that Metro style IE prompt users to run their site on the desktop (see details here).

A good Flash Player experience is part of a no compromise experience across all form factors of PCs, including touch-centric PCs running Windows 8. We’ve heard feedback from customers about their experience with sites that do not offer an HTML5 experience. for example, try pbskids.org on an iPad. some workforce solutions, like Beeline, require Flash. some financial management sites, like this one, require Flash. And some sites still deliver their best experience with Flash, such as youtube.com.

Adobe and Microsoft added support for touch gestures – like double tap and pinch to zoom – that work consistently across HTML5 and Flash. Adobe and Microsoft worked together to disable the desktop Flash functionality that is incompatible with touch, such as rollovers, within the Metro style experience. much of Flash’s other functionality works well with touch.

Together we have also improved battery life with better support for PLM in the Metro style experience. Flash on Windows has already supported offloading potentially battery-draining video work to specialized video hardware for some time (link). this work improves responsiveness and performance as well.

Adobe and Microsoft have worked closely together for some time to address security and reliability issues (for example here, and here), sharing best practices like the SDL/SPLC and ASLR as well as information on hangs and crashes. by updating Flash through Windows Update, like IE, we make security more convenient for customers. Microsoft and Adobe remain committed to meeting the expectations of Windows customers with regard to the delivery of security updates. we are also working together on accessibility, manageability, and privacy.

The Flash Player included with Windows 8 is based on the full PC implementation and not a limited mobile subset, and there’s a clear path to make it available on the new chip architectures that Windows 8 supports. Adobe is committed to delivering this same Flash Player support for Metro style IE on both x86/64 and the initial delivery of Windows RT PCs (Windows running on ARM processors).

For the development community, platform continuity and technology choice are important. Flash in Metro style IE10 provides a bridge for existing sites to transition to HTML5 technologies where it makes sense and at a pace that is right for the experiences they want to deliver to their customers. HTML5 does not currently support, for example, some premium video content and game scenarios.

We will provide additional technical information in the coming weeks through the regular documentation channels, like MSDN and Adobe Developer Connection. These details will include how developers can test Flash content on their own sites in Metro style IE, and how to submit their sites for consideration for the CV list. this documentation will also include a best practices guide to help developers, designers, and content publishers create experiences with Flash that plays well on Metro style IE. These best practices will complement existing recommendations on authoring touch-friendly HTML5 sites.

“Do Not Track” on by Default in IE in Windows 8

In Windows 8, IE10 sends a “Do Not Track” signal to Web sites by default. Consumers can change this default setting if they choose. this decision reflects our commitment to providing Windows customers an experience that is “private by default” in an era when so much user data is collected online. IE10 is the first browser to send a “Do Not Track” (DNT) signal by default.

You can read more about other actions underway with DNT here.

Vendor prefixes, and moving the Web forward from experimental to stable

With the Release Preview of Windows 8, IE10 adds support for non-vendor prefixed versions of standards that have reached Candidate Recommendation (CR) status since the Windows 8 Consumer Preview or should reach CR in 2012.

With this change, IE10 makes it easier for Web developers to write markup that works consistently across different browsers. Specifically, IE10 now supports the following W3C draft standards in their unprefixed form starting with the Release Preview: CSS transitions, transforms, animations, gradients, and CSS Fonts’ font-feature-settings property, as well as platform APIs such as the Indexed Database API (IndexedDB) and requestAnimationFrame().

We selected these standards after examining all the W3C draft standards IE10 supports and looking for standards that are stable (having no significant renaming or removal of properties/values expected), supported and interoperable across at least two browsers other than IE10 for the features’ core use cases, and already in use on the Web, including in their unprefixed form.

Browser vendors generally drop the vendor prefix once a specification reaches CR. for compatibility with sites and apps developed using the Windows 8 Consumer Preview and that rely on the Microsoft vendor prefix, IE10 continues to support the -ms- vendor-prefixed forms as well. Note that IE10 continues to support only the vendor-prefixed form of several other standards because these specifications are not yet sufficiently stable and interoperable, for example CSS Flexible Box Layout.

As a best practice, developers typically add an unprefixed version of a property to “future-proof” their pages. the following set of declarations is now ready for future browsers that support unprefixed CSS Transforms:

-webkit-transform: rotate(30deg);

-moz-transform: rotate(30deg);

-ms-transform: rotate(30deg);

-o-transform: rotate(30deg);

transform: rotate(30deg);

Other Key Platform Changes

In the Release Preview, we continue to improve performance. Web pages should just “stick to your finger” and remain fast and fluid while panning, zooming, and scaling content. the Chalkboard Benchmark shows the results of some of our performance work. it measures how efficiently a browser can perform these common touch actions by zooming in and out of a “chalkboard” while panning left, right, up, and then down. IE10’s performance here is a great example of Internet Explorer’s hardware acceleration in action.

Performance improvements contribute to great touch support, for example with full independent composition of Web page contents (fixed elements, subscrollers, animations, and video). We’ve also improved performance on low-end hardware; intensive sites now show much less flashing and flickering on low-end hardware. These improvements make IE10’s support for full screen video playback (in both HTML5 video and Adobe Flash Player) even better.

We’ve continued to improve the performance of the Chakra JavaScript engine. JavaScript intensive Web applications, like HTML5 games, will benefit from dynamic profile-based JIT, type-specialized code generation for floating point numbers, expansion of function inlining, and further tuning to reduce the idle memory footprint while reducing the observable pauses due to garbage collection.

We’ve also improved standards support in a number of ways. IE10 now has support for IVS/Emoji characters and the classList API and new reverse and alternate-reverse values of the animation-direction CSS property. DOM exceptions match the W3C WebIDL spec, and developers can use a constructor to create Blob objects, matching the W3C spec. We’ve also removed legacy DX filters from all modes.

HTML5 applications and sites can do more with touch via the MSGesture APIs that provide instantiable gesture event handling.

A better Web Today, and Ahead

The opportunities continue for HTML5 to make both Web sites and applications better. Those opportunities are exciting for everyone on the Web.

To get to that Web sooner, we continue to recommend that developers update old and out of date patterns on their sites. Looking at the CV list you can find examples of sites that need shimming because they use out of date libraries (e.g. here) or rely on browser detection rather than feature detection. the compatibility problem reports we receive have more to do with sites detecting IE and sending it different content than they send other browsers than any particular issue in IE. Developers can find sample feature detection code patterns in several IE blog posts, including this one.

The quality and correctness of different browsers’ HTML5 engines continue to vary widely. we will submit updates to test cases to the W3C for all the features that IE10 now supports without a prefix. as members and co-editors of the CSS Working Group, we will work with our colleagues to move these specifications forward to Candidate Recommendation. we continue to contribute to the test suites under development at the HTML5 standards bodies to further the goal of interoperability and same markup. We’ve submitted and updated over 240 tests to them that you can view at the IE Test Center as well. as different browsers improve their support of the same markup to produce the same results, we can all realize the promise of HTML5.

You can find a full list of new functionality available to developers in the IE10 developer guide here. Download the Windows 8 Release Preview to try this update to IE10. we look forward to continued engagement with the developer community and your feedback on Connect.

—Dean Hachamovitch, Corporate Vice President, Internet Explorer

Windows Release Preview: The Sixth IE10 Platform Preview





IE10 in the Windows 8 Release Preview supports the width and height properties of the W3C Working Draft CSS Device Adaptation. this gives Web developers a simple tool to control automatic content scaling across various window dimensions. In particular, it enables Web sites to easily adapt to Windows 8 Metro style browser in the snapped view and portrait orientation.

Auto-Scaling and when it Is Used

Most websites have prioritized optimization for a 1024 pixel wide window. this ensures a good user experience for a wide variety of displays when the browser is maximized. however, sites may not work well on new form factors like tablets and portrait screen orientation if they haven’t optimized for other window sizes as well. In particular, pages often clip or distort layout when viewed in a narrow width.


TechCrunch and Wikipedia displayed in very narrow windows

This narrow layout is particularly important in Windows 8, where the snapped view of the Metro style browser is in this exact state. this situation also occurs for portrait mode on slate devices due to the smaller form factor.

In the Metro style browser, the snapped view and portrait mode are auto-scaled by default to ensure at least 1024 pixels of layout width. Mobile devices take a similar approach when displaying non-mobile-optimized sites on a narrow form factor. Since most sites are built to work well at 1024 pixels, this ensures that they are laid out well and do not clip content by default.


TechCrunch and Wikipedia displayed in Windows 8 Metro style browser in snapped view

Although this approach ensures a good default experience, users will need to zoom in to view and interact with the site.

Working well In a Narrow Window

The best narrow layouts are those that have been custom-made by the Web developer. In addition to fitting the site into a narrower region, this also may require changes to image sizes, reordering of content, alternative tools for site navigation, or other fundamental changes to content.

If your site has already made these modifications for narrow windows, then Device Adaptation can be used to override the default scale.

For some great examples of adaptive layouts, check out Media Queries. Metal Toad Media also has a great article discussing layout width support based on prevalent devices and screen sizes in the market.

Using @-ms-viewport

Simple support for the snapped view. if your site is already capable of a 320 pixel width layout, you can easily choose to show that version in the snapped view. Combining Device Adaptation with CSS media queries allows the auto-scaling feature to be overridden selectively. this CSS overrides the default auto-scaling, and instead enforces a consistent 320 pixel layout width for all windows 320 pixels wide or narrower:

@media screen and (max-width: 320px) {

@-ms-viewport { width: 320px; }

When the window is less than 320 pixels wide the content will be scaled down to fit. For example, a 300 pixel wide window will show the content at 93.75% scale. For larger widths, IE10’s normal scaling applies (for example, when the Metro style browser is in portrait mode).

Device adaptation degrades gracefully in browsers which do not yet support it. these browsers can still benefit from narrow layout support—they just won’t auto-scale to fit content to the window.

Portrait support. if your site supports a 768 pixel wide layout as well, then portrait mode support can be easily added with a second viewport rule:

@media screen and (max-width: 320px) {

@-ms-viewport { width: 320px; }

@media screen and (min-width: 768px) and (max-width: 959px) {

@-ms-viewport { width: 768px; }

We recommend testing your site in layout widths of 768 pixels (portrait on most slates) and 320 pixels (snapped Metro style browser) in addition to 1024 pixels and wider (landscape). You can see an example of the viewport rule in action in the Make it Snappy! demo on the IE Test Drive site.

—Matt Rakow, Program Manager, Internet Explorer

Adapting Your Site to Different Window Sizes

Internet Explorer’s commitment to achieving the goal of consistent “same markup, same results” across browsers is evidenced, in part, by IE9’s and IE10’s addition of CSS3 features that enable Web sites to move to standards-based features for their graphical effects. Earlier we wrote that Internet Explorer’s legacy visual filters and transitions, first introduced in IE4, are not supported in IE10’s Standards and Quirks modes and noted their inferior performance compared to their standards-based replacements. Based on further analysis of these filters’ performance and their very low usage on the public Web, Internet Explorer 10 in Windows 8 Release Preview removes them from all document modes for all sites in the Internet zone. The features remain available in IE10’s document modes 5, 7, 8, and 9 for sites in the Local Intranet and Trusted Sizes zones.

Updating Web Sites

there is no mechanism for a Web site developer to enable legacy filters on their pages.

our guidance remains the same as stated in Moving to Standards-based Web Graphics in IE10: Now is the time to make the move to standards-based markup and use IE10’s new CSS3 features instead of legacy DX Filters. Please refer to that post for specific guidance.

Changing Setting by Zone

End-users can change the default rendering of legacy filters using the Security tab of the Internet Options dialog. Select the zone to change and touch or click “Custom level…”. In the Security Settings dialog for that zone, scroll down to the Option “Render legacy filters” in the “Miscellaneous” section. there you may enable or disable the rendering of filters for all sites in that zone.


Security tab of the Internet Options dialog showing the Internet zone highlighted


Security Settings dialog scrolled to the location of the Render legacy filters setting

system administrators can control this setting for all users using Group Policy.

Move to Standards-based Markup

As we’ve written many times on this blog, users benefit when all browsers support the same standards-based markup and all sites serve standards-based content to all browsers.

We encourage all developers to serve the same standards markup to IE10 and move your sites off of IE’s legacy filter features today.

—Ted Johnson, Lead Program Manager, Internet Explorer Graphics

Legacy DX Filters Removed from IE10 Release Preview

Sharing a link to a Web page is a common activity on the PC, and it gets better with IE10 on Windows 8. One of the new features on Windows 8 is the Share charm, which allows you to seamlessly send content between apps on your PC. Previously, if you wanted to share an interesting article with your friend, or post a funny picture on your blog, you’d copy the link from the address bar, switch to a different site or app, and then paste it. now, with the Windows 8 Share charm, you can share directly from the browser without ever leaving your current page.

When you use the Share charm to share a site from the browser, IE10 creates two data formats that contain relevant content – the URI, and some HTML that includes a rich representation of the page. here are two examples of data that get shared for a YouTube video:

The URI (of the current site)

http://www.youtube.com/watch?v=4DbgiOCTQts

The HTML (with a link preview)


An example of IE10′s rich preview of Web pages

Both of these data formats are created for an “implicit” share, which is the name for what happens when you share the site that you are currently viewing. since Web pages can be represented as hyperlinks or a rich HTML link preview, IE10 includes both types of data. Of course, if you aren’t sharing the whole page, but rather, some content that you’ve highlighted, IE10 will share the HTML of your selection instead of the URI and the link preview. in this case, sharing a selection would be called an “explicit” share, and does not include the link. this post describes the link sharing case, how IE10 participates in the Windows 8 Share contract using HTML, and how Web developers can create link previews with just a few meta-tags.

The Share Charm and IE10

Here’s a video of how a user might share links from the browser to an app that uses HTML.

Sharing from IE10: Link Previews in Action

In this video, “Stash” is a sample link saving app that makes use of the Windows share charm with HTML. The sample app simply supports the HTML data format for sharing, and IE provides the link preview. Link previews are HTML that contains a title, image, and description for every shared link. this makes it easy for you to recognize the site content. if you have Windows 8 Consumer Preview and Visual Studio 11 Beta, you can download and run Stash on your own PC. Stash integrates with the Windows 8 Share contract as a target app, as you can see below. Below, you can see a high-level diagram that shows how links are shared from IE10.


Diagram: Sharing a link from IE10 to target apps, using the Share charm’s data package

Windows 8 Share charm handles the coordination between the source and target apps to provide an integrated sharing experience across all apps. this removes the need for target and source apps to be aware and coordinate between each other.

Sharing the Web is better, Start to Finish

The Web is made up of HTML. That’s why HTML is one of the most important data formats in IE10’s integration with the Share contract. IE10 creates link previews to both provide a better sharing experience for users, and to help connect Web developers to Windows 8 Share. With a little extra meta-data markup, sites can define what information is included in their link previews. on the other end of the share contract, target apps that support the HTML data format can get the full experience of contextual Web hyperlinks without having to parse a single site. The end result is a rich, modern, and fluid sharing experience, from end to end.


Screenshot of target apps available in Share pane


Screenshot of Stash’s Share Pane

When you share a Web site, IE10 parses that site to create a link preview. in the example above, it’s a short snippet of content that represents a movie page on IMDb. The goal of sharing HTML, in addition to the URI, is to share the best possible representation of what the user intended to share, so IE10 creates link previews for all implicit shares. The benefits of HTML are that it can include more information than a URI, and the content of the HTML is more meaningful than a hyperlink. in the words of Leslie Knope, no one wants to share that “complicated nonsense.”


From NBC’s Parks and Recreation, Season 4, Episode 16

So, as you can imagine, we would have never ordered a sign with all this complicated nonsense because, you know, we’re not insane.

Depending on the target app, though, sometimes rich content is not the best kind of data, and a URI is more useful. For example, blogging apps can take advantage of rich HTML content, and SMS apps would do best to use the URI. Developers of Metro style apps choose the data format(s) that make most sense for their app to receive, following the Windows 8 Share guidance.

Sites use Markup to Define what IE10 Shares

Since IE10 uses existing markup meant for sharing on the Web, many sites will already look great when sharing HTML link previews on Windows 8. we support the Open Graph protocol as a simple way to add meta-data about the page. When users share sites on Facebook and through Windows 8 and IE10, you can use OpenGraph to control the way your Web page appears to others.

Here’s an example of an IE test drive demo that uses this markup:

<meta name="description" content="Brick Breaker TestDrive Demo Game, Performance and Touch benchmark" />

<title>Brick Breaker</title>

<meta property="og:image" content="Views/Homepage/Icons/BrickBreaker.png" />

IE looks for the following tags in the site’s markup to create the page’s link preview.

PropertyHTML tagCharacter limitTitle 1<meta name=”title” content=”Insert Site Title Here” />160Title 2<title>Insert Site Title Here</title>160Description<meta name=”description” content=”Insert Site Description Here” />253Image 1<meta property=”og:image” content=”insert_image_link_here” />2,048 (limit for image URI)Image 2<link rel=”image_src” href=”insert_image_link_here” />2,048 (limit for image URI)Image 3<meta name=”image” content=”insert_image_link_here” />2,048 (limit for image URI)Image 4<meta name=”thumbnail” content=”insert_image_link_here” />2,048 (limit for image URI)

Note that this is the order in which we parse for each attribute. For example, if both Image 1 and Image 2 tags are present, we’ll use the Image 1 tag. Additionally, if more than one tag of any type is present, we use the first one you list in your markup.

For character limits, if the description is longer than the maximum length, IE will put a “…” at the end in the preview.

Make sure to include at least one of each property in your site markup to get your pages looking great for sharing in Windows 8. See this demo on the IE Test Drive site for more on how the markup works.

Apps Get the Benefit of a Powerful Web Browser

If your app supports the Share target app contract, you should consider whether it makes sense for it to support HTML as a shared data format. Apps that use HTML can benefit from the link previews shared by IE10 because IE10 does all of the heavy lifting. it parses the site and puts together a short and informative link preview, and all your app needs to do is display and host the HTML. The hyperlink is embedded within the preview, so it functions just like a Uri, but looks much better. this way, apps that don’t have the resources to parse the Web to condense pages into small, rich previews, can still display contextual links as HTML.

Many apps, in addition to IE10, will share HTML. Target apps that accept HTML must be agnostic about the source of the shared data. as noted above, IE10 shares HTML for both implicit and explicit sharing scenarios, so sometimes the HTML is a link preview, and sometimes it’s a user selection. in either case, the content of the HTML is the best possible representation of what the user intended to share. Here’s a snippet of what the link preview HTML generated by IE10 will look like when it’s added to the Share charm’s Data Package:

<!–StartFragment–>

/* IE10uc1u8217?s metro-style CSS attributes */

<a class="snippet-URL" href="http://site_link_goes_here">Website Title goes here</a>

<td class="snippet-image">

<img src="image_link_goes_here" />

<td class="snippet-text">Website description goes here </td>

<!–EndFragment–>

For an example of an app that uses HTML from IE10, download the sample app “Stash” seen in the video above. this app demonstrates how a Metro style app can use HTML data as a share target.

Here’s a code snippet from the app, which shows how Stash uses HTML sent from the Share charm.

function activatedHandler(eventArgs) {

// in this sample we only do something if it was activated with the Share contract

if (eventArgs.detail.kind

=== Windows.ApplicationModel.Activation.ActivationKind.shareTarget) {

// we receive the ShareOperation object as part of the eventArgs

var shareOperation = eventArgs.detail.shareOperation;

if (shareOperation.data.contains(

Windows.ApplicationModel.DataTransfer.StandardDataFormats.html)) {

shareOperation.data.getHtmlFormatAsync().then(

function (htmlFormat) {

// Extract the HTML fragment from the HTML format

var htmlFragment = Windows.ApplicationModel.DataTransfer

.HtmlFormatHelper.getStaticFragment(htmlFormat);

// display the HTML in the Share pane.

id("htmlArea").innerHTML = htmlFragment;

The above code lets Stash accept HTML when the user selects it as their Share target. For more on developing a Share target app on Windows 8, see the MSDN Quickstart page for receiving shared content.

—Alex Feldman, Program Manager, Internet Explorer

Sharing Links from IE10 on Windows 8

With HTML5 comes many APIs that push the envelope on user experiences involving media and real-time communications. These features often rely on binary file formats, like MP3 audio, PNG images, or MP4 video. the use of binary file formats is important to these features to reduce bandwidth requirements, deliver expected performance, and interoperate with existing file formats. but until recently, Web developers haven’t had direct access to the contents of these binary files or any other custom binary files.

This post explores how Web developers can break through the binary barrier using the JavaScript Typed Arrays API, and explore its use in the Binary File Inspector Test Drive demo.

Typed Arrays, available in IE10 Platform Preview 4, enable Web applications to use a broad range of binary file formats and directly manipulate the binary contents of files already supported by the browser. Support for Typed Arrays has been added throughout IE10: in JavaScript, in XMLHttpRequest, in the File API, and in the Stream API.

Binary File Inspector

The Binary File Inspector test drive demo highlights some of the new capabilities offered by this combination of new features. you can see the ID3 headers for music files, get a sense of the raw bytes in video files, and also see how additional file formats, like the PCX image file format, can be supported in the browser with the use of JavaScript and Canvas.

In the example above, an .mp4 video is rendered using a <video> element on the left, and the binary contents of the file are displayed on the right, both in HEX form, and as corresponding ASCII characters. In this example, you can see some characteristic elements of the MPEG file format, such as the “ftyp” of “mp4.”

Typed Arrays and ArrayBuffers

Typed Arrays provide a means to look at raw binary contents of data through a particular typed view. For example, if we want to look at our raw binary data a byte at a time, we can use a Uint8Array (Uint8 describes an 8-bit unsigned integer value, commonly known as a byte). If we want to read the raw data as an array of floating point numbers, we can use a Float32Array (Float32 describes a 32-bit IEE754 floating point value, commonly known as a floating point number). the following types are supported:

Array TypeElement size and descriptionInt8Array8-bit signed integerUint8Array8-bit unsigned integerInt16Array16-bit signed integerUint16Array16-bit unsigned integerInt23Array32-bit signed integerUint32Array32-bit unsigned integerFloat32Array32-bit IEEE754 floating point numberFloat64Array64-bit IEEE754 floating point number

Each array type is a view over an ArrayBuffer. the ArrayBuffer is a reference to the raw binary data, but it does not provide any direct way to interact with the data. creating a TypedArray view of the ArrayBuffer provides access to read from and write to the binary contents.

The example below creates a new ArrayBuffer from scratch and interprets its contents in a few different ways:

// Create an 8 byte buffer

var buffer = new ArrayBuffer(8);

// View as an array of Uint8s and put 0×05 in each byte

var uint8s = new Uint8Array(buffer);

for (var i = 0; i < 8; i++) {

uint8s[i] = 5; // fill each byte with 0×05

// Inspect the resulting array

uint8s[0] === 5; // true – each byte has value 5

uint8s.byteLength === 8; // true – there are 8 Uint8s

// View the same buffer as an array of Uint32s

var uint32s = new Uint32Array(buffer);

// the same raw bytes are now interpreted differently

uint32s[0] === 84215045 // true – 0×05050505 == 84215045

In this way, Typed Arrays can be used for tasks such as creating floating point values from their byte-level components or for building data structures that require a very specific layout of data for efficiency or interoperation.

Typed Arrays for Reading Binary File Formats

An important new scenario enabled by Typed Arrays is to read and render the contents of custom binary file formats that are not natively supported by the browser. As well as the various array types introduced above, Typed Arrays also provide a DataView object that can be used to read and write the contents of an ArrayBuffer in an unstructured way. This is well suited to reading new file formats, which are typically made up of heterogeneous mixes of data.

The Binary File Inspector demo uses DataView to read the PCX file format and render it using a <canvas> element. Here’s a slightly simplified version of what the demo does to read the file header, which includes information like the width, height, DPI, and bits-per-pixel of color depth.

var buffer = getPCXFileContents();

var reader = new DataView(buffer);

// Read the header of the PCX file

// the first section is single bytes

header.manufacturer = reader.getUint8(0);

header.version = reader.getUint8(1);

header.encoding = reader.getUint8(2);

header.bitsPerPixel = reader.getUint8(3);

// the next section is Int16 values, each in little-endian

header.xmin = reader.getInt16(4, true);

header.ymin = reader.getInt16(6, true);

header.xmax = reader.getInt16(8, true);

header.ymax = reader.getInt16(10, true);

header.hdpi = reader.getInt16(12, true);

header.vdpi = reader.getInt16(14, true);

Code similar to the above can be used to add support for rendering a broad range of new data formats in the browser including examples like custom image formats, additional video file formats or domain-specific map data formats.

Getting Binary Data with XHR and File API

Before we can use the Typed Arrays APIs to work with the contents of files, we need to use browser APIs to get access to the raw data. For accessing files from the server, the XMLHttpRequest API has been extended with support for various “responseType”s. the “arraybuffer” responseType provides the contents of the requested server resource to JavaScript as an ArrayBuffer object. also supported are the “blob,” “text” and “document” response types.

function getServerFileToArrayBufffer(url, successCallback) {

// Create an XHR object

var xhr = new XMLHttpRequest();

xhr.onreadystatechange = function () {

if (xhr.readyState == xhr.DONE) {

if (xhr.status == 200 && xhr.response) {

// the 'response' property returns an ArrayBuffer

successCallback(xhr.response);

alert("Failed to download:" + xhr.status + " " + xhr.statusText);

// Open the request for the provided url

xhr.open("GET", url, true);

// Set the responseType to 'arraybuffer' for ArrayBuffer response

xhr.responseType = "arraybuffer";

In many cases files are provided by the user, for example as an attachment to an email in a Web mail application. the File API offers Web developers tools to read the contents of files provided via an <input> element, drag-and-drop or any other source that provides Blobs or Files. the FileReader object is used to read the contents of a file into an ArrayBuffer and, like the XHR object, is asynchronous to ensure that reading from the disk does not prevent the user interface from responding.

function readFileToArrayBuffer(file, successCallback) {

// Create a FileReader

var reader = new FileReader();

// Register for 'load' and 'error' events

reader.onload = function () {

// the 'result' property returns an ArrayBuffer for readAsArrayBuffer

var buffer = reader.result;

successCallback(buffer);

reader.onerror = function (evt) {

// the error code indicates the reason for failure

if (evt.target.error.code == evt.target.error.NOT_READABLE_ERR) {

alert("Failed to read file: " + file.name);

// begin a read of the file contents into an ArrayBuffer

reader.readAsArrayBuffer(file);

Conclusion

Binary data is heavily used by Web browsers. With support for Typed Arrays, XHR2 and the File API in IE10, Web applications can now work directly with binary data, to manipulate byte-level data, to render additional binary data formats, and to extract data from existing media file formats. Try out the Binary File Inspector test drive demo, and take Typed Arrays for a spin in IE10.

—Luke Hoban, Program Manager, JavaScript

Working with Binary Data using Typed Arrays