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.

Flickr's new group pool pages, now with "justified" view.

Flickr has made some small but welcome upgrades to the cornerstone of its social features — Flickr Groups. The changes include a new way to view group pools and the ability to post directly to groups using Flickr’s new HTML5 uploader.

Flickr lacks the hype of more recent photo-sharing services like Instagram, but remains popular with pro and amateur photographers alike at least in part because of the community that continues, despite some stumbles, to exist on the site. Much of that community is built around Flickr Groups, like-minded photographers banding together to share images of anything from beautiful mountains to sushi to a shared love of RAW images from micro 4/3 cameras.

In an effort to make it easier for Flickr fans to contribute to Groups, Flickr’s recently updated photo uploader now offers an option to share your photos with any group you’ve joined directly from the upload page.

Perhaps more importantly, Flickr is extending the Flickr API with the same features, making it possible for third-party applications — like your favorite iOS and Android photo apps — to add the same group sharing features. Developers can check out the Flickr code blog for more on what’s new in the Flickr API.

As part of today’s Groups upgrade, Flickr is also extending its “justified” view — which tiles images to fit more photos at larger sizes in a smaller space — to Group photo pools. Along with the justified view, Group Photo Pool pages now have a persistent (but collapsible) sidebar where you can quickly access group discussion threads, view tags and see the top contributors.

Mozilla Webmakers Summer Code Party, coming soon.

Mozilla has kicked off a new effort to do something that’s very near and dear to Webmonkey’s heart — helping people create cool stuff on the web. Mozilla Webmaker, as the new initiative is known, wants to create “a new generation of webmakers, and a more web literate world.”

Mark Surman, Mozilla’s Executive Director, calls web literacy “the world’s second language,” and goes on to say Mozilla believes web literacy is “a vital 21st century skill — as important as reading, writing and arithmetic.”

To help bring that literacy to more people around the world Mozilla’s Webmaker will offer a variety of different things to try, each aimed at different interests:

• 1) Tools. Authoring tools and software, designed and built with our community. From supercharging web video with Popcorn, to remixing with Hackasaurus, to making your own web pages with Thimble.
• 2) Projects. Practical starter projects, how-tos and recipes, designed to help people at all levels make something amazing with the web. From tweaking your blog template to building apps that change the world.
• 3) Community. Bringing people with diverse skills and backgrounds together. Teachers, filmmakers, journalists, youth. From web ninjas to newbies. All making and learning together at events, meet-ups and hack jams everywhere.

Webmaker isn’t just Mozilla, either; the company has partnered with the likes of Tumblr, Creative Commons, Code for America, and dozens of others.

To get things started, Mozilla will kick off what it calls a “Summer Code Party” on June 23. And yes, it sounds a lot like Google’s Summer of Code, but with a focus on building the open web. Head over to the Webmaker site to search for something near you or start your own event.

For more info about Summer Code Party and other aspects of the Webmaker initiative head over to the new site, or check out the intro video below.

[Update: Several readers have asked about Thimble, mentioned in the Mozilla quote above. A Mozilla spokeperson tells Webmonkey, "Mozilla Thimble is the name of a web app we're building that provides a live side-by-side code editor for webmakers -- code on the left, live preview on the right." Thimble will also provide error checking and code tips find and fix mistakes quickly. Mozilla says the goal is to "give webmakers a tool to build and share web pages and also allows them to load in our pre-made project templates with guided content." Mozilla Thimble will launch as a beta in early June, in time for the Summer Code Party campaign.]

The Web Audio API in action. Image: Evolver.fm

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.

Now developer Jason Grigsby argues that not only will the srcset solution not completely solve the problem, but the goal of adaptive images is fundamentally at odds with how web browsers currently handle images. In other words, there currently is no way to solve the problem.

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.

Students: Step into your summer office. Image: Lost In The RP/Flickr

Past participants have helped improve everything from popular web frameworks to browser add-ons and even operating systems. Summer of Code is also not a half bad way to get yourself on Google’s radar — the company looks at the results of the program to help it “identify potential recruits.”

Summer of Code has served as a launchpad for quite a few new open source software projects as well as helping to jumpstart work on existing favorites. This year’s roster includes some 1,208 students who will spend the next 12 weeks writing code for 180 different open source organizations.

With 208 proposed projects, there’s a pretty good chance that some Summer of Code improvements will be rolled into your favorite open source projects later this year. Among the things we’ll be keeping an eye on are Metalink’s various efforts to improve the download capabilities in Firefox and Chrome. Eventually Metalink wants to bring error recovery/repair for large downloads to everything from Chrome to wget.

Other promising projects include several efforts to help improve OpenStreetMap, the so-called “Wikipedia of maps,” as well as Code for America’s various projects, some new features for Git and an ambitious plan to bring Pylint into the modern world of Python 3.

For more info on this year’s Summer of Code, head over to Google’s Summer of Code website, which has details on all the various projects and participants. You can also get updates from the Summer of Code page at Google+.

The Eephus League Magazine: showing publishing pros how it's done.

Baseball season is already well under way, but it’s never too late for another site about America’s favorite pastime — especially when it’s as awesome as the beautiful Eephus League Magazine.

Even if you have no idea what the name means — and fear not, even some baseball fans aren’t familiar with the Eephus pitch since it isn’t throw much (though current Red Sox reliever Vicente Padilla has something like an Eephus pitch) — the site is well worth a visit for its gorgeous layout and design.

The Eephus League Magazine is written and produced by web designer Bethany Heck, but if the interface and navigation looks slightly familiar it’s probably because the underlying code is the work of Ian Coyle, creator of Nike’s Better World site, which we featured last year.

Since then Coyle has also released Edits Quarterly, an online magazine of photography and short films. Edits is what inspired Heck to put together The Eephus League Magazine. And it’s not hard to see why, with Edits Coyle managed to create something even the so-called pros of the magazine publishing world can’t seem to make — a digital magazine that doesn’t suck.

What makes Edits — and its offspring like Eephus — remarkable is that it manages to feel like reading a print magazine even though you’re really just scrolling down a webpage. For example, there are what you might call “pages” in Coyle’s design, but they aren’t simple skeuomorphs like you’ll find in e-readers. Instead the “pages” just serve to move you through the content and keep articles separate even as they are all together on one page. Scrolling remains vertical; there’s no awkward “page flipping” actions. The Eephus League Magazine uses Coyle’s JavaScript, so moving through it feels just like browsing Edits, but Heck has made a few adjustments to fit Eephus‘s own layout and images.

In the end the experience of both magazines is different enough to catch your eye, but not so much so that it overwhelms the content. But don’t take our word for it, head over to Eephus and be sure to check out Edits Quarterly as well.

Photo: Only Sequel/Flickr

Twitter has jumped on the “Do Not Track” privacy bandwagon.

The company recently confirmed that it supports the Do Not Track header, a user privacy tool originally created by Mozilla that is in the process of becoming a web standard. That means if you visit Twitter in any web browser that supports the Do Not Track header, you can opt out of the cookies Twitter uses to gather personal information, as well as any cookies set by third-party advertisers.

Behavioral tracking, as such practices are often called, is a common on the web. Advertisers use cookies to track your clicks, watching which sites you visit, what you buy and even, in the case of mobile browsers, where you go. Often the sites tracking you are not just the sites you’ve actually visited, but third-party sites running ads on those pages.

And it’s not just advertisers tracking your movements, social networks like Facebook and Twitter also follow you around the web. You may not realize it, but Twitter has been tracking your every move for some time. The company doesn’t make a secret of it either. In a blog post announcing Twitter’s new “tailored suggestions system” Twitters Othman Laraki writes, “we receive visit information when sites have integrated Twitter buttons or widgets.”

To be clear, not only is Twitter able to set cookies any time you visit its own domain, whenever you visit a website (like this one) with a “Tweet This” or similar button Twitter can see you there as well. This practice is hardly unique to Twitter; Facebook, Google+ and others are doing the same thing.

Most of the time the information gathered is used to create a better experience for users. In the case of Twitter’s new “tailored suggestions” feature the information is used to build a profile of what you like and then Twitter makes suggestions based on that profile. You can read about exactly what Twitter does with your info and how long it keeps it in the company’s privacy policy.

The problem with such tracking is that it’s necessary for features we want, like smart, targeted suggestions — new users to follow, music you’ll likely enjoy, books you might want to read and so on — but it can also be used for decidedly less friendly purposes. As awareness of the downsides to such tracking become more well known a growing number of people are opting out of the tracking. The Mozilla Privacy blog reports that “current adoption rates of Do Not Track are 8.6 percent for desktop users of Firefox and 19 percent for Firefox Mobile users.”

To take advantage of Twitter’s new Do Not Track feature you’ll need to be using a web browser that supports the header. Currently that means Firefox, Opera 12+, Internet Explorer 9+ or Safari 5.1+. Chrome has pledged to add support for Do Not Track, but doesn’t just yet. For more information on protecting your online privacy, including tools like Ghostery, which go even further, blocking all tracking cookies, see our earlier post, Secure Your Browser: Add-Ons to Stop Web Tracking.

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.

Image: Google

Google has released an update for its Chrome web browser that adds tab syncing to Chrome’s list of tricks. Using the latest version of Chrome you can now access the tabs open on your desktop at home while you’re out and about with your Android phone. The syncing should work with any device that can run the latest version of Google Chrome.

Current Chrome users will be automatically updated to the latest version. If you’d like to try out the latest version of Chrome head over to the download page.

The tab-syncing feature was already available to those using the Chrome beta channel, but now it’s available in a more stable form.

As with the rest of Chrome’s syncing features, you’ll need to be signed into your Google account in Chrome for it to work. To give it a try just sign in and look for the Other Devices menu on Chrome’s New Tab page. Click that button and you’ll see a list of every open tab on all the devices signed into that Google account.

While tab syncing is handy if you move between home and work computers, it really shines when going from desktop to mobile. If you’ve got an Android phone with the new Chrome beta installed, you’ll now be able to access any open tab on your desktop machine no matter where you are. The reverse is also very helpful, especially for those times when you encounter a mobile-unfriendly page — just open it later when you get home.

Note that Chrome users will be automatically updated to the latest stable version of the browser over the next few days, but the Chrome Blog reports that the tab-syncing features “will be rolled out more gradually over the coming weeks.” If you don’t have access just yet, you’ll have to get by with this video from Google until tab syncing is enabled for your account.