Dela via

HTML, CSS, and JavaScript features and differences (HTML)

  • Artikel

[ This article is for Windows 8.x and Windows Phone 8.x developers writing Windows Runtime apps. If you’re developing for Windows 10, see the latest documentation ]

The Windows Runtime apps using JavaScript platform allows you to build apps with HTML, CSS, and JavaScript. While a lot of Windows Runtime app using JavaScript programming is identical to writing markup and code for a website, Windows Runtime apps using JavaScript provide additional features, and introduces some differences to how you use existing HTML features. Here we look at those differences.

Prerequisites

HTML support

Windows Runtime apps using JavaScript support most HTML5 features, such as the canvas, SVG, video, and audio elements. They also support most Cascading Style Sheets, Level 3 (CSS3) features, such as 2D transforms, 3D transforms, transitions, and animations.

In general, writing HTML for a Windows Runtime app using JavaScript is a lot like writing HTML for Internet Explorer 11 running in standards mode. There are a few differences, though: the next sections describe how Windows Runtime apps using JavaScript provide some powerful new features, and how some existing HTML and DOM APIs work differently.

Additional features

Windows Runtime apps using JavaScript provide many new features you can use to enhance your apps:

  • Enhanced support for touch.

  • More control over the look and feel of your UI.

    Windows Runtime apps using JavaScript provide additional stylable components, called parts, to many existing HTML controls and all the new Windows Library for JavaScript controls. These parts give you more flexibility over the look and feel of your controls. For more info about control styling, see Quickstart: Styling controls.

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

    You can also use the Windows Runtime to write your own custom libraries in C#, Visual Basic, or C++. You can then access those libraries through JavaScript in your Windows Runtime app using JavaScript.

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

    The WinJS is a set of JavaScript and CSS files that make it easier to create Windows Runtime apps using JavaScript. You use it together with HTML, CSS, and the Windows Runtime to create your app.

Windows Runtime objects

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.

Differences

In general, HTML and DOM APIs function as they would inside Windows Internet Explorer in standard mode. But there are some differences. Some of these differences are the result of running inside the Windows shell, which controls what types of windows you can open. Other differences are the result of the Windows app using JavaScript's security model.

Creating and manipulating windows

Windows: Creating and manipulating windows:

In the Windows shell, the active app occupies a single window that fills most of the screen. You can't create new windows, and you can't resize or move existing windows.

Working with the window object

Some methods of the window object such as alert, prompt, open, moveBy, moveTo, resizeBy, and resizeTo don't work in Windows Runtime apps using JavaScript. A page running in the local context can use window.close to quit the app, but should only use it in the case of an unrecoverable error. Pages running in the web context can't use window.close.

Basic navigation

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.

<p><a href="page2.html">Go to page 2</a></p>

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="https://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.

That's because Windows Runtime apps using JavaScript won't perform a top-level navigation to an external page. They can only display external web pages in an WebView control or iframe. For more info, see How to link to external web pages. For more info about the different protocols you can use for linking (such as ms-appx:/// and ms-appx-web:///), see How to reference content.

Local and web context pages

To understand some of the differences between how your markup and code behave in the browser and how they behave in a Windows Runtime app using JavaScript, you need to first understand the difference between the local context and the web context.

A Windows Runtime app using JavaScript contains at least one HTML page. That page, and any other pages you include in the app itself, generally run in the app's local context. When you use an iframe to navigate to a remote page, that page runs in the web context and has limited access to your system.

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.

Nearly every website provides some form of navigation, usually in the form of hyperlinks that you click to go to a different page. Each page has its own set of JavaScript functions and data, a new set of HTML to display, style info, and so on. This navigation model is known as multi-page navigation.

Another navigation model is single-page navigation, where you use a single page for your app and load additional data into that page as needed. You still split your app into multiple files, but instead of moving from page to page, your app loads other documents (using Page or HtmlControl objects) into the main page. Because your app's main page is never unloaded, your scripts are never unloaded, which makes it easier to manage activation, state, and animations. When users run your app, they experience a smooth, application-like experience that doesn't have to pause to load new pages and doesn't ever display blank screens. We recommend that Windows apps using JavaScript use the single-page navigation model.

Asynchronous functions

To provide responsive user experience, many WinJS and Windows Runtime functions execute asynchronously. That way your app can continue to respond to user interactions while performing work in the background. Instead of directly returning a value, an asynchronous function returns a Promise for a value. For more info about asynchronous programming, see Asynchronous programming in JavaScript.

Dynamically adding HTML

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:

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:

  • createElement

    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.

  • MSApp.execUnsafeLocalFunction

    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.

    var someElement = document.getElementById('someElementID');
MSApp.execUnsafeLocalFunction(
    function() { someElement.innerHTML = '<div onclick="console.log(\"hi\");">hi</div>' }
);

  • WinJS.Utilities.setInnerHTMLUnsafe, WinJS.Utilities.setOuterHTMLUnsafe

    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.

DOM events

For the most part, DOM events function the same for Windows Runtime apps using JavaScript as they do in a web browser, but there are a few differences. For a list of events that work differently, see the HTML and DOM API changes list.

ActiveX controls

Windows Runtime apps using JavaScript don't support custom ActiveX controls. If you need a UI control, use an HTML control, a WinJS control, or create your own custom WinJS control. If you need to perform custom logic, create a custom Windows Runtime object instead.

Encoding

All HTML, JavaScript, and CSS accessed by a Windows Runtime app using JavaScript must be encoded as UTF-8.

Bytecode caching

When an Windows Runtime app using JavaScript is executed outside of the Microsoft Visual Studio debugging environment, a number of performance optimizations occur. One important optimization is that all JavaScript files (files with a .js extension) included in the app package are converted into bytecode that the JavaScript engine can consume directly. Your app can load and execute the code in these files faster than it can load and execute unprocessed files, such as a JavaScript file on the web. This bytecode and a copy of the source code itself are stored in a single bytecode cache file with the package files. After the bytecode conversion completes, modifying the original source files has no effect on the app’s behavior until the app is re-deployed.

Using jQuery

You can use jQuery in your Windows Runtime app using JavaScript, but only versions 2.0 and later. We recommend always using the latest version.

HTML and DOM API changes list