Web Platform Tidbits #2

I should think of a better name for these posts.

DirectWrite coming to Chrome

One of the most longstanding complaints about Chrome on Windows is the poor quality with which it renders some fonts in comparison with Internet Explorer and Firefox. The reason is that the latter browsers use Window’s newer DirectWrite API to render text, whereas Chrome still uses the older GDI+ API. Apparently, Chrome’s sandbox architecture made it harder for them to use DirectWrite than for other browsers, and while Google engineers said they were aware of the problem and working on it, not much visible progress seemed to happen for a long time. In the meantime, many developers have taken to using hacks, such as the application of a semi-transparent CSS text-stroke, or forcing the use of SVG fonts, in order to reduce the jagginess of the displayed text.

Well, it’s not definite yet, but it looks like a real fix might be soon on its way. Google promised as much during their I/O conference, and in the past month this meta bug in the Chromium tracker has seen a lot of acitivity and blocking bugs closed. The meta bug, to switch the Windows font code from GDI to Skia, is apparently a prerequisite to turning on the DirectWrite backend. Fingers crossed we’re about to see this switch completed and landed in Chrome soon.

Custom at-rules in CSS

Recent talk about the “extensible web” got me thinking about some ideas I’d like to polyfill in CSS, particularly new declarative syntaxes for animations and state machines. To that end, I’ve posted a suggestion to the W3C’s www-style mailing list suggesting a new API for authors (e.g. web developers) to register custom JavaScript handlers for processing “var-” prefixed at-rules that the CSS parser comes across. The idea is that polyfills and libraries could then register at-rule handlers that process declarations. This would let people using those polyfills and libraries put the declarative configuration within CSS. I think it’s a good idea, but it remains to be seen if it gets a positive reception (or any reception at all, a lot of ideas posted to www-style sink without a trace, particularly if they’re not from W3C member employees).

I’ll try and post a more detailed explanation with examples when I get a chance.

Internet Explorer 11 Preview

Microsoft released a preview of IE11, as part of Windows 8.1. I don’t have Windows 8, or space to run a VM right now, so I haven’t tried it, but David Storey has posted a great round-up of all the new features. The four that caught my eye are WebGL (the big one), Fullscreen API, Web Crypto, and Mutation Observers, but there’s quite a few others. In all, it’s not a bad improvement for ten months work.

Unfortunately, as I expected nothing from Web Components is in there. I was hoping HTML templates might sneak in, as the spec is co-edited by Microsoft, but given it’s still a working draft that was never very likely.

Are We Componentized Yet? Mark II

Last year, I made a small dashboard to track the implementation status of the various specifications, polyfills and implementations that make up web components. I named it “Are We Componentized Yet?“, inspired by Mozilla’s various sites called some formation of are-we-x-yet, hosted it on GitHub, and forwarded the URL to some people working on the web components specs. I suggested that it, or something similar could help people to keep track of where the myriad moving parts of the web components effort. It was positively received, and I think it may have provided some inspiration behind the creation of the Chromium Feature Dashboard, which attempts to do something similar, except across every upcoming feature in the web platform!

After creating Are We Componentized Yet, I’m afraid I rather neglected it for a while. I did have some excuse though, as I was travelling around the Australian outback for a few months. Now I’m back in the UK, I had a bit of a push to update it from Paul Irish and Eric Bidelman, who pointed out that the utter lack of SEO made it virtually unfindable in search engines, and it was also missing some stuff like links to the new HTML Imports spec. I decided it was long overdue for a complete overhaul, particularly the extremely sucky design, so I’ve given it a complete refresh, with a lot more content, up-to-date information and a (hopefully) more attractive UI. Take a look: http://jonrimmer.github.io/are-we-componentized-yet/

It’s still far from perfect though. I was never entirely pleased with the presentation of the data in the table. I originally envisaged it as a series of status bars, filling in from the left towards completion, but it doesn’t quite work. I had to add in a yellow, intermediary colour to deal with items that had been started, but not yet finished, and it doesn’t make much sense to say something is “behind a flag” when it’s been released. None of that is fixed in the this new revision, but I have some ideas, and I hope to tackle that next. I also want to make it easy to see the implementation status in different browsers, so I hope to add in some kind of switch for that. Hopefully it won’t take me a year this time.

Web Platform Tidbits June 2013

Some things that have caught my eye over the past weeks:

ECMAScript 6 Compatibility Table (via Sylvain Galineau on Twitter)

A big matrix of all the features in the draft ES6 spec, and their implementation status in various browsers and JavaScript runtimes. Right now it’s a sea of red, but there’s hopeful signs. Perhaps unsurprisingly, Mozilla/Firefox lead the way, with the latest versions of Firefox having a little under 50% of them implemented. Google’s V8 team has issues open and assigned for many of these features, so I expect to see their compatibility increase quite a bit over the coming months.

Upcoming Safari Features

Something I and others have speculated about is how the departure of Google from the Webkit would affect the project’s forward momentum and that of Safari. Google engineers were working on a lot of new features, such as web components, that are now orphaned and the desire to avoid bit rot in the codebase has seen things like Shadow DOM removed. A sensible step in engineering terms, but a disappointing one for developers excited about web components.

However, as part of WWDC, Apple have apparently published a video1 about what’s new in Safari, an interesting slide from which was published on Twitter. It lists various features, one of which in particular caught my eye: CSS Grid Layout. I’ve written about Grid Layout before, as alongside Flexbox (also listed on the slide) it promises to make UI layout in web apps much easier.

The reason it caught my attention is that I knew it had, until Google’s departure, been implemented within Webkit by a Google engineer, Julien Chaffraix (Webkit Bug #60731). I wasn’t aware of any sign from Apple or the other Webkit contributors that they were preparing to adopt this feature, particularly since it is unfinished and its listing on the Webkit Feature Flags page says it has no contributors. The last WK commit related to it is by Chaffraix, three months ago. So what’s going on?

Sylvain Galineau pointed out that Apple aren’t promising to ship it right away, and there’s likely a few months of development ahead. He also speculated that Apple engineers may do their development in a private branch before merging the finished feature, but Webkit and Safari engineer Timothy Hatcher denied that, so unless it’s a mistake, it appears Apple are planning to ship it as is, or restart its development some time in the future, either by picking up where Chaffraix left off, or starting again from scratch.

The Extensible Web Manifesto

A bunch of movers and shakers from the world of web standards and browser development launched the Extensible Web Manifesto. It’s proposal to guide how standards groups develop the platform. It calls on them to focus on providing low-level capabilities that expose the underlying platform and also that explain the “magic” behind things like parsing. The idea being that web developers can then build on these low-level capabilities to create high-level features through libraries and components. These high-level features could then be easily distributed and iterated upon and, when matured, the best could be adopted back into the platform.

This all seems to tie in Alex Russell’s (and others) ideas about trying to develop a consistent view of the web as a platform, rather than just a grab bag of high level features tailored to the particular use cases envisioned by spec authors and browser vendors. The idea is that advanced frameworks and libraries won’t need to create their own parallel universe, complete with a bespoke component model, encapsulation and parsing, because the platform already has these, and will expose them in a way that allows them to be reused and extended in a flexible way.

It’s a good philosophy (I’ve signed it), and I see the same way of thinking gradually infecting a lot of other people who think about and develop the future of the web platform. Tab Atkin’s thoughts on making CSS more easily extendable seems to tie directly into it.

My only worry is that, scanning through the list of signatories, Google, Mozilla, TC39 and JS framework engineers are well represented, but I don’t see anyone from Apple or Microsoft. Google, in particular, seem very keen to drive forward this vision of the web platform, but without co-operation across the industry, will it become a reality? Time will, as ever, tell.

  1. Which I haven’t watched yet, as it requires Quicktime and will not run in anything other than Safari on OS X, not exactly a shining example of cross-platform web compatibility.