The fourth IE10 platform preview includes enhanced HTML5 support by using an interoperable quirks mode based on the behavior defined in HTML5. This HTML5-based quirks mode is the default quirks mode in IE10.
Users and Web developers want sites to just work across browsers. A key part of this is making HTML, CSS, and JavaScript work in the same way across implementations. HTML5 facilitates cross-browser consistency by defining parts of the Web platform previously left unspecified. This largely involves the HTML5 parsing rules, but also includes parts about howbrowsersshouldbehave in quirks mode.
IE10’s HTML5 quirks mode is used for pages without a DOCTYPE or with a legacy DOCTYPE as defined in HTML5. Like HTML5 and other browsers, the behavior of IE10’s quirks mode is the same as standards mode with select quirks applied. This means features like
Developers can quickly identify which mode a page uses via the F12 developer tools. The latest HTML5 standards and quirks modes are now listed as Standards and Quirks. Legacy modes are still listed by the version of IE that introduced them. IE's legacy quirks mode is now referred to as Internet Explorer 5 quirks.
F12 Developer Tools’ Document Mode menu
IE10 continues to use Internet Explorer 5 quirks in Compatibility View for pages without a DOCTYPE, and for pages that opt-in via X-UA-Compatible.
<metahttp-equiv="X-UA-Compatible"content="IE=5">
Call to Action
HTML5 defines quirks mode for compatibility and interoperability, but you should continue to author new sites for standards mode by using at the top of your pages. Please help ensure IE10's HTML5 quirks mode works correctly by reporting issues via Connect.
The December 2011 Cumulative Security Update for Internet Explorer is now available via Windows Update. This security update resolves three privately reported vulnerabilities in Internet Explorer. The most severe vulnerabilities could allow remote code execution if a user visits a specially crafted Web page using Internet Explorer. An attacker who successfully exploited this vulnerability could run a malicious application on the affected system. Users whose accounts are configured to have fewer user rights on the system could be less affected than users who operate with administrative user rights.
This security update is rated Important for Internet Explorer on Windows clients and Internet Explorer 9 for Windows 2008 R2; and Low for Internet Explorer on Windows servers. For more information, see the full bulletin.
Most customers have enabled automatic updating and do not need to take any action. We recommend that customers, who have not enabled automatic updating, enable it (Start Menu, type “Windows Update”). We recommend that administrators, enterprise installations, and end users who want to install this security update manually, apply the update immediately using update management software or by checking for updates using the Microsoft Update service.
In the spirit of the holiday season, we offer a new HTML5 experience that makes the most of your PC hardware and the new touch capabilities in Windows 8.
Check out Let It Snow and get ready for a GPU-powered snow storm. This experience brings together hardware-accelerated HTML5 canvas, SVG, CSS, and more. On Windows Developer Preview with support for multi-touch in IE10, you can reach out and brush the snow off the sign and reveal a holiday message -or just use your mouse. If you think your browser can keep up, kick it up to 1000 snowflakes. If it's more of a flurry than a blizzard, try it with IE9 (or IE10) using the hardware acceleration built into the browser.
Click the image to Let It Snow
Earlier this year we showed the first look at IE10, which offers more and more of the site ready HTML5 developers are asking for, so they can build beautiful and interactive Web experiences. With the Windows Developer Preview, we introduced more hardware-accelerated HTML5 for building touch friendly applications on the Web. We’re delighted and amazed by what developers are building on HTML5 and excited to be part of it.
Thank you!
Your participation and feedback is an important part of how we build IE. Today we want to say thank you to everyone who browses the Web with IE9, downloads the IE10 previews, runs the test drives, and reports issues on Connect. We also want to thank the people and groups who make the standards process work, the broad community of Web developers, and enthusiastic consumers who work to move the Web forward.
From the entire IE team, we wish you a Happy Hardware-accelerated Holiday Season, and we look forward to another exciting year on the Web in 2012.
We continue to contribute to the test suites under development at the HTML5 standards bodies, submitting 118 new tests to them, to further the goal of interoperability and same markup. You can view them at the IE Test Center as well. We strongly encourage all developers to write for HTML5 standards first by always using the HTML5 doc type in your pages.
IE10 Preview 4 introduces an updated quirks mode that is more consistent and interoperable with the way quirks modes works in other browsers like Firefox, Chrome, Safari, and Opera. This updated quirks mode supports quirks for page layout, while allowing use of more up-to-date standards features like HTML5 elements for audio, video, canvas, and more.
You can find a full list of new functionality available to developers in the IE10 developer guide here. Download the Windows 8 developer preview to try this update to IE10. We look forward to continued engagement with the developer community and your feedback on Connect.
This IE10 preview supports CORS (cross origin resource sharing) to allow developers to use XMLHttpRequest to safely request, share, and move data across applications on different domains. This is a common pattern developers use to bring data and services together from different applications. In this test drive demo, you can see how CORS is used along with XMLHttpRequest, the File API, and HTML5 progress control to deliver a smooth experience for uploading multiple files to a service on another domain.
Click here to see CORS used with XMLHttpRequest to upload files across domains.
Having the ability to work with binary data and files enables developers to build new kinds of applications and experiences on the Web. This IE10 preview supports blobBuilder from File API: Writer for working with large binary objects (blobs) and JavaScript typed arrays. In this test drive demo, you can see how different file types, including file types which are not natively supported in the browser like PCX files can be read, rendered, and even have their internal contents displayed.
Click here to see how JavaScript typed arrays used with File APIs to read and view binary files.
As developers build more sophisticated applications on the Web, they have more need for precise control over how end-users select parts of the page. With CSS user select support in IE10, developers can specify which elements in their page can be selected by the consumer when using their applications. In this this test drive demo, you can see how selection control is applied in a sample blog application using the user-select property in a CSS rule.
Click here to try CSS user-select to control end-user Web page selection.
An updated platform preview of IE10 for the Windows Developer Preview is now available for download. This IE10 preview adds even more support for HTML5 technologies, enabling richer Web applications with significantly improved performance. IE10’s hardware acceleration of technologies like SVG, CSS3 transforms and animations delivers faster rendering than other browsers
With this fourth Platform Preview, developers can start working with more site-ready HTML5 technologies. You can read the full list here in the IE10 developer guide. Here are a few highlights:
Cross-Origin Resource Sharing (CORS) for safe use of XMLHttpRequest across domains.
File API Writer support for blobBuilder allowing manipulation of large binary objects in script in the browser.
Support for JavaScript typed arrays for efficient storage and manipulation of typed data.
CSS user-select property to control how end-users select elements in a Web page or application.
Support for HTML5 video text captioning, including time-code, placement, and captioning file formats.
These foundational capabilities are what developers building native applications depend on: working with binary data and files, controlling selection and hit testing in application UI, and providing accessible video content with captioning. The features in this platform preview are available to Web pages now, and will be available to Metro style applications in Windows 8.
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);
} else {
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";
xhr.send();
}
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 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.
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
var buffer = getPCXFileContents();
var reader = new DataView(buffer);
// Read the header of the PCX file
var header = {}
// 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.
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 Type
Element size and description
Int8Array
8-bit signed integer
Uint8Array
8-bit unsigned integer
Int16Array
16-bit signed integer
Uint16Array
16-bit unsigned integer
Int23Array
32-bit signed integer
Uint32Array
32-bit unsigned integer
Float32Array
32-bit IEEE754 floating point number
Float64Array
64-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 0x05 in each byte
var uint8s = new Uint8Array(buffer);
for (var i = 0; i < 8; i++) {
uint8s[i] = 5; // fill each byte with 0x05
}
// 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
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.
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
Internet Explorer 4 introduced a set of visual filters and transitions to allow Web developers to apply multimedia-style effects to their Web pages. The name DX Filters comes from their underlying implementation, DirectX, and their long-form syntax, e.g., “filter: progid:DXImageTransform.Microsoft.Alpha(opacity=50).” DX Filters are not the same as SVG Filter Effects, though both use the CSS property name filter.
The most popular of these effects have since become CSS3 Working Drafts or Candidate Recommendations including opacity, gradients, and shadows. With IE10 supporting these CSS3 specifications, there’s no need for the legacy, IE-specific filters. One additional filter, AlphaImageLoader, was once popular to work around bugs with PNG transparency in IE6 but those bugs were fixed in IE7.
The following table lists the most popular DX Filters and their standards-based alternatives.
DX Filter
Standards-based Alternative
Alpha
opacity
AlphaImageLoader
or background-image and related properties
Gradient
background-image: linear-gradient()
DropShadow
text-shadow or box-shadow
Matrix
transform, transform-origin
SVG Filter Effects in IE10 can be used to simulate some of the less common, more esoteric filters in the context of SVG. Note: Because IE9 document mode supports both DX Filters and some of the standards-based alternatives, it is wise to avoid specifying both properties on the same element. Libraries such as Modernizr make it easy to use feature detection with CSS and avoid duplicate declarations.
Make the Move to Same Markup Now
The changes described above are effective as of IE10 Platform Preview 4, available for Windows Developer Preview.
More than any version of IE before, IE10 works with the same markup and code as other popular browsers (once any CSS vendor-specific prefixes are updated to include “-ms-”). Going the other way, the removal of these two legacy features means that content developed for IE10 should also work in other browsers.
Users benefit when all browsers can work with the same standards-based content.
Users expect to visit any site on the Internet with any browser and enjoy a similar quality experience. We first discussed Internet Explorer’s commitment to achieving the goal of consistent “same markup, same results” across browsers in a post on March 16, 2010 announcing the release of the IE9’s first platform preview. IE9 moved us a long way toward that goal and IE10’s HTML5-based Standards and Quirks modes largely completes that work. The post HTML5 Parsing in IE10 listed some of the legacy features removed from IE10’s HTML5-based Standards and Quirks modes. This post expands the list of removed legacy features to include two more: Vector Markup Language (VML) and DirectX-based Filters and Transitions. Both of these features were marked deprecated in MSDN documentation as of IE9 (e.g., the first sentence of Filters and Transitions: “This topic documents a feature of Visual Filters and Transitions, which is deprecated as of Windows Internet Explorer 9”) and are now gone from IE10’s Standards and Quirks modes.
The common uses of VML and DX Filters now have standards-based alternatives implemented in IE10 and current versions of other browsers. These legacy IE features remain available in IE10 in document modes 5, 7, 8, and 9 though their performance is inferior to their hardware-accelerated, standards-based replacements. We encourage Web developers to move their sites to standards-based technologies rather than rely on legacy document modes.
Use SVG, not VML
Microsoft and others proposed VML (Vector Markup Language) to the W3C in 1998. IE5 first implemented it. The W3C merged VML with a competing proposal with the outcome being SVG. (See Vector Markup Language for a brief history.)
SVG, implemented in IE9, provides the functionality needed to replace VML in Web sites and applications that use it. The VML to SVG Migration Guide, published on the Microsoft Download Center, provides guidance for moving from VML to SVG.
The Raphaël JavaScript Library is a lightweight and easy-to-use graphics API that uses SVG when available and VML when not. Raphaël is a good choice for building vector graphics solutions that work in IE8 and newer browsers.
Last March, we released a prototype implementation of the audio portion of a working draft of the W3C Media Capture API on HTML5 Labs. This prototype publicized some proposed API enhancements described in section 6.1 of Microsoft’s HTML Speech XG Speech API Proposal. We have now updated the prototype to include the image and video capture features described in the proposal to support scenarios we’ve heard are important for Web developers, as well as incorporating your feedback on audio.
As more and more consumers use mobile devices to take still pictures, videos, and sound clips, Web developers increasingly need support to capture and upload image, video, and sound from their Web sites and applications. A usable and standardized API for media capture means Web sites and apps will be able to access these features in a common way across all browsers in the future.
During this past year, the effort to standardize media capture has intensified. The WebRTC working group was formed and combined scenarios that support basic video and audio capture with the ability to share that media in real-time communication scenarios. A broad interest in both of these scenarios from industry partners and browser vendors alike shifted focus away from the Media Capture API and brought the WebRTC draft spec to the forefront.
This past November, we took our experience with the development of this prototype and interest in media capture for the browser to the W3C's technical plenary meeting (TPAC). Travis Leithead shared some of our feedback with the Device APIs (DAP) Working Group and we continued existing discussions within the HTML Speech Incubator Group. One result of our engagement was the formation of a media capture joint task force in order to bring the best of local media capture and real-time communication scenarios together. We are actively participating in the task force and support the getUserMedia approach to capture.
With the release of this prototype, we give Web developers early access to photo, video and audio media capture APIs in the browser. We anticipate evolving the prototype to share implementation feedback and experience with the new media capture task force. The end goal remains to create the best possible standard for the benefit of the whole Web community.
Let’s also look back at our earlier proposals, explain why we believe the scenarios are still important, and why we implemented them in this new version of the prototype:
Privacy of device capabilities
The prototype allows enumeration of the capture device's capabilities (its supported modes). In the old W3C Device Capture API spec, privacy-sensitive information about the device could be leaked to an application because the navigator.device.capture.supported* properties could be accessed without user intervention. Our prototype moves these APIs to an object that is only available after the user gives permission. The W3C's current getUserMedia API does not support enumeration of device capabilities, but we believe it is valuable to Web developers and should be done in a similar privacy-sensitive manner.
Multiple Devices
The W3C's current getUserMedia API is designed to support multiple devices, either via hints to the API or through user preference. This is an improvement for a scenario that was not supported in the old W3C Device Capture API spec.
Our current prototype also supports a conceptually similar design: navigator.device.openCapture() which returns asynchronously with the capture device the user prefers (through preference or UI).
Direct Capture
In the old Media Capture API spec, the Capture.capture[Image|Video|Audio] operations launch an asynchronous UI that returns one or more captures. This means the user has to do something in the Web app to launch the UI and then initiate the capture, which makes it impossible to build capture UI directly into the Web application. Not only would this be unusable for a speech recognition application, but it is also places unnecessary user interface constraints on other media capture scenarios.
Our prototype and the current getUserMedia capture API directly capture from the device and return a Blob. Note that for privacy reasons some user agents will choose to display a notification in their surrounding chrome or hardware to make it readily apparent to the user that capture is occurring, together with the option to cancel the capture.
Streaming
For applications like speech recognition, captured audio needs to be sent directly to the recognition service. However, the current getUserMedia API design only supports capturing to Blobs, which delay the ability to process the recorded data.
Our prototypeallows starting a capture asynchronously and returning a Stream object containing the captured data. Support for Streams would also be useful in video recording scenarios. For example, using a capture stream, an app could stream a recording to a video sharing site, as it is recorded.
Preview
In the case of video capture, live preview within the application is important and something that was missing from the old Media Capture API spec.
Both our prototype and the W3C's getUserMedia API, allow a preview of the recording to be created with URL.createObjectURL(). This URL can then be used as the value for the src attribute on an
End-Pointing
For applications like speech recognition, it's important to know when the user starts and stops talking. For example, if the app starts recording but the user doesn't start talking, the app may wish to indicate that it can't hear the user. More importantly, when the user stops talking, the app will generally want to stop recording, and transition into working on the recognition results. This sort of capability may also be of some use during non-speech scenarios, to provide prompts to users who are recording videos.
Neither the old Media Capture API, nor the current getUserMedia approach support end-pointing.
In order to support key speech/voice scenarios, we recommend adding end-pointing capability. The prototype provides this feature and allows Web developers to experiment and provide feedback on these capabilities which will be useful feedback for the W3C.
Looking Forward
We are supportive of the getUserMedia API, and note that it incorporates many of the points of feedback previously submitted. To avoid confusion about the future direction of media capture at the W3C, the DAP working group has officially deprecated the old Media Capture API, which now redirects to the media capture joint task force's current deliverable.
In addition to a prototype plugin that exposes the modified APIs, we have added to this package a functional demo app that makes use of them.
Building this prototype and listening to your feedback will help Microsoft and the other browser developers build a better and more interoperable Web. We look forward to continuing this discussion in W3C and helping to finalize the specifications.
