The consumer preview of Windows 8 with no Flash support in IE 10 Metro.
Microsoft seems to have changed its mind about Adobe Flash and will include a bundled version of Flash with its upcoming Metro-style Internet Explorer 10 web browser. Previously Microsoft announced that the Metro version of IE 10 would run without plugins like Adobe Flash or even Microsoft’s own Silverlight.
The rumor of an about-face on Flash comes from leaked Windows 8 screenshots that have turned up on rumor sites WinUnleaked and WithinWindows. Microsoft declined to answer Webmonkey’s questions for this post, noting only that “Microsoft does not comment on rumors and speculation.”
Rumors and speculation though the conclusions may be, the screenshots tell the story and the story is simple: The latest developer builds include support for Flash in Metro IE 10.
To get around the “no plugins” policy for IE 10 Metro, Microsoft appears to have included the Flash runtime in the actual browser, meaning that it’s not technically a plugin. But even with the new plugin that’s not a plugin, don’t expect Flash to work everywhere. Instead, Metro IE 10′s Flash support looks more like a last-ditch effort to make sure that big-name legacy sites with popular content will work in the Metro version of IE 10.
Flash in Metro isn’t going to work everywhere, though. In fact, Microsoft will maintain a white-list of sites that can access the Flash player in Metro. Microsoft’s previously published Internet Explorer Compatibility View lists dozens of sites including Hulu, CNN, Amazon, Adobe Labs and other popular sites with older, Flash video. (Wired is on that list as well.)
It’s unclear how much of the leaked info represents a change in Microsoft’s policy toward HTML5 video and web standards. Historically, Microsoft has gone to great lengths to maintain backward compatibility and it may be that dropping Flash entirely was simply too much for the company to stomach all at once. Also bear in mind that these leaked screenshots are of early builds and things may well change considerably before the final version of Windows 8 is released.
Google is celebrating electronic music pioneer Robert Moog’s 78th birthday with a Google doodle of the iconic Moog synthesizer. Like many past doodles today’s doodle doesn’t just look cool, thanks to the Web Audio API, it’s also a working synthesizer complete with a reel-to-reel tape machine for recording.
The Moog Google Doodle uses the nascent Web Audio API to create a mini Moog and power a mock reel-to-reel recorder. At the moment browser support for the Web Audio API is limited, but the doodle will work in most browsers since it falls back to Flash where the Audio API isn’t supported (the doodle does not work in Internet Explorer).
To play the Moog, just click any of the keys so that it gains focus and then you can play using your keyboard. All the nobs are fully functional as well, just click and drag to change the settings. Hit the record button and you can save your songs and share them with others.
Behind the scenes the Moog doodle also uses Closure libraries and some CSS 3 for the design and custom fonts. Developer’s interested in how the Moog doodle works can check out the archived doodle page and peruse the Moog.js JavaScript file for full details (as with all Google scripts, this one has been optimized for file size; you’ll want to run it through JSBeautifier or similar before you try to read it).
So many screens, so few images (testing responsive sites with Adobe Shadow). Photo: Adobe
The web design community continues to debate the merits and drawbacks of the WHATWG’s proposed adaptive images solution.
As we reported last week, a new srcset attribute has been added to the <img> element in the WHATWG’s HTML specification. The new attribute will allow developers to specify different sized images based on the user’s screen size.
The idea is to find a way to serve smaller images to devices that don’t need large images — saving precious bandwidth — while serving high-resolution images to screens that warrant them. And the WHATWG’s srcset attribute does solve some of the problems surrounding adaptive images, but it’s far from ideal.
Adaptive images are at odds with how browsers handle images thanks to what’s known as a “lookahead pre-parser.” Browsers use lookahead pre-parsers to start downloading images as soon as possible (to speed page-load times), which means images are parsed and downloads started before the browser has determined the full page layout.
However, a truly useful adaptive image solution needs the browser to first determine the page layout and then determine which images to use.
Grigsby rightly calls it a chicken and egg dilemma. “How do we reconcile a pre-parser that wants to know which size image to download ahead of time with an image technique that wants to respond to its environment once the page layout has been calculated?”
Grigsby argues that the smart thing to do might be for browsers to eliminate pre-fetching:
For existing web content, the lookahead pre-parser is undoubtedly the fastest way to render the page. But if web development moves towards responsive images as standard practice, then delaying the download of images until the proper size of the image in the layout can be determined may actually be faster than using the lookahead pre-parser. The difference in size between a retina image for iPad and an image used on a low resolution mobile phone is significant.
That’s going to be a tough sell to browser makers right now. Browser makers are understandably loath to do anything that might slow down page-load times — even if that slow-down is temporary.
Other possible solutions Grigsby covers include progressive image formats (which suffer from similar chicken-and-egg dilemmas) and of course the <picture> element. The whole article is well worth a read since it gets into more details about why all of these solutions are ultimately less than ideal.
So many screens, so few images (testing responsive sites with Adobe Shadow). Photo: Adobe.
The web needs a more intelligent way to serve images.
No one wants to waste bandwidth sending large images over limited mobile pipes, but everyone wants images to look good on the myriad screens connecting to today’s web. Currently web authors use a variety of hacks to (incompletely) work around this problem, but to really solve it the web likely needs new tools.
Unfortunately, thanks to miscommunication between standards bodies, web developers and browser makers, instead of a solution to the image problem what developers got this week feels more like a slap in the face. Eventually an adaptive image solution will likely emerge, but the real lesson for many developers will be about how the standards process works and how they fit into it, if at all.
Webmonkey has previously looked at some proposed solutions to the adaptive image problem. Some very smart web developers came up with the idea of a <picture> element that works much like the current HTML <video> element. These developers thought they had the attention of the Web Hypertext Application Technology Working Group, better known as the WHATWG. Then, earlier this week, Edward O’Connor, Apple’s WHATWG representative, proposed another method of solving the problem, using a new srcset attribute on the <img> element. See our earlier coverage of the srcset attribute for a more detailed look at how it works and compares to the <picture> proposal.
What has web developers up in arms is that Ian Hickson, editor of the WHATWG spec (and better known as Hixie) has already added the srcset attribute to the WHATWG’s HTML draft spec, seemingly ignoring the months of effort that went into <picture>. Worse, members of the WHATWG apparently weren’t even aware that developers were putting forth the effort to come up with a solution via the Responsive Images community group. Nor were concerns about the srcset syntax given much consideration. Hickson does address some objections to srcset in his message to the WHATWG, but ends up dismissing most of them.
That doesn’t match up with how most people envision the web standards process. But as web developer and standards advocate Jeremy Keith writes, “this is exactly how the WHATWG is supposed to work. Use-cases are evaluated and whatever Hixie thinks is the best solution gets put in the spec, regardless of how popular or unpopular it is.”
In fact, think of the WHATWG as the source for initial, rapid development of new features. The group was started by browser makers because the W3C’s HTML Working Group (HTMLWG) moved too slowly. But if the WHATWG is the source of rapid development, the W3C is an effective check on that speed, ensuring that even those of us who don’t make web browsers still have a voice in the future of HTML. (see our earlier overview for more on the history and differences between the HTML WG and the WHATWG.)
While the HTML WG is also chaired by Hickson (a position he will soon step down from), it offers a much more democratic (and consequently slower) process and has overridden the WHATWG’s rash decisions in the past. For example the W3C added the time element back after Hickson removed it from the WHATWG spec.
Confused yet? It gets worse. The WHATWG is working on an ever-evolving standard, what it calls a “living standard,” which is different from — and may well diverge from — the snapshot-based standards issued by the W3C, like HTML5. In a comment on longtime web standards champion Jeffery Zeldman’s post on the matter, Jeremy Keith writes, “I don’t mind if the srcset attribute is in the WHATWG HTML spec but not in the W3C HTML5 spec. If it works, it’ll end up in a future W3C version number.”
Implicit in Keith’s statement is that if the srcset attribute doesn’t end up working out it won’t be in HTML5.x and would likely just fade away like the blink tag, the applet tag and other HTML ideas tried and later discarded.
Which is another way of saying developers need not panic. Perhaps web developers don’t have a voice in the WHATWG simply because we’ve been using the wrong channels (W3C community groups don’t seem to be an effective means of communicating with standards bodies, in fact they seem more like this.). If you’ve got ideas and would like a voice in the future of the web join the WHATWG mailing list and login to the IRC channel. Introduce yourself, learn the rules and contribute.
A better way to serve responsive images. Photo: Ariel Zambelich/Wired.com
Responsive web design has grown well beyond its humble beginnings — using liquid layouts and media queries to scale websites so they fit any screen — and now means developers must wrestle with much more complex problems, like serving the right image to the right screen.
The Responsive Images community group has been wrestling with this problem for some time and has proposed and refined the <picture> tag, one possible solution. The picture element would work much like the HTML5 <video> tag, with code that looks something like this:
Due to a communication breakdown between the WHAT WG, which actually writes the standards, and the community group, which is a way for outsiders to contribute to standards, the WHAT WG is already considering a different proposed solution that involves adding some elements to the good old <img> tag.
The proposed solution comes from Apple’s Edward O’Connor and mirrors a similar syntax for background images in CSS. Neither are standards yet and we’re hoping neither ever become standards. Here’s an example of the proposed syntax:
That’s a code tangle only a browser maker could love and in the subsequent discussion on the community group post developers are nearly unanimous in preferring the <picture> tag (though many dislike its verboseness). The truth is neither this nor the <picture> tag is a very appealing solutions.
However, toward the bottom of that discussion thread Denis Leblanc proposes another possible solution, namely, header tags. Matt Wilcox, who created the Adaptive Images solution we’ve covered before, takes Leblanc’s idea and runs with it in another post. What Leblanc proposes is creating a new head tag that would allow web developers to create breakpoints with a media-query-like syntax:
What the code above does is set “case” to equal a particular value, when a media query expression is matched. And if that’s done in the HTML <head> we know that absolutely everything else can rely on it — the <head> is the very first thing parsed by a browser, even before anything inside <body>. Anyone familiar with working on the ‘responsive images’ problem should at this point be getting very excited. It means that the browser can be aware of the need to adapt before any pre-fetch behaviours have been triggered by finding an <img /> element in the mark-up. That is a major advantage and is how this solution solves the problem of image pre-fetch.
In other words, this solution neatly avoids downloading anything other than only the image needed, saving bandwidth and processing power. Then in your body you would simply write:
It’s certainly less verbose than either of the other proposals, needing only a single image element with no custom properties or other code. It’s also backward-compatible provided you either create a directory called “{case}” on your server or alias the path to an existing file. Browsers that don’t understand the syntax simply serve the image referenced and those that do choose the appropriate image from the meta tag breakpoints you’ve set.
In short, this looks like a very ideal solution from a web author’s point of view. Whether or not browser makers and the standards bodies agree remains to be seen. One possible strike against it is that it would add variables to HTML in the form of the {case} syntax, but variables are already part of CSS and JavaScript, so why not HTML?
None of these proposals is anything more than an idea at this stage — though there is already a JavaScript polyfill for the new head tag idea — but if you’d like to keep up with what’s happening, be sure to keep an eye on the W3C’s Responsive Images community group. It’s not going to happen overnight, but eventually standards bodies and browser makers are going to start implementing solutions and the more experimenting web developers have done, the better those solutions will be. It’s your web after all, so make it better.
Browse Our Tutorials
Cheat Sheets
Color Charts
Cut & Paste Code
