- We assume that you're familiar with the structure of a basic app as described in Coding basic apps.
- Enhanced support for touch.
- More control over the look and feel of your UI.
- Access to the Windows Runtime.
The Windows Runtime is a set of APIs developed for Windows Runtime apps that provide networking functionality, better XML parsing, access to the system and devices, and more. For a complete list of what the Windows Runtime provides, see the Windows Runtime reference.
- Controls such as DatePicker, TimePicker, and ListView, a data control that can be highly customized and can bind to different types of data, including XML and web services. These controls are a part of the WinJS (WinJS).
For a complete list, see the Controls list.
- Access to the WinJS.
Windows Runtime provides provides APIs that give you deeper access to the system. You can write your own custom objects for your project in C#, VB, and C++, which you include as a code library in your project.
One of the simplest and most commonly used forms of navigation is the hyperlink. The code here creates a hyperlink that navigates to page2.html.
Because it's a relative link, the system assumes that page2.html is a local page that's part of your app. Clicking the link takes you to page2.html. Local pages, such as page2.html, run the local context.
The next example adds a link to an external website, www.bing.com:
<p><a href="ms-appx:///page2.html">Go to page 2</a></p> <p><a href="http://www.bing.com">Search the web</a></p>
When you click the second link, something interesting happens—the link opens in the web browser rather than inside your application, unlike the first link which opened inside the application.
ms-appx-web:///), see How to reference content.
You can use the ApplicationContentUriRules section of the app's package manifest to give a page in the web context access to your system's geolocation devices (if your app has permission to access this functionality), as well as access to the clipboard.
Although they have access to more of the system than other external pages, web context pages don't have as much access as local context pages. For example, a page in the web context can't access the Windows Runtime, but a page in the local context can. For more info about the differences between local and web contexts, see Features and restrictions by context.
A page in your app's local context has more access to the system than other Web pages (or "Web-context pages") do. It can access the Windows Runtime and, depending on the app's permissions, might be able to access the file system and your devices. For this reason, it's important to prevent potentially malicious code from executing.
To guard against script injections and help shield your system from potentially malicious code, HTML you inject into a page in the local context is filtered as though it was processed by the toStaticHTML method. Injecting HTML that contains an unknown element, event handler, script or reference to script, or unknown CSS pseudo-element and pseudo-class causes an exception when you try to add the HTML to the page's DOM.
This security restriction affects these properties and methods:
- innerHTML and outerHTML
- document.write and document.writeln
You can bypass this security restriction, but do so only with trusted content that doesn't contain any remote web content outside of your control. To bypass safe HTML filtering, you use one of these functions:
Explicitly creates new elements that you can add to the DOM. Because you create each element explicitly, the safe HTML filter isn't applied to them. We assume that you're in complete control of what you're adding and so there's no risk of accidently including malicious code.
Disables the safe HTML filtering for the specified function. You can create a function that inserts content that would normally be blocked and use MSApp.execUnsafeLocalFunction to execute that function.
Writes the specified HTML without using safe HTML filtering. (These functions are a part of the WinJS.)
Because they have limited access to the system, pages in the web context are not subject to these restrictions: properties and functions such as innerHTML and pasteHTML don't check for potentially malicious code.