Adapting tailored sites to support standards

Many websites provide tailored experiences to devices running iOS or Android operating systems. With a few key changes, these experiences can be offered to browsers and devices that support industry standards. This allows these experiences to reach many more users with minimal effort. For example, a website viewed in Internet Explorer for Windows Phone 8.1 Update provides a similar experience when viewed on a Windows laptop, an Xbox console, a Surface tablet, and so on. By creating sites that support industry standards (such as HTML5, CSS3, DOM4, and so on), you extend your site's reach to include browsers that support the same standards, regardless of the underlying device, operating system, or form factor.

The following tips samples help adapt tailored sites to more broadly support industry standards. This guidance was developed through real world experience gained while helping partners adapt popular sites. In many cases, the actual code changes to your site are minimal, depending on the features used on your site and the practices you're already following. So go ahead and make your best content available on as many browsers as possible.

For specific advice regarding your tailored site, consider using the common coding problem scanner located at modern.IE.

• Step 1: Update or replace browser detection
• Step 2: Ensure standards mode for all browsers
• Step 3: Update CSS and DOM prefix use.
  • Revising prefixed properties
  • Prefixed properties
  • Gradients
  • Flexbox orientation
  • Borders around hyperlinked images
• Step 4: Update touch and pointer event handlers
  • Adding pointer event listeners
  • Retrieving coordinates
  • Handling mouse and other input types
  • Turning off default touch behavior
• Step 5: Handle non-standard behaviors
  • Disabling link highlighting
  • Disabling native styling for drop-down lists

Step 1: Update or replace browser detection

If your site uses browser detection, you should carefully review the need for browser detection as well as the underlying code. Consider reworking the code to focus on features and capabilities rather than specific browsers, devices, or operating systems. For example, media queries provide a convenient way to support different screen resolutions without excluding any particular browser.

If, for some reason, it seems necessary to continue using browser detection, either on the client or server-side, you should review the implementation and verify that it fully supports current versions of the major browsers. For example, Internet Explorer's user agent string has changed dramatically in the last few versions. Code designed to detect older versions of the browser may incorrectly exclude versions of the browser that are otherwise fully capable of supporting the your existing design. To learn more, see:

• User-agent string changes
• How to Detect Features Instead of Browsers
• Update existing code to work across browsers

In the long run, it's important to adopt feature detection and other modern practices for writing cross-browser code rather than to continue to rely on user-agent detection. As an example, it's very important to ensure that Internet Explorer on Windows Phone 8 is served HTML5 video rather than Flash-based video. By changing your implementation to detect support for HTML5 video, you also ensure your site works on other devices that do not support Flash. Other examples include:

• If you use third-party libraries, such as jQuery Mobile, you'll need to verify that you're using the latest version available.
• If you also use Typekit, you'll want to republish your custom font kit.
• If you use Ooyala for video, you'll need to update to their latest player.

Step 2: Ensure standards mode for all browsers

Next, verify that your site relies on standards mode so that browsers apply the latest and greatest features available to your designs. Using standards mode provides the greatest support for the latest standards, such as HTML5, Cascading Style Sheets, Level 3 (CSS3), Scalable Vector Graphics (SVG), and others, as opposed to some of the older modes such as "quirks mode" which are supported for backward compatibility. For most sites, this won't require any work because standards mode is the default. The easiest way to be sure is to include the HTML5 doctype at the top of every page:

<!DOCTYPE html> 

Standards mode also is the default for webpages using HTML 4.0 or XHTML document type directives (or doctypes) that do not specify "Transitional".

If you're testing your web pages on a local network (or "localhost"), you will need to temporarily force standards mode because IE defaults into a backward-compatible mode for intranet sites. You can do this by adding the following tag to the <head> tag of the page, or by adding the equivalent HTTP header:

<meta http-equiv="x-ua-compatible" content="IE=edge" />

Once the site has been deployed to an internet domain, you can remove the meta element because it will no longer be needed.

Some examples of scenarios to avoid that would push your site out of standards mode are:

• Not including a doctype declaration at all. Instead, use the HTML5 doctype mentioned above.

• Specifying a "transitional" doctype. Instead, remove the Transitional keyword or adopt the HTML5 doctype.

• Forcing a specific IE mode using the x-ua-compatible header with "IE=9" (or older version). Instead, specify IE=edge or remove the x-ua-compatible header completely and use the HTML5 doctype.

To learn more, see Update your site to web standards and Defining document compatibility.

Step 3: Update CSS and DOM prefix use.

Now you're ready to check for code updates. Look for any Cascading Style Sheets (CSS) or JavaScript calls tailored to specific toolkits, like Webkit, and see if there are standards-compliant alternatives. In rare cases, you may need to use vendor prefixes (-ms) to support specific browsers. Your site may already include a broad set of prefixes as a best practice. Beyond that, there may be a few other CSS updates or behavior differences that require minor changes.

Revising prefixed properties

The first set of properties we'll look at are unprefixed properties. These are CSS/Document Object Model (DOM)Document Object Model (DOM) properties that initially shipped under the WebKit prefix (for example, with "-webkit") but have since shipped in IE and other browsers in an unprefixed format. Fixing these can be as simple as copying the line and then removing the "-webkit" prefix from the copy. Doing so helps support browsers which don't use WebKit.

Note that this applies to CSS properties as well as the equivalent JavaScript calls. For example:

Instead of just:

-webkit-border-radius: 0;

Use:

-webkit-border-radius: 0; 
border-radius: 0; 

Instead of:

a.webkitTransitionDuration = "5ms" 

Use:

b.webkitTransitionDuration = 
   b.transitionDuration = "5ms"; 

Instead of just:

this.element.addEventListener 
   ("webkitTransitionEnd", this, false); 

Use:

this.element.addEventListener 
   ("webkitTransitionEnd", this, false); 

this.element.addEventListener
   ("transitionend", this, false); 

Here are some common WebKit properties and their standard (unprefixed) counterparts. Each has an equivalent style property that can be accessed via JavaScript. For example, borderRadius in CSS can also be accessed as object.style.borderRadius.

Other properties, such as CSS Multi-Column Layout, also are supported without vendor prefixes..

Prefixed properties

The following WebKit-prefixed properties also have the same behavior in IE but require Microsoft vendor-prefixing ("-ms") because the corresponding standards have not progressed far enough at the World Wide Web Consortium (W3C) to be considered standardized. (You can learn more about the Microsoft approach to this process.) Note that while you are adding the "-ms" version, you can also choose to add an unprefixed version to be forward compatible. (See How to create effective fallback strategies to learn more.)

Gradients

The CSS gradients syntax has been updated during the standardization process. Specifically, the gradient type (for example, linear or radial) has moved to the property name, and there also are differences in how you specify the gradient line and colors. For the full details on the IE supported syntax for gradients, see IE10 Developers Guide: Gradients. For example:

Before:

background: -webkit-gradient(linear, left top, 
   left bottom, from(#ffffff), to(#000000)); 

After:

background: -webkit-gradient(linear, left top, 
   left bottom, from(#ffffff), to(#000000));

background: linear-gradient(to bottom, 
   #ffffff, #000000); 

Flexbox orientation

The syntax for setting Flexbox orientation has changed in IE:

Before:

-webkit-box-orient: vertical; 

After:

-webkit-box-orient: vertical;
flex-direction: column;   

Borders around hyperlinked images

If an image is used as a hyperlink, by default IE draws a blue highlight around the image to emphasize that this is a hyperlink; WebKit doesn't do this. An easy way to turn this off is to explicitly specify no border for hyperlinked images using the following CSS:

a img {
      border: none;
 } 

Step 4: Update touch and pointer event handlers

Internet Explorer for Windows Phone 8.1 Update now supports the Touch events API for handling touch. For many sites tailored for iOS or Android devices, this means it is no longer necessary to make changes to support Windows Phone devices. However, the Touch events API does not properly handle support for some other touch-enabled devices like laptops or hybrid devices.

To fully support devices running Windows, sites should incorporate the Pointer Events standard so that touch, mouse, and pen input are all supported through a single event model. In certain scenarios, the Pointer Events standard provides better performance when compared to designs based on the Touch events API.

Adding pointer event listeners

The pointer API uses a standard "down, move, up" event model. Therefore, it's simple to hook up listeners for existing event handlers to pointer events.

Before:

this.element.addEventListener("touchstart", eventHandlerName, false); 
 this.element.addEventListener("touchmove", eventHandlerName, false);
 this.element.addEventListener("touchend", eventHandlerName, false); 

After:

if (window.PointerEvent) {
   this.element.addEventListener("pointerdown", eventHandlerName, false);
   this.element.addEventListener("pointermove", eventHandlerName, false);
   this.element.addEventListener("pointerup", eventHandlerName, false);
   this.element.addEventListener("pointercancel", eventHandlerName, false);
} else {
   this.element.addEventListener("touchstart", eventHandlerName, false);
   this.element.addEventListener("touchmove", eventHandlerName, false);
   this.element.addEventListener("touchend", eventHandlerName, false);  
   this.element.addEventListener("touchend", eventHandlerName, false);  

   //Consider also, support mouse on multi-modal devices
   this.element.addEventListener("mousedown", eventHandlerName, false);
   this.element.addEventListener("mousemove", eventHandlerName, false);
   this.element.addEventListener("mouseup", eventHandlerName, false);
}

Retrieving coordinates

The pointer event model fires separate events for each touch point, so there is no need to retrieve a specific index from the touches collection. The coordinates are exposed directly from the event object using the pageX and pageY properties. This can easily be incorporated into existing code as follows:

Before:

var curX = event.targetTouches[0].pageX; 

After:

var curX = event.pageX || event.targetTouches[0].pageX;  

Handling mouse and other input types

Pointer events let you handle mouse input with the same events that handle touch input. You can use the same code to handle common scenarios such as tap, click, and drag.

To differentiate between different input types, use the pointerType property:

switch (event.pointerType) {
  case "touch":
    //Handle input only if from a touchscreen
    break;
  
  case "mouse":
    //Handle input only if from a mouse
    break;
  
  case "pen":
    //Handle input only if from a pen stylus
    break;
  
  default:
    //Handle all other input types
}

Turning off default touch behavior

With Touch Events, disabling default touch behavior (like panning or zooming) is done by cancelling the event. With Pointer Events, disabling the default touch behavior is done declaratively via the touch-action CSS property.

Before:

touchEvent.prevent.default(); // Prevent panning/zooming on the element touched  

After:

.preventTouchBehaviors {
  touch-action: none; /* Prevent panning/zooming on elements with this class */
}
  

In addition to "none", IE on Windows Phone 8 also supports the "pan-x" and "pan-y" property values, which specify that the browser should handle horizontal or vertical gestures, and custom JavaScript handlers should handle everything else.

Tip  The HandJS polyfill may help add pointer event support to browsers that do not currently support the API.

The steps in this article help you adapt tailored sites so they also support industry standards. In turn, this helps your rich experiences reach and delight users regardless of their browser, device, or operating system.

Step 5: Handle non-standard behaviors

A final category of updates is related to scenarios that don't have an associated W3C standard. In most cases you can combine solutions safely. For example, you can specify the standards-based approach first and then fallback to a non-standard approach when needed.

Disabling link highlighting

Some mobile browsers, including Safari on iOS and IE on Windows Phone, display a translucent highlight when elements with hyperlinks are tapped, to provide additional feedback to the user. However, many sites want to disable this default behavior to have greater control over the look and feel of their site.

Webkit solution:

 a {
 -webkit-tap-highlight-color: rgba(0,0,0,0);
 } 

IE solution:

<meta name="msapplication-tap-highlight" content="no" /> 

Note that msapplication-tap-highlight should appear in the head section of the page (it applies to the entire page).

Disabling native styling for drop-down lists

The -webkit-appearance CSS property defines WebKit-specific behaviors to change the appearance of controls to resemble native controls. In many cases, this is the default behavior in IE and therefore isn't required.

However, one specific, commonly used scenario for "-webkit-appearance" is to disable the drop-down arrow that appears on select elements in order to apply a custom style (generally a background image). When the arrow is removed, the textIndent value usually is set to ensure that the text of the drop-down list items doesn't show up on the page. (However, it will show up in the control that pops up when it is tapped). Here's how to achieve the same effect in IE:

Webkit solution:

 select {
    -webkit-appearance: none;
    text-indent: -5000px;
 }  

IE solution:

select::-ms-expand {
    display: none;
 } 

<!-- Empty option removes text -->
<select>
 <option></option>
 ...
 </select> 

When you adapt tailored sites to support industry standards, your rich experiences will reach to users regardless of their browser, device, or underlying operating system.