Microsoft News

The bad guys didn’t take a holiday vacation: Internet Explorer’s SmartScreen service blocked nearly 2 million malware downloads per day on average from mid-December through New Year’s. December 25 saw a 30% spike in malware blocks— successfully preventing users from being tricked into giving their PCs an unwanted “present.”

January is a great time to resolve to stay safer online. Microsoft works around the clock, year-round, to help. By following a few simple best practices, including opting into Automatic Updates and Internet Explorer’s SmartScreen Filter, you can help keep your computer secure on the Web.

New PC owners will be happy to hear that Windows 7 users are 5 times less likely to be infected with malware than users running Windows XP. To improve your defenses even more, Windows 7 and Windows Vista users should be sure to upgrade to IE9, our safest and most secure browser. Later this month, we’ll help keep more customers safe by beginning simpler, seamless automatic upgrade process for customers who aren’t running the latest, most secure versions of IE for their operating system. Of course, no matter what OS and browser you use, you should ensure that you install updates as they become available – including updates for browser extensions, a common source of vulnerability. If you got a new phone or tablet over the holiday, be extra careful where you get your apps—the bad guys have noted these fresh new targets and are reacting accordingly.

This month marks the tenth anniversary of Bill Gates’ Trustworthy Computing memo, and delivering trustworthy browsing is more important than ever, as the ecosystem grows to encompass phones, tablets, and other form factors and the bad guys attempt even more clever attacks. We’re excited to be working with the rest of the Windows team on cutting-edge security improvements in IE10 and Windows 8, and we’ll be describing our new defenses in a series of posts over the next two months.

—Eric Lawrence, IE Security

Today we introduce seven new language versions of IEBlog—French, German, Portuguese (Brazil), Korean, Japanese, Chinese (PRC), and Russian. Links to these appear in the new “Languages” block at the top of the right column. We plan to publish translated versions five to ten days after their appearance on the English language IEBlog.

We’ve worked hard to localize most of the language elements on the page and in the posts themselves. Text within images will remain in English though we translate captions and image alt text. Markup and code samples will also remain in English. Occasionally, we’ll mistakenly translate an HTML, CSS, or JavaScript keyword; please forgive us. The links along the top and bottom of the page which link to English-language pages remain in English.

One of the more fun programming tasks in localizing IEBlog was to correctly translate and reformat the dates and times of the posts and comments. We decided to go one step further and translate the time (which was previously always displayed in US Pacific Time) to the time zone of the viewer. We also made this change to the English language version.

If you’re a speaker of one of these languages, we hope you’ll enjoy the new versions of IEBlog.

—Marcia Coelho da Costa, Senior International Project Manager,
 Joe Oswald, Principal International Project Manager Lead, and
 Ted Johnson, Production Engineer for IEBlog

IE10 Platform Preview 4 includes support for a new CSS property, -ms-user-select, which makes it easier for Web developers to control exactly what text can be selected on their Web sites. If you were to watch me all day at my workstation, you would notice that as I read on the computer, I select text. I’m not the only one who reads like this; selecting text on the Internet is important in many other scenarios.

Consider a typical news Web site. Most pages will include a news article, the contents of which the user needs to be able to select because they read by selecting text or because they want to share the content. Also on the news Web page there are some menus and links to other parts of the site. Users likely don’t need to select these items. Using -ms-user-select, the Web developer can specify that text selection is allowed in the news article but not allowed in the menus.

The IE Test Drive site includes an example that does this.

Setting -ms-user-select:none on the entire page and then setting -ms-user-select:element on the element containing the blog post allows only the contents of the blog post to be selected. -ms-user-select:element is a new property first introduced by IE which we think could be useful in many situations. Setting -ms-user-select:element means that the user can select the text of that element, however, the selection will be constrained to the bounds of the element. People who want to select the contents of a news article probably don’t want to select the footer elements just past the article. Setting -ms-user-select:element makes it easy for users to just select the contents of the article without having to worry about getting the mouse placement exactly correct.

-ms-user-select accepts four values:

• text – the text is selectable
• element – the text is selectable, constrained to the bounds of the element
• none – the text is not selectable
• auto – if the element contains editable text such as an input element or contenteditable element, the text is selectable. Otherwise selection is determined by the parent node’s value.

auto is the default value for -ms-user-select.

A developer can turn off text selection by setting -ms-user-select to none. In IE, when text is set to -ms-user-select:none, the user will not be able to start a selection within that block of text. However, if the user started selecting text on a different area of the page, the selection would continue into any area of the page including areas where -ms-user-select is none. In Firefox, if the developer sets –moz-user-select:none then selections can’t start in that area and also can’t be included in any other selection. In Webkit, setting –webkit-user-select:none will make it appear as if that the text is not included in the selection, however if you copy and paste the content, you will see that the content is included in the selection.

user-select was originally proposed in the User Interface for CSS3 module; this module has since been superseded by CSS3 Basic User Interface Module, yet it does not define the property. Both Mozilla and Webkit support their own prefixed versions of this property. However, as discussed above, there are some differences in the implementations.

Play around with the examples on the IE Test Drive site and let us know what you think.

—Sharon Newman, Program Manager, Internet Explorer

With cross-browser support for both the CSS3 @font-face rule and the WOFF font packaging format, modern Web typography has expanded far beyond the realm of ‘Web-safe fonts.’ Well-known magazines such as the New Yorker use Web fonts to preserve the typographic personality of their headlines, while [US] President Obama’s re-election campaign uses Web font service Typekit to host their identity font.

One remaining limitation prevents Web designers from using the entire font: the inability to access the large variety of optional OpenType® features built into many fonts. These features define glyph substitution and positioning options to support fundamental typographical features such as kerning, superscript and subscript, contextual letterforms such as ligatures, numeral styles, access to alternate East Asian glyphs as well as ornamental swashes.

For instance, an OpenType “stylistic set” built into Gabriola allows this text:

…to render as:

Recent updates to the CSS3 Fonts module include a new set of properties to expose these OpenType features within CSS. These properties can be grouped in two broad categories:

• An explicit mapping of the common OpenType features to specific properties and values. For example font-kerning:normal applies the kerning pair adjustments encoded within the font and font-variant-numeric: tabular-nums enables tabular numerals.
• The font-feature-settings property enables low-level access to all the OpenType features supported by a font. It is meant as an ‘escape hatch’ to access to more advanced features in less common use-cases.

CSS Property: font-feature-settings

Preview 4 of IE10 includes support for the font-feature-settings property. Our earlier Gabriola example could thus be written:

p#demo {

font-family: Gabriola, cursive;

font-size: 24pt;

-ms-font-feature-settings: "ss06" 1;

}

The -ms-font-feature-settings declaration above turns on a stylistic set supported by the font (ss06). The property takes either a value of ‘normal’ – no change in glyph selection or positioning – or a comma-separated list of one or more features. Each feature combines a four-letter OpenType feature tag and a value. In the example above, “ss06” is the OpenType feature tag for stylistic set 6. We assign the value 1 to the feature to turn it on.

The OpenType feature registry defines the list of possible tags (also documented here and standardized by ISO). Here a few of the most popular:

OpenType tag	Enables
kern	Kerning
liga	Standard ligatures
dlig	Discretionary ligatures
smcp	Small capitals
subs	Subscript
sups	Superscript
swsh	Swashes
ss01, ss02, …, ss20	Stylistic sets 1 to 20

For a good illustrated introduction to these features and many others, we recommend the Layout Features section of the FontFont OpenType User Guide.

The more common features are on/off switches. Feature values of off or zero turn the feature off; a value of on or any positive integer activates it. For some features, an integer value gives access to several options. This is usually the case for swashes (‘swsh’). If no value is specified for the feature, a value of 1 is assumed. All the following declarations are thus equivalent for the purpose of our Gabriola example:

-ms-font-feature-settings: "ss06" 1;

-ms-font-feature-settings: "ss06" on;

-ms-font-feature-settings: "ss06";

Finding Out Supported Features for a Font

Design tools such as Adobe InDesign or Illustrator expose OpenType features through user-friendly menus and dialogs, word processors such as Word support them through their font selection dialog and font vendors often document which features their products support. A future post will discuss using the browser to detect font features. With more browser access to OpenType features we expect font hosting services to do more to advertise and document their use as well.

Browser Support

The font-feature-settings property is currently supported by Firefox 4+ and Internet Explorer 10, beginning with Preview 4. Note that because Firefox and IE implemented different versions of the draft the value syntax they accept is different. For example, enabling kerning in both browsers requires the following:

-ms-font-feature-settings: "kern" 1;

-moz-font-feature-setting: "kern=1";

More information about –moz-font-feature-settings see -moz-font-feature-settings.

As CSS3 Fonts moves along the standardization track we expect more browsers to add support for font-feature-setttings as well as the more author-friendly font-variant properties and values defined in the module.

Also note that the property applies to all font families, whether Web fonts downloaded through @font-face rules or local fonts referenced by name.

Demos

Our IE Test Drive site includes advanced OpenType feature demos from Monotype Imaging, FontFont and The Font Bureau. They demonstrate the variety of typographic designs available in modern fonts.

You don’t need any special fonts to try this. Windows 7 includes a number of OpenType-enabled fonts including Calibri, Cambria, Consolas, Gabriola, and Palatino Linotype. In the Windows 8 Developer Preview, we added OpenType features to Segoe UI and the Web-safe fonts Arial, Verdana, Georgia, Times New Roman, Comic Sans and Trebuchet.

We are excited to give Web authors access to all the OpenType features built in Web fonts and look forward to an even broader range of typographic design on the Web.

—Sylvain Galineau, Program Manager, Internet Explorer

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.

—Rob Mauceri, Group Program Manager, Internet Explorer

Today we introduce an updated look and layout for the IEBlog. Here’s an overview of the design and layout changes we made:

• New font family – We’re using the Segoe UI font to align with Windows 8 Metro style.
• New color scheme – We have a new color scheme inspired by the Windows 8 Metro style Start screen.
• Improved performance – The blog’s home page defaults to excerpt view. This substantially reduces load time since excerpts do not contain images or videos.
• Fewer borders – We’ve removed the borders around the right rail items resulting in a cleaner look.
• Updated right rail content – We’ve removed the tag cloud and limited the monthly archive list to 24 months. The links section has been updated somewhat and we’ve added the Microsoft Translator machine-translation widget for visitors who may wish to read our blog in languages other than English.

We hope you like the new style as much as we do.

—Ted Johnson for IEBlog

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 how browsers should behave 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 <canvas>, <audio>, and <video> remain available. Most importantly this aligns IE10's quirks mode with the behavior of other browsers, so pages missing a DOCTYPE run consistently across implementations.

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.

<meta http-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 <!DOCTYPE html> at the top of your pages. Please help ensure IE10's HTML5 quirks mode works correctly by reporting issues via Connect.

—Tony Ross, Program Manager, Internet Explorer

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.

—Ceri Gallacher, Program Manager, Internet Explorer

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 prototype allows 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 <audio> or <video> element.

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.

—Claudio Caldato, Principal Program Manager, Interoperability Strategy Team

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.

Use CSS3, not DX Filters

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

—Ted Johnson, Lead Program Manager, Internet Explorer Graphics