Nothing Special   »   [go: up one dir, main page]

Today’s Chrome Beta channel release includes a slew of new developer features to help you make richer, faster and more compelling web content and apps, especially for mobile devices. Unless otherwise noted, changes described below apply to Chrome for Android, Windows, Mac, Linux, and Chrome OS.

DirectWrite on Windows

Chrome 37 adds support for DirectWrite, an API on Windows for clear, high-quality text rendering even on high DPI displays. Before DirectWrite, Chrome used the Graphics Device Interface (GDI) to render text. GDI dates back to the mid-80's and reflects the engineering tradeoffs of that time, particularly for slower, lower-resolution machines. The switch to DirectWrite has been a top user request for years, and required extensive re-architecting and streamlining of Chrome's font rendering engine.

Some users should begin seeing better-looking fonts and increased rendering performance as we roll out DirectWrite, with no changes required by web developers. Assuming everything goes smoothly, all users will experience the improvements by the Chrome 37 stable release.

Compare the below screenshots, taken with and without DirectWrite enabled.



New HTML element: <dialog>

In this release we're also adding support for the <dialog> HTML5 element, which enables developers to create styled dialog boxes in their web applications and control them via a JavaScript API. For more details, check out some code samples and see <dialog> in action. The <dialog> element is a better-designed alternative to showModalDialog(), which is now disabled as we recently announced.

Other updates in this release

  • The Web Cryptography JavaScript API is enabled by default starting in Chrome 37, allowing developers to perform cryptographic operations such as hashing, signature generation/verification, and encryption.
  • Subpixel font scaling is now supported, which enables smooth animations of text between font sizes.  
  • TouchEvent co-ordinates are now doubles instead of longs, enabling higher-fidelity touch interactions on high-DPI displays.
  • CSS cursor values "zoom-in" and "zoom-out" are now unprefixed.
  • The number of cores on a physical machine can now be accessed by navigator.hardwareConcurrency.
  • The user's preferred languages are now accessible by navigator.languages, and the languagechange event is fired when this is updated.
  • The CSS Shapes Module allows developers to define non-rectangular text wrapping boundaries around floated elements.
  • NPAPI deprecation continues according to our previously-announced plan with a harder-to-bypass blocking UI
  • The default monospace font on Windows is now Consolas instead of Courier New.
  • Cross-origin fonts are now blocked unless the response includes the appropriate CORS headers.
As always, visit chromestatus.com/features for a complete overview of Chrome’s developer features,  and circle +Google Chrome Developers for more frequent updates!

Posted by Emil A Eklund, Software Engineer and Senior Blog DirectWriter



The web platform has evolved organically over the past two decades, slowly growing new capabilities and APIs. Many features that are added are great ideas that enable web developers to make even better applications. But some APIs turn out, in retrospect, to be mistakes. Over time, the platform accretes more bad APIs, which makes it harder to add new browser features, confuses web developers, and even introduces security bugs. showModalDialog is a bad API that we deprecated earlier this year, and in Chrome 37 we will disable support for it by default.

showModalDialog was first introduced in Internet Explorer 4 and although it was never formally standardized, over time most other browsers added support for it. It allows applications to show a dialog of HTML content that freezes all other content while showing. showModalDialog is not a commonly used API: based on our usage counters, less than 0.006% of pages use it.

Unfortunately, showModalDialog's unique ability to freeze content is now widely regarded as a mis-feature in terms of user experience, code complexity, and security. From a usability perspective, showModalDialog rudely demands that you interact with it by freezing all of your other tabs—even ones from other sites. showModalDialog also requires complex and hard-to-maintain code scattered throughout the codebase. This complexity complicates the behavior of new web features like Mutation Observers, Object.observe, and Promises. It also makes showModalDialog a source of a disproportionate number of bugs, including serious security vulnerabilities. It is for these reasons that we decided to turn off showModalDialog by default in the next version of Chrome.

Although very few sites use showModalDialog, the small minority that do—disproportionately enterprise sites—have come to rely heavily on it. In order to give these sites more time to update, we have added a temporary Enterprise Policy setting to re-enable showModalDialog. In May 2015 this setting will be removed and showModalDialog will be completely removed from Chromium. Affected sites should begin work to update their sites as soon as possible.

Although it can be difficult, sometimes the only way to go forward is to leave the past behind. Removing bad APIs will help us make the web a more consistent and capable platform for both developers and users.

Posted by Adam Barth, Software Engineer