X SEO

Earlier this year we announced an exciting redesign initiative for Flickr, focused on providing our members with new and easier ways to share their lives in photos by letting photos take center stage. Change is hard for some, especially when it comes to something as personal and precious as your photography, so we’re implementing the updates in phases. We recently introduced a Justified layout and embedded photo editing tool by Aviary, and today we’re proud to announce the newest piece of our design evolution: an improved Uploadr experience for users that makes adding photos – and related details about them – to Flickr a snap.

This completely new uploading experience makes it easier than ever to select, upload, and share images. You can edit batches of photos and share the story behind your photos, adding tags, captions, and organizing sets.

We used HTML 5 technology so you can easily drag-and-drop to arrange your photos exactly the way you want them to look in your photo stream. And we’ve amped up the experience by increasing our upload speeds by up to 30% and our file size limits to 50MB for Pro users and up to 30MB for free users. With options like these, you don’t have to sacrifice pixel quality when sharing your photos with family and friends.

The Flickr team is hard at work to bring you even more cool features as part of this larger reimagining of the Flickr experience. Stay tuned for lots more!

In the meantime, you can read more about the new Uploadr on the Flickr Blog and on the Flickr Developer Blog at code.flickr.com.

Go forth and Flickr!

Photo: Available from Schill./ FLICKR: http://www.flickr.com/photos/schill/6464356545/sizes/l/in/faves-karaem23/

Facebook has revealed that its HTML5 site has twice as many users as its iOS and Android apps combined. But that’s actually a problem, because Apple and Google’s mobile browsers don’t support photo uploads or high-performance animation for HTML5 — features that are crucial to getting Facebook mobile site users sharing more and convincing app developers to port to HTML5 where Facebook can tax payments.

To encourage mobile browser advancement, Facebook formed the W3C community group, but Apple and Google, the two partners it needs most, have refused to join. Since these oft-rivals to the social network own the dominant mobile browsers Safari and Chrome, Facebook’s efforts may have little impact, HTML5 apps and games will stay inferior, and both Facebook and the end user will miss out.

The audience for great HTML5 apps could be huge. When Facebook stopped reporting the user counts of its iOS and Android apps to AppData, Android had 95 million MAU, iPhone had 105 million MAU, and iPad had 20 million MAU. Given their trajectory they could now have well over 235 million combined monthly active users, and so could its HTML5 site. As of a few months ago, Facebook was driving 120 million visits a month to HTML5 apps. This all means Facebook has a big financial incentive to push the advancement of mobile browser standards.

Facebook doesn’t view its HTML5 app support as a traditional mobile app platform like iOS or Android. Rather it thinks of itself as a social layer that’s integrated into iOS, Android, and HTML5, but that happens to support payments for mobile web apps. The core of Facebook’s business is advertising, but it still makes healthy revenues from the 30% Credits tax on its web game canvas. As more and more gaming shifts to mobile, though, it would help if HTML5 was good enough to support advanced apps that Facebook could then offer viral distribution for and monetize in return.

To fill us in on how it’s trying to jumpstart mobile browser progress, Facebook recently brought several journalists to its headquarters to meet James Pearce, head of mobile developer relations. This year Facebook released the open source Ringmark mobile browser testing suite that shows how many of the core capabilities necessary to build HTML5 apps does a browser support. To date, no browser or device has completed Ring 1, which includes camera access, DRM, and accelerated canvas for graphics-intensive games.

Safari and Chrome could probably become Ring 1-complete if Apple and Google really wanted them to, but they’re focused on their surprisingly successful native app platforms. Better HTML5 support would also mean developers could port their current iOS and Android apps to HTML5, giving users options beyond the app store where Apple and Google can’t monetize payments.

In hopes of persuading them to juice up their mobile browsers, Facebook created the WC3 community group to galvanize support from app developer, carriers, and OEMs, and the rest of the mobile industry. Mozilla and Opera are on board, but they don’t have enough distribution to make that significant. If Facebook can amass a enough rabble-rousers maybe it can get popular mobile browsers to do comply.

Pearce didn’t address the two other web giants with “Yo”, but he did tell us Apple and “Google [are] the audience for what this community group is producing. Its output is a series of prioritizations about what the browser vendors need to do. It’d be wonderful if in the future we saw Ring 1 browsers. Everyone in the industry has the motivation to see this be successful. We’re not swimming against the tide here. There’s not necessarily a need for us to beat anyone with a stick. They know this needs to happen.”

Apple and Google should put politics aside and the user first, devote more resources to mobile browser development, and bring mobile Safari and Chrome up to snuff. There’s certainly some shortcomings to HTML5, but Apple and Google employ some of the smartest people in the world. Even if it helps Facebook, it’s the right thing to do. Maybe one day an Instagram or even an Infinity Blade could run straight from your mobile browser.

Postscript: Unfortunately, despite their app sales revenue being dwarfed by Apple mobile hardware and Google mobile advertising, these two still have a vested interest in seeing HTML5 lag behind native apps. Don’t expect them to pour money into HTML5 until they absolutely have to.

A couple of weeks back I wrote about customizing your markup, but I got an important bit wrong and while I’ve corrected the post, I wanted to clear up the error in detail.

I said that you wrap portions of your document (or the whole thing) in an element element and use the customized element inside. This is incorrect, and actually a very bad idea. In fact, you define your customized elements using an element element and then use the customized elements later in the document. Something like this:

<element extends="h1" name="x-superh1">
</element>

<h1 is="superh1">UltraMegaPower!!!</h1>
<h1>Regular Old Power</h1>

The line break inside the element element isn’t required—I just threw it in for clarity.

The element element can optionally contain template markup, but I honestly don’t understand that part of it yet. I get the general idea, but I haven’t crawled through the specifics long enough to have really internalized all the fiddly bits. And as we all know by know, the fiddly bits are where understanding lives and dies. (Also where the Devil hangs out, or so I’ve been told.)

I still firmly believe that all this papers over a much bigger problem, which is the arbitrary barrier to devising and using actual custom elements (as opposed to customized existing elements). HTML5 already allows you to make up your own bits of language: you can make up any attribute you want as long as your preface the name with data-. Okay, so that’s a little bit clumsy naming-wise, but the capability is there. You don’t have to register your attributes, or declare them in a list, or any of that other stuff. You just make up data-timing or data-proglang or data-sttngcharacter on the spot and off you go.

This is not possible for elements. You can’t even make up a prefixed element name, whether it’s data-kern or x-kern or even xkern (to avoid the limitation that hyphens aren’t allowed in element names). You just can’t devise your own elements. The best you can do is use the element element to sprinkle some semantic dust bunnies on top of elements that already exist.

Of course, all this “you can’t” and “not possible” applies to the specification. Browsers will let you feed them any old element name and style it, script it, whatever. Some say that’s more than enough. If the browser lets you do it, why let the specification hold you back? And of course, that’s how most people will approach the situation.

To someone like me, though, who spent years (literal years) explaining to web folk the world over that just because Internet Explorer for Windows let you write width: 12 px, actually writing it was still a bad idea—well, those habits die hard. Just doing stuff because the browser let you do it is not always a good idea. In fact, more often than not it’s a bad idea.

None of that really matters, as I say, because people are going to inject their own elements into their markup. They’ll do it because it’s easier than thinking about the proper element to use, or they’ll do it because no appropriate element yet exists, or for some other reason. That’s why the HTML5 specification ought to include the ability to do it, so that we have a paved path and defined best practices. The capability is useful, as the data- attribute feature demonstrates. If there’s a good, solid technical reason why extending that customization from attributes to elements is not desirable, I’d really like to know what it is.

So HTML5 allows you (at the moment) to create your own custom elements. Only, not really.

Suppose you’re creating a super-sweet JavaScript library to improve text presentation—like, say, TypeButter—and you need to insert a bunch of elements that won’t accidentally pick up pre-existing CSS. That rules span right out the door, and anything else would be either a bad semantic match, likely to pick up CSS by mistake, or both.

Assuming you don’t want to spend the hours and lines of code necessary to push ahead with span and a whole lot of dynamic CSS rewriting, the obvious solution is to invent a new element and drop that into place. If you’re doing kerning, then a kern element makes a lot of sense, right? Right. And you can certainly do that in browsers today, as well as years back. Stuff in a new element, hit it up with some CSS, and you’re done.

Now, how does this fit with the HTML5 specification? Not at all well. HTML5 does not allow you to invent new elements and stuff them into your document willy-nilly. You can’t even do it with a prefix like x-kern, because hyphens aren’t valid characters for element names (unless I read the rules incorrectly, which is always possible).

No, here’s what you do instead:

1. Wrap your document, or at least the portion of it where you plan to use your custom markup, in an element element. That’s not a typo.
2. To your element element, add an extends attribute whose value is the HTML5 element you plan to extend. We’ll use span, but you can extend any element.
3. Now add a name attribute that names your custom “element” name, like x-kern.
4. Okay, you’re ready! Now anywhere you want to add a customized element, drop in the elements named by extends and then supply the name via an is attribute.

Did you follow all that? No? Okay, maybe this will make it a bit less unclear.

<element extends="span" name="x-kern">
<h1>
<span is="x-kern" style="…">A</span>
<span is="x-kern" style="…">u</span>
<span is="x-kern" style="…">t</span>
<span is="x-kern" style="…">u</span>
mn
</h1>
<p>...</p>
<p>...</p>
<p>...</p>
</element>

(Based on markup taken from the TypeButter demo page. I simplified the inline style attributes that TypeButter generates for purposes of clarity.)

So that’s how you create “custom elements” in HTML5 as of now. Which is to say, you don’t. All you’re doing is attaching a label to an existing element; you’re sort of customizing an existing element, not creating a customized element. That’s not going to help prevent CSS from being mistakenly applied to those elements.

Personally, I find this a really, really, really clumsy approach—so clumsy that I don’t think I could recommend its use. Given that browsers will accept, render, and style arbitrary elements, I’d pretty much say to just go ahead and do it. Do try to name your elements so they won’t run into problems later, such as prefixing them with an “x” or your username or something, but since browsers support it, may as well capitalize on their capabilities.

I’m not in the habit of saying that sort of thing lightly, either. While I’m not the wild-eyed standards-or-be-damned radical some people think I am, I have always striven to play within the rules when possible. Yes, there are always situations where you work counter to general best practices or even the rules, but I rarely do so lightly. As an example, my co-founders and I went to some effort to play nice when we created the principles for Microformats, segregating our semantics into attribute values—but only because Tantek, Matt, and I cared a lot about long-term stability and validation. We went as far as necessary to play nice, and not one millimeter further, and all the while we wished mightily for the ability to create custom attributes and elements.

Most people aren’t going to exert that much effort: they’re going to see that something works and never stop to question if what they’re doing is valid or has long-term stability. “If the browser let me do it, it must be okay” is the background assumption that runs through our profession, and why wouldn’t it? It’s an entirely understandable assumption to make.

We need something better. My personal preference would be to expand the “foreign elements” definition to encompass any unrecognized element, and let the parser deal with any structural problems like lack of well-formedness. Perhaps also expand the rules about element names to permit hyphens, so that we could do things like x-kern or emeyer-disambiguate or whatever. I could even see my way clear to defining an way to let an author list their customized elements. Say, something like <meta name="custom-elements" content="kern lead follow embiggen shrink"/>. I just made that up off the top of my head, so feel free to ignore the syntax if it’s too limiting. The general concept is what’s important.

The creation of customized elements isn’t a common use case, but it’s an incredibly valuable ability, and people are going to do it. They’re already doing it, in fact. It’s important to figure out how to make the process of doing so simpler and more elegant.

This morning I caught a pointer to TypeButter, which is a jQuery library that does “optical kerning” in an attempt to improve the appearance of type. I’m not going to get into its design utility because I’m not qualified; I only notice kerning either when it’s set insanely wide or when it crosses over into keming. I suppose I’ve been looking at web type for so many years, it looks normal to me now. (Well, almost normal, but I’m not going to get into my personal typographic idiosyncrasies now.)

My reason to bring this up is that I’m very interested by how TypeButter accomplishes its kerning: it inserts kern elements with inline style attributes that bear letter-spacing values. Not span elements, kern elements. No, you didn’t miss an HTML5 news bite; there is no kern element, nor am I aware of a plan for one. TypeButter basically invents a specific-purpose element.

I believe I understand the reasoning. Had they used span, they would’ve likely tripped over existing author styles that apply to span. Browsers these days don’t really have a problem accepting and styling arbitrary elements, and any that do would simply render type their usual way. Because the markup is script-generated, markup validation services don’t throw conniption fits. There might well be browser performance problems, particularly if you optically kern all the things, but used in moderation (say, on headings) I wouldn’t expect too much of a hit.

The one potential drawback I can see, as articulated by Jake Archibald, is the possibility of a future kern element that might have different effects, or at least be styled by future author CSS and thus get picked up by TypeButter’s kerns. The currently accepted way to avoid that sort of problem is to prefix with x-, as in x-kern. Personally, I find it deeply unlikely that there will ever be an official kern element; it’s too presentationally focused. But, of course, one never knows.

If TypeButter shifted to generating x-kern before reaching v1.0 final, I doubt it would degrade the TypeButter experience at all, and it would indeed be more future-proof. It’s likely worth doing, if only to set a good example for libraries to follow, unless of course there’s downside I haven’t thought of yet. It’s definitely worth discussing, because as more browser enhancements are written, this sort of issue will come up more and more. Settling on some community best practices could save us some trouble down the road.

Update 23 Mar 12: it turns out custom elements are not as simple as we might prefer; see the comment below for details. That throws a fairly large wrench into the gears, and requires further contemplation.

In honor of the new Yoast Google+ page, I’ve taken questions there which I’ll answer here, so everyone can benefit. Do you think the increased number of metatags released by Google are good for webmasters and the web, or just making things more complicated for the amateur so only those that can afford SEO consultancy [...]

href="http://yoast.com/q-a-google-plus/">Questions and Answers – Google+ edition is a post by rel="author" href="http://yoast.com/author/admin/">Joost de Valk on href="http://yoast.com">Yoast – Tweaking Websites.A good WordPress blog needs good hosting, you don’t want your blog to be slow, or, even worse, down, do you? Check out my thoughts on href="http://yoast.com/wordpress-hosting/">WordPress hosting!

Today, we’re excited to announce the next step in the evolution of Bing for Mobile, with the release of the new Bing for Mobile app for iPhone and Android (coming soon to more devices). Today’s update uses HTML5 to blend the mobile browse experience with the app experience so you get a consistent and fast mobile search experience whether you’re using m.bing.com from your browser or the Bing app.

Rather than tightly binding functions into a mobile client, we want to embrace the drive towards exposing our functions via an HTML5 experience.  In order for search to advance, engines need to be able to call functions that are currently ‘hiding’ in apps so we can better help people get done what they are trying to get done.  Using HTML5, our goal is to build a mobile experience that leverages the unique capabilities of the different platforms including camera support and voice search, while making the functions the apps can provide consistent across the platforms and – in the future – callable by engines to help people get from searching to doing.

Check out this video where Andy and Stefan talk about this transition to an HTML5 mobile experience:

The update includes several cool new features such as:

• Maps/List Split View: Provides a dynamic way to synchronize a list such as business listings and directions and a map in a single view making it easy to see the location of what you’re searching for. Also works for driving directions and transit.
• Deals: One-stop deal shopping and convenient mobile phone access for local deals from more than 100 deal providers across the US.
• Video Domain: launched last month on m.bing, the new video domain is now available on iPhone.
• Transit/Real-Time: the Android app now features transit routing/real-time transit and news– all features that were previously only available on m.bing.com.

The new app is currently available for iPhone devices and select Android devices in the United States. We’re working to release the same consistent experience for RIM and Windows Phone 7 devices in the future, and will share more details as they become available.

To get the update, go to the Android Market (Android users on Verizon can go here) or iPhone App store to download the latest version. Once you have downloaded, future updates to the experience will happen automatically.

Check out the update today and let us know what you think!

- Santanu Basu, Product Manager, Bing for Mobile

Earlier tonight, Alexia found and posted some screenshots of something that sure looked a lot like the mythical “Project Spartan“. Shortly thereafter, Facebook took down the page in question. And for good reason. That was Project Spartan, we’ve now confirmed.

Whoops.

Well, to be fair, I’ve heard numerous times that they don’t actually call it that internally. That may be a name that external developers use. No matter — we all know what I mean. It’s the HTML5-based mobile platform that Facebook has been building in secret for months. And now it’s done. In fact, it has been done for a while. From what I hear, it has been waiting on one thing…

And that’s where things get really interesting.

At the risk of sounding like The Boy Who Cried Wolf, I’m just going to say it: Facebook’s iPad app is about to launch. That too has been ready to go for a while now, but it has been held up by some internal back-and-forth between Apple and Facebook. And Project Spartan has been waiting on that iPad app.

Earlier this week, Mashable reported that Facebook’s iPad app would launch at Apple’s iPhone event this coming Tuesday. For what it’s worth, we’ve heard Facebook is actually planning to launch the iPad app at their own iPad/Spartan event on Monday. But they’re still discussing all of this with Apple. And Apple has been well known to change things at the last second. It is possible that they want Facebook to launch this on stage at their event to showcase some of the new HTML5 capabilities of iOS 5 (which will also be formally unveiled at the event).

I believe the Monday launch is a fallback option. Facebook is apparently ready to go with or without Apple.

Last week, we noted that the main developer of Facebook’s iPad app left in frustration over delays with the app. Again, this is all about the Facebook/Apple relationship. Don’t believe the app was pretty much ready to go a couple of months ago? Then why was it in the live code?

Spartan has also been delayed a few times. More recently, we’ve been hearing a lot about the collaboration between Apple and Facebook on the project. The two (Facebook iPad and Facebook Spartan) are now joined at the hip, it seems. One will not launch without the other. And apparently, all of this is with Apple’s blessing.

But make no mistake, the relationship between the two companies is tenuous at best. Both know that they’d probably be better of working together, but both also believe that they don’t actually need each other. Hence, the dancing we’ve been seeing and hearing about. The two are frenemies. But the launch of Google+ has made one common enemy very clear…

This time it sure looks like the planets are aligning. Sources on both side suggest a major Facebook/Apple/iPad/HTML5 announcement happening early next week one way or another. This time I wouldn’t bet against it.

Here at the Bing homepage team, we’re always looking for ways to bring you a little something special. Today we’re really excited to announce the first ever video homepage.

If you have an HTML-5 enabled browser, you now get all the beauty and intrigue of the Bing homepage with a little breath of life added. Users without a modern browser will continue to see the gorgeous still photography that we’re known for. Not getting the video and want to see what the fuss is about? Try downloading IE9 and going to www.bing.com.

We won’t be programming a video every day, just when the mood strikes us.

While this first video is US-only, we’ll begin rolling the video homepage out to international markets in the next few months – so stay tuned.

If you’re interested in learning more about the evolution of the homepage and how the team chooses content, check out the following video.

Happy first day of fall!

Stephanie Horstmanshof

Bing Homepage team