Sharing Links from IE10 on Windows 8

Mon, 14 May 2012 20:53:50 GMT

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.”

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:

<head>

<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" />

</head>

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

Property	HTML tag	Character limit
Title 1	<meta name="title" content="Insert Site Title Here” />	160
Title 2	<title>Insert Site Title Here</title>	160
Description	<meta name="description" content="Insert Site Description Here” />	253
Image 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:

<html>

<body>

<!--StartFragment-->

<style>

/* IE10\uc1\u8217?s metro-style CSS attributes */

</style>

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

<table>

<tr>

<td class="snippet-image">

<img src="image_link_goes_here" />

</td>

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

</tr>

</table>

<!--EndFragment-->

</body>

</html>

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.

Happy sharing!

—Alex Feldman, Program Manager, Internet Explorer

Diagnosing JavaScript Errors Faster with Error.stack

Thu, 10 May 2012 21:54:45 GMT

IE10 in Windows 8 Consumer Preview includes support for Error.stack, which enables Web developers to diagnose and correct bugs faster, especially those that are difficult to reproduce. Developers can build amazing apps with the capabilities of Web platforms that power today’s modern browsers. In Windows 8, we expose that power through both Internet Explorer 10 and Metro style apps in JavaScript. The increasing power and complexity of these apps means developers need better tools like Error.stack for handling errors and diagnosing bugs.

Debugging Applications

Structured error handling in JavaScript rests on throw and try/catch – where the developer declares an error and passes the control flow to a portion of the program that deals with error handling. When an error is thrown, Chakra, the JavaScript engine in Internet Explorer, captures the chain of calls that led up to where the error originated – also referred to as the call stack. If the object being thrown is an Error (or is a function whose prototype chain leads back to Error), Chakra creates a stack trace, a human-readable listing of the call stack. This listing is represented as a property, stack, on the Error object. The stack includes the error message, function names, and source file location information of the functions. This information can help developers rapidly diagnose defects by learning what function was being called, and even see what line of code was at fault. For example, it might indicate that a parameter passed into the function was null or an invalid type.

Let’s explore with an example of a simple script that attempts to calculate the distance between two points, (0, 2) and (12, 10):

(function () {

'use strict';

function squareRoot(n) {

if (n < 0)

throw new Error('Cannot take square root of negative number.');

 

return Math.sqrt(n);

}

 

function square(n) {

return n * n;

}

 

function pointDistance(pt1, pt2) {

return squareRoot((pt1.x - pt2.x) + (pt1.y - pt2.y));

}

 

function sample() {

var pt1 = { x: 0, y: 2 };

var pt2 = { x: 12, y: 10 };

 

console.log('Distance is: ' + pointDistance(pt1, pt2));

}

 

try {

sample();

}

catch (e) {

console.log(e.stack);

}

})();

This script has a bug – it forgets to square the differences of the components. As a result, for some inputs, the pointDistance function will simply return incorrect results; other times, it will cause an error. To understand the stack trace, let’s examine the error in the F12 developer tools and look at its Script tab:

The stack trace is dumped to the console in the catch clause, and because it’s at the top of the stack, it’s readily apparent that the Error is originating in the squareRoot function. To debug the problem, a developer wouldn’t have to go very deep into the stack trace; squareRoot’s precondition was violated, and looking one level up the stack, it’s clear why: the sub-expressions within the call to squareRoot should themselves be parameters to square.

While debugging, the stack property can help identify code for setting a breakpoint. Bear in mind that there are other ways to view the call stack: for instance, if you set the script debugger to “Break on caught exception” mode, you may be able to inspect the call stack with the debugger. For deployed applications, you may consider wrapping problematic code within try/catch in order to capture failed calls, and log them to your server. Developers would then be able to look at the call stack to help isolate problem areas.

DOM Exceptions and Error.stack

I noted previously that the object being thrown must be an Error or lead back to Error via its prototype chain. This is intentional; JavaScript supports throwing any object and even primitives as exceptions. While all of these can be caught and examined, they are not all specifically designed to contain error or diagnostic information. As a consequence, only Errors will be updated with a stack property when thrown.

Even though DOM Exceptions are objects, they don’t have prototype chains that lead back to Error, and therefore they don’t have a stack property. In scenarios in which you are performing DOM manipulation and want to surface JavaScript-compatible errors, you may want to wrap your DOM manipulation code within a try/catch block, and throw a new Error object within the catch clause:

function causesDomError() {

try {

var div = document.createElement('div');

div.appendChild(div);

} catch (e) {

throw new Error(e.toString());

}

}

However, you will probably want to consider whether you want to use this pattern. It is likely best-suited for utility library development; specifically, consider whether your code’s intent is to hide DOM manipulation, or to simply carry out a task. If it is hiding DOM manipulation, wrapping the manipulation and throwing an Error is probably the right way to go.

Performance Considerations

The construction of the stack trace begins when the error object is thrown; doing so requires walking the current execution stack. To prevent performance problems in traversing a particularly large stack (possibly even a recursive stack chain), by default, IE only collects the top 10 stack frames. This setting is configurable, however, by setting the static property Error.stackTraceLimit to another value. This setting is global, and must be changed prior to throwing the error, or else it will not have an effect on stack traces.

Asynchronous Exceptions

When a stack trace is generated from an asynchronous callback (for example, a timeout, interval, or XMLHttpRequest), the asynchronous callback, rather than the code that created the asynchronous callback, will be at the bottom of the call stack. This has some potential implications for tracking down offending code: if you use the same callback function for multiple asynchronous callbacks, you may find it difficult to determine by inspection alone which callback caused the error. Let’s slightly modify our previous sample so that, instead of calling sample() directly, we’ll put that into a timeout callback:

(function () {

'use strict';

function squareRoot(n) {

if (n < 0)

throw new Error('Cannot take square root of negative number.');

 

return Math.sqrt(n);

}

 

function square(n) {

return n * n;

}

 

function pointDistance(pt1, pt2) {

return squareRoot((pt1.x - pt2.x) + (pt1.y - pt2.y));

}

 

function sample() {

var pt1 = { x: 0, y: 2 };

var pt2 = { x: 12, y: 10 };

 

console.log('Distance is: ' + pointDistance(pt1, pt2));

}

 

setTimeout(function () {

try {

sample();

}

catch (e) {

console.log(e.stack);

}

}, 2500);

})();

Upon executing this snippet, you’ll see the stack trace come up after a slight delay. This time, you’ll also see that the bottom of the stack is not Global Code but rather is Anonymous function. In fact, it’s not the same anonymous function, but the callback function passed into setTimeout. Since you lose the context surrounding hooking up the callback, you may not be able to determine what is causing the callback to be called. If you consider a scenario in which one callback is registered to handle the click event of many different buttons, you will be unable to tell to which callback the registration refers to. That being said, this limitation is only minor, because, in most cases, the top of the stack will likely highlight the problem areas.

Exploring the Test Drive Demo

Check out this Test Drive demo using IE10 in the Windows 8 Consumer Preview. You can execute code in the context of an eval and if an error occurs, you’ll be able to inspect it. If you’re running the code within IE10, you’ll also be able to highlight the lines of your code as you hover over the error lines in the stack trace. You can type code into the Code area yourself, or select from several samples in the list. You can also set the Error.stackTraceLimit value when running the code samples.

For reference material, you may want to cruise over to the MSDN documentation for Error.stack as well as stackTraceLimit.

—Rob Paveza, Program Manager, Chakra Runtime

Building cross-browser plugin-free experiences

Thu, 26 Apr 2012 22:04:49 GMT

We've talked about how the transition to a plug-in free Web is happening today. Lots of Web browsing happens on devices that simply don’t support plug-ins. Web sites that use plug-ins need to understand what their customers experience when browsing plug-in free. In case you missed it, check out Rey Bango’s blog post where he lays out clear guidance for developers on building cross-browser plugin-free experiences and addressing issues like cross-browser CSS, media playback, and touch.

-- John Hrvatin, Program Manager Lead, Internet Explorer

Guidelines for Building Touch-friendly Sites

Fri, 20 Apr 2012 18:14:00 GMT

In Windows 8 Consumer Preview, IE10 enables fast and fluid multi-touch experiences on the Web. Most sites work fine with touch in IE10 with no changes to the site. This post provides four simple guidelines to ensure your customers who use touch can most effectively use your site.

We’ve written before about how new input devices and touch screens make the Web more fun, interactive, and immersive. We’ve also talked about the importance of ensuring a no compromise browsing experience in IE10 so the real Web works great with touch.

Of the four guidelines below, the first two make sure touch users can access all of your site’s functionality. The last two provide tips to make your site easier to use with touch.

DO NOT Hide Content Behind Hover

A mouse can hover content (point at it) without activating it (clicking it). However, with touch a tap is both hover and activation in one action. So functionality that requires hover without activating will not work for touch users. Instead, consider making all behaviors click (tap) based.

DO Configure the Browser for the Default Touch Behaviors That Work Well For Your Site

Users expect to be able to pan and zoom sites using touch. Therefore, the browser consumes touch moves, pinches, and double-taps by default and does not send events for these interactions. If your site needs to provide special functionality for these interactions instead, you must configure IE10 to provide only the default behavior you want, if any.

When a user touches an element, the -ms-touch-action CSS property determines the default behavior that IE10 provides.

The table below describes the five possible values.

Value	Description
auto	The browser determines the behavior for the element.  This is the default value for -ms-touch-action.
none	No default behavior is allowed.
manipulation	Only panning, pinch zoom, and swiping to navigate forward or back are allowed.
double-tap-zoom	Only double-tap zooming is allowed.
inherit	The element inherits the value of -ms-touch-action from its parent.

For example, a canvas painting application might use:

With this configuration, the user can double-tap to zoom in to the canvas element, but sliding a finger on the canvas element will send events to it rather than pan the page.

DO Identify Input Types Using HTML5 Forms

IE10 introduces support for HTML5 input controls, all of which are touch optimized. For text inputs, you can further improve your users’ touch experiences by identifying the specific input type, when applicable. Internet Explorer will show a tailored touch keyboard layout for that input type on Windows 8:

The touch keyboard shows @ and “.com” buttons for email addresses.

The touch keyboard shows a number pad for telephone numbers.

The touch keyboard shows forward slash and “.com” for URLs.

DO Provide Ample Room for Users’ Fingers

To build Windows 8’s touch-first experience, we’ve done a ton of research to formulate some helpful guidelines for developers. The average width of a finger is 11mm. As targets for tapping get larger, the percentage of accidental missed taps drops off quickly.

Ideally, a target is at least 11mm (about 40px) square with at least 2mm (about 10px) of padding around it.

			40px or more target size
10px or more between targets

If you want to adjust the spacing only for users with touch hardware, use feature detection.

To detect that user has touch hardware:

Going Beyond These Basics

You can do much more to create a great touch-first experience. For example, you may choose to optimize for touch by supporting custom multi-touch interactions or gestures. Here are a few links to get you started:

• IE 10 Developer Guide
• Touch Zooming & Panning
• Pointer & Gesture Events
• Touch Input for IE10 and Metro style Apps
• Handling Multi-touch and Mouse Input in All Browsers

We plan to write more about these methods in future blog posts. Applying these guidelines today will ensure your sites work well with touch in IE10.

— Jacob Rossi, Program Manager, Internet Explorer