WebDev FeedHouse

W3C: XHTML Modularization 1.1 - Second Edition is a W3C Recommendation

W3C Staff — Fri, 30 Jul 2010 18:00:12 +0000

The <a href="/MarkUp/">XHTML2 Working Group</a> has published a W3C Recommendation of <a href="/TR/2010/REC-xhtml-modularization-20100729/">XHTML Modularization 1.1 - Second Edition</a>. XHTML Modularization is a tool for people who design markup languages. XHTML Modularization helps people design and manage markup language schemas and DTDs; it explains how to write schemas that will plug together. Modules can be reused and recombined across different languages, which helps keep related languages in sync. This edition includes several minor updates to provide clarifications and address errors found in version 1.1. Learn more about the <a href="/MarkUp/Activity">HTML Activity</a>. </content>

W3C: First Draft of Emotion Markup Language (EmotionML) 1.0 Published

W3C Staff — Fri, 30 Jul 2010 18:00:12 +0000

The <a href="/2002/mmi/">Multimodal Interaction Working Group</a> has published the First Public Working Draft of <a href="/TR/2010/WD-emotionml-20100729/">Emotion Markup Language (EmotionML) 1.0</a>. As the web is becoming ubiquitous, interactive, and multimodal, technology needs to deal increasingly with human factors, including emotions. The present draft specification of Emotion Markup Language 1.0 aims to strike a balance between practical applicability and basis in science. The language is conceived as a "plug-in" language suitable for use in three different areas: (1) manual annotation of data; (2) automatic recognition of emotion-related states from user behavior; and (3) generation of emotion-related system behavior. Learn more about the <a href="/2002/mmi/">Multimodal Interaction Activity</a>. </content>

W3C: Privacy Workshop Participants to Study Data Usage and Handling

W3C Staff — Fri, 30 Jul 2010 18:00:12 +0000

W3C announces organization of a <a href="/2010/policy-ws/">Workshop on Privacy and Data Usage Control</a>, to take place in Cambridge, MA, UA on 4-5 October 2010. Users trust enormous amounts of personal information to a large variety of online services including social network sites, search engines, photo and video sharing services, and hosted email solutions. As those services become ever more tightly integrated, it becomes increasingly difficult to control the spread of information on the Web. Participants will represent a broad set of stakeholders, including researchers, database manufacturers, CRM-system manufacturers, and Social Networking Providers. Participants will study whether there is interest in further work on policy languages and data handling/data usage work within W3C. Anyone may participate in the Workshop; all participants must submit a short <a href="/2010/policy-ws/#paper">position paper</a>. More information about the Workshop is available in the <a href="/2010/policy-ws/">Call for Participation</a>. Learn more about W3C's <a href="/Privacy/">Privacy Activity</a>. </content>

W3C: First Draft of WOFF File Format 1.0 Published

W3C Staff — Fri, 30 Jul 2010 18:00:12 +0000

The <a href="/Fonts/WG/">WebFonts Working Group</a> has published the First Public Working Draft of <a href="/TR/2010/WD-WOFF-20100727/">WOFF File Format 1.0</a>. This document specifies the WOFF font format. This format was designed to provide lightweight, easy-to-implement compression of the font data, suitable for use in conjunction with CSS. Any TrueType/OpenType/Open Font Format file can be losslessly converted to WOFF for Web use (subject to licensing of the font data); once decoded by a user agent, the WOFF font will display identically to the original desktop font from which it was created. Learn more about the <a href="/Fonts/">Fonts Activity</a>. </content>

W3C: Last Call: Cascading Style Sheets (CSS) Snapshot 2007

W3C Staff — Fri, 30 Jul 2010 18:00:12 +0000

The <a href="/Style/CSS/members">Cascading Style Sheets (CSS) Working Group</a> has published a Last Call Working Draft of <a href="/TR/2010/WD-css-beijing-20100727/">Cascading Style Sheets (CSS) Snapshot 2007</a>. This document collects together into one definition all the specifications that together form the current state of Cascading Style Sheets (CSS) as of 2007. The primary audience is CSS implementors, not CSS authors, as this definition includes modules by specification stability, not Web browser adoption rate. Comments are welcome through 15 August. Learn more about the <a href="/Style/">Style Activity</a>. </content>

W3C: Cross-Origin Resource Sharing Draft Published

W3C Staff — Fri, 30 Jul 2010 18:00:12 +0000

The <a href="/2008/webapps/">Web Applications Working Group</a> has published a Working Draft of <a href="/TR/2010/WD-cors-20100727/">Cross-Origin Resource Sharing</a>. User agents commonly apply same-origin restrictions to network requests. These restrictions prevent a client-side Web application running from one origin from obtaining data retrieved from another origin, and also limit unsafe HTTP requests that can be automatically launched toward destinations that differ from the running application's origin. In user agents that follow this pattern, network requests typically use ambient authentication and session management information, including HTTP authentication and cookie information. This specification extends this model in a number of ways.Learn more about the <a href="/2006/rwc/">Rich Web Client Activity</a>. </content>

W3C: W3C Releases Unicorn, an All-in-One Validator

W3C Staff — Fri, 30 Jul 2010 18:00:12 +0000

W3C is pleased to announce the release of <a href="http://validator.w3.org/unicorn/">Unicorn</a>, a one-stop tool to help people improve the quality of their Web pages. Unicorn combines a number of popular tools in a single, easy interface, including the <a href="http://validator.w3.org/">Markup validator</a>, <a href="http://jigsaw.w3.org/css-validator/">CSS validator</a>, <a href="http://validator.w3.org/mobile/">mobileOk checker</a>, and <a href="http://validator.w3.org/feed/">Feed validator</a>, which remain available as individual services as well. W3C invites developers to enhance the service by <a href="http://code.w3.org/unicorn/wiki/Documentation/Observer">creating new modules</a> and testing them in our <a href="http://code.w3.org/unicorn/wiki#DevelopUnicornandValidationServices">online developer space</a> (or <a href="http://code.w3.org/unicorn/wiki/Documentation/Install">installing Unicorn locally</a>). W3C looks forward to code contributions from the community as well as <a href="http://code.w3.org/unicorn/wiki#Feedback">suggestions for new features</a>. W3C would like to thank the many people whose work has led up to this first release of Unicorn. This includes developers who started and improved the tool over the past few years, users who have provided feedback, <a href="http://code.w3.org/unicorn/wiki/Translators">translators</a> who have helped localize the interface with <a href="http://validator.w3.org/unicorn/translations">21 translations</a> so far, and sponsors HP and Mozilla and other individual donors. W3C welcomes <a href="http://code.w3.org/unicorn/wiki#Feedback">feedback</a> and <a href="http://www.w3.org/QA/Tools/Donate">donations</a> so that W3C can continue to expand this free service to the community. Learn more about <a href="http://www.w3.org/Status">W3C open source software</a>. </content>

W3C: The Multilingual Web - Where Are We? Find out at the W3C Workshop

W3C Staff — Fri, 30 Jul 2010 18:00:12 +0000

<a class="imageLink" href="/International/multilingualweb/madrid/cfp"> <img width="98" height="98" src="http://www.w3.org/International/multilingualweb/madrid/mw3-small.png" alt="Multilingual Web logo"/> </a> W3C is organizing a Workshop: <a href="/International/multilingualweb/madrid/cfp">The Multilingual Web - Where Are We?</a>, to take place 26-27 October 2010 in Madrid, Spain. Workshop participants will survey and introduce currently available best practices and standards that help content creators, localizers, language technology developers, browser makers, and others meet the challenges of the multilingual Web. The Workshop also provides opportunities for networking that span the various communities involved in enabling the multilingual Web. <a href="/International/multilingualweb/madrid/cfp#participation">Participation</a> is free and open to anyone. However, space is limited and participants must send an <a href="/International/multilingualweb/madrid/cfp#eoi">expression of interest</a> to the program committee. People wishing to speak should also submit a presentation outline as soon as possible. This is the first of four Workshops being planned by W3C over the next two years as part of the <a href="http://www.multilingualweb.eu/">MultilingualWeb</a> European Project. The first Workshop is hosted by the Universidad Politécnica de Madrid. For more information, see the <a href="/International/multilingualweb/madrid/cfp">call for participation</a>. Learn more about W3C's <a href="/International/">Internationalization Activity</a>. </content>

W3C: HTML Media Capture Draft Published

W3C Staff — Fri, 30 Jul 2010 18:00:12 +0000

The <a href="/2009/dap/">Device APIs and Policy Working Group</a> has published a Working Draft of <a href="/TR/2010/WD-html-media-capture-20100720/">HTML Media Capture</a>. This specification defines HTML form enhancements that provide access to the audio, image and video capture capabilities of the device. The title of the specification changed in this draft (from "The Capture API"). Learn more about the <a href="/2007/uwa/">Ubiquitous Web Applications Activity</a>. </content>

W3C: Last Call: Web Services SOAP Assertions (WS-SOAPAssertions)

W3C Staff — Fri, 30 Jul 2010 18:00:12 +0000

The <a href="/2002/ws/ra/">Web Services Resource Access Working Group</a> has published a Last Call Working Draft of <a href="/TR/2010/WD-ws-soap-assertions-20100713/">Web Services SOAP Assertions (WS-SOAPAssertions)</a>. This specification defines two WS-Policy assertions that can be used to advertise the requirement to use a certain version of SOAP in message exchanges. Comments are welcome through 27 August. The group also published <a href="http://www.w3.org/TR/2010/NOTE-ws-resource-transfer-20100713/">Web Services Resource Transfer (WS-RT)</a> as a Note today. That specification defines extensions to WS-Transfer primarily to provide fragment-based access to resources. Learn more about the <a href="/2002/ws/">Web Services Activity</a>. </content>

W3C: Last Call: Mobile Web Application Best Practices

W3C Staff — Fri, 30 Jul 2010 18:00:12 +0000

The <a href="/2005/MWI/BPWG/">Mobile Web Best Practices Working Group</a> has published a Last Call Working Draft of <a href="/TR/2010/WD-mwabp-20100713/">Mobile Web Application Best Practices</a>. The goal of this document is to aid the development of rich and dynamic mobile Web applications. It collects the most relevant engineering practices, promoting those that enable a better user experience and warning against those that are considered harmful. The Mobile Web Best Practices Working Group does not expect more substantive changes at this point and expects to be able to transition directly to Proposed Recommendation at the end of the Last Call review period. Last call comments welcome before Comments are welcome through 06 August 2010. Learn more about the <a href="/Mobile/">Mobile Web Initiative Activity</a>. </content>

W3C: RDF Workshop Report Emphasizes Support for JSON, Turtle, Other Formats

W3C Staff — Fri, 30 Jul 2010 18:00:12 +0000

The last week of June, participants at the <a href="/2009/12/rdf-ws/">W3C RDF Next Steps Workshop</a> concluded that support for JSON, Turtle, and for "Named Graphs" are top priorities for any future work on RDF. Participants also highlighted the importance of compatibility with existing deployment. Read about these and other topics in the <a href="/2009/12/rdf-ws/Report.html">Workshop report</a>. To join the discussion about organizing future work on RDF, please share your thoughts on the <a href="mailto:semantic-web@w3.org">Semantic Web Interest Group</a> mailing list (with a copy to the separate <a href="mailto:www-rdf-comments@w3.org">RDF Comments list</a>). W3C thanks the <a href="http://bioontology.org/">National Center for Biomedical Ontology</a> at Stanford, Palo Alto, USA, for hosting the Workshop. Learn more about the <a href="/standards/semanticweb/">Semantic Web</a>. </content>

W3C: Last Call: Authoring Tool Accessibility Guidelines (ATAG) 2.0, Implementing ATAG 2.0

W3C Staff — Fri, 30 Jul 2010 18:00:12 +0000

The <a href="http://www.w3.org/WAI/AU/">Authoring Tool Accessibility Guidelines Working Group</a> has published Last Call Working Drafts of <a href="/TR/2010/WD-ATAG20-20100708/">Authoring Tool Accessibility Guidelines (ATAG) 2.0</a> and the companion document <a href="/TR/2010/WD-IMPLEMENTING-ATAG20-20100708/">Implementing ATAG 2.0</a>. ATAG defines how authoring tools should help developers produce accessible web content that conforms to Web Content Accessibility Guidelines (WCAG) 2.0. The ATAG documents also describe how to make authoring tools accessible so that people with disabilities can use them. Comments are welcome through 2 September 2010. Read the <a href="http://lists.w3.org/Archives/Public/w3c-wai-ig/2010JulSep/0002.html">invitation to review the ATAG 2.0 Last Call Working Draft</a> and about the <a href="http://www.w3.org/WAI/">Web Accessibility Initiative (WAI)</a>. </content>

W3C: For Review: Updated Techniques for Web Content Accessibility Guidelines (WCAG)

W3C Staff — Fri, 30 Jul 2010 18:00:12 +0000

The <a href="http://www.w3.org/WAI/GL/">Web Content Accessibility Guidelines Working Group</a> today requests review of draft updates to Notes that accompany WCAG 2.0: <a href="http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/">Techniques for WCAG 2.0 (Editors' Draft)</a> and <a href="http://www.w3.org/WAI/GL/2010/WD-UNDERSTANDING-WCAG20-20100708/">Understanding WCAG 2.0 (Editors' Draft)</a>. Comments are welcome through 9 August 2010. (This is not an update to WCAG 2.0, which is a stable document.) To learn more about the updates, see the <a href="http://lists.w3.org/Archives/Public/w3c-wai-ig/2010JulSep/0003.html">Call for Review: WCAG 2.0 Techniques Draft Updates e-mail</a>. Read about the <a href="http://www.w3.org/WAI/">Web Accessibility Initiative (WAI)</a>. </content>

W3C: Contacts API Working Draft Published

W3C Staff — Fri, 30 Jul 2010 18:00:12 +0000

The <a href="http://www.w3.org/2009/dap/">Device APIs and Policy Working Group</a> has published a Working Draft of <a href="http://www.w3.org/TR/2010/WD-contacts-api-20100701/">Contacts API</a>. This document defines the high-level interfaces required to provide access to a user's unified address book, which may source address book data from several sources, both online and locally. Learn more about the <a href="http://www.w3.org/2007/uwa/">Ubiquitous Web Applications Activity</a>. </content>

Vitamin: PHP Login Form Part 1 [Video Tutorial]

Keir Whitaker — Thu, 29 Jul 2010 12:00:41 +0000

For our second free weekly helping from the Think Vitamin Membership video library we Jim looks at how to create the perfect login form using PHP.

Don’t forget to check out the video library for free videos as well as learning more about our new membership service.

QuirksMode: Four mobile links

Thu, 29 Jul 2010 11:11:54 +0000

Here are four interesting mobile articles that caught my eye in the past 24 hours:

Your mobile app is spying on you. About the danger in free apps.

The study also found that a large proportion of apps contain third-party code with the capability to interact with sensitive data in a way that may not be apparent to users or the developers of the apps themselves. The third-party code is generally used for advertising or analytics. The project found that 47 percent of free Android apps included this third-party code, while 23 percent of free iPhone apps use it. Third-party code represents a security risk because it is difficult to update (and patch a vulnerability) on a global basis. Apple changed its terms of service for the iPhone recently because of its concerns about what third-party analytics and other companies were doing with private data.
Nokia’s JavaScript Peformance Best Practices. Contains a lot that was taken from Steve Souders’s research and common knowledge, but also a few things I’ve never heard before. I’d really have to do an evaluation of some of the practices. Also contains a few ugly-but-necessary tricks for Symbian WebKit (S60).
Also from Nokia: Introducing Ovi Browser Beta for Series 40. Nokia, too, has produced a mini-browser that relies on a server for the actual rendering and sends out the fully-rendered page, just as Opera Mini does. Now I need to lay my hands on an S40 device so that I can test it.
From Bruce Lawson at Opera, finally, comes Mobile-friendly: The mobile web optimization guide with useful tips and tricks for making your website mobile-friendly.

[...] mobile users are in a hurry; they're on the go and want to perform one specific task and then finish. A common example cited is that of a restaurant site. The mobile user wants to find the location, the menu and the opening hours so, the argument goes, the mobile site should contain this and nothing else.

This is a good argument, but it's only half true. If it were 100% true, what would be on the "full" website? Presumably, a movie of the decor, some atmospheric music, animated representations of the house special dishes, and a downloadable menu in some fancy font. The fallacy here is that users of desktop computers are not task-focussed and have time to waste on an immersive branding experience.

Wisdump: Anorexic vs. obese layouts: you can't please everyone, but you should try

Sophia Lucero — Thu, 29 Jul 2010 04:19:58 +0000

This comes as a surprise. Aux of Cogent Metal is vehemently against webpages that have narrow layout widths. And I thought web designers are now more worried about the opposite: the wide layouts that whip out the horizontal scrollbars in resolutions narrower than 1024×768.

This is another proof that you can’t guess every possible reaction to a design pattern. In this case Aux would rather have wide layouts because it would mean a larger area to present content. But what can you do about someone just like Aux, but who believes the complete opposite?

Elasticity is tricky

The ideal solution to please both lovers and haters of the narrow look would be to construct an elastic layout. But images are the number one obstacle. They have fixed dimensions and look horrible when resized using HTML or CSS attributes—please, don’t go there, it’s just atrocious. Other solutions are just for decorative purposes, not for every image on the page.

Ads, widgets, and plug-ins all tend to have fixed dimensions as well. It’s a chicken-and-egg thing: designers resort to fixed layouts because they can’t resize all those fixed objects, and all those objects are fixed because their creators assume they’ll be placed in fixed layouts anyway. That, and there hasn’t been a move towards flexible anything. Is it because we fear the unpredictability of flexibility? If it were possible to have webpage elements with flexible dimensions, would we use them, or still go for the fixed-dimension ones?

A completely flexible layout width isn’t that appealing, either. In larger screens the lines of text will be so long that it becomes difficult to read. Every layout option has its advantages and disadvantages. You have to pick one and accept that you’ll piss someone off one way or the other.

Custom-tailored user experience

However, you should try to please as many people as possible especially if your website is any of the following:

Very popular (e.g., CNN)
Text-heavy (e.g., Wikipedia)
Requires registration (e.g., My Yahoo!)

Don’t stop with the layout width. The general ability to customize is important. See what MSNBC and BBC have done. Users can control the type of news that appears, the order in which the news sections appear, the complexity of the page layout, the text styles (from color to letter spacing), and so on. It’s the empowerment you bring to the audiences that tells them they are highly valued individuals.

Design is about presenting information in the best possible way. Unfortunately there is no single way that is considered the best as long as someone other than the designer is experiencing that design. Although more difficult to implement, websites can let users choose that experience. If you can help it, let them.

ajaxian: Canto.js: An Improved Canvas API

Michael Mahemoff — Thu, 29 Jul 2010 04:10:24 +0000

Javascript author extraordinaire David Flanagan released Canto.js recently, a lightweight wrapper API for canvas, introduced here and documented at the top of the source code. Example:

PLAIN TEXT

JAVASCRIPT:

canto("canvas_id").moveTo(100,100).lineTo(200,200,100,200).closePath().stroke();

Notice three things:

canto() returns an abstraction of the canvas - a "Canto" object.
As with jQuery and similar libraries, there's method chaining; each method called on a Canto also returns the Canto.
lineTo() has been extended to support multiple lines being drawn in a single call.

Instead of setting the ink properties and then painting it, you can do it all in one step:

PLAIN TEXT

JAVASCRIPT:

canto("canvas_id").moveTo(100,100).lineTo(200,200,100,200).closePath().stroke({lineWidth: 15, strokeStyle: "red"});

And plenty more syntactic sugar - check out the API in the source code comments. Sweet!

Thanks @pkeane.

Vitamin: Around the Web: CSS3 Animations, Agile + UX, Processed Identity

Chrissie Brodigan — Thu, 29 Jul 2010 02:38:01 +0000

Hey there!

It’s Wednesday, so this mid-week roundup is devoted to all things business and development.

Some links are newsworthy, some retweeted across Twitter, and others just meet our "awesomeness"� requirement, and regardless we hope you'll enjoy them. Without further delay:

Start Experimenting With CSS3 Animations (via@leemunroe)
Arggggh! Subterfuge. Why Design Contests Are Bad (via Core77)
Open Source Your Career (via Stefan Koopmanschap)
Agile + UX, Remembering What a Team is Supposed to Be (via Thinking & Making)
If you’ve ever worked on a brand identity or run into challenges you’ll enjoy “Processed Identity,” which s the story of how you got “there”

Wildcard: Get to Know an Internet Commenter (via McSweeny’s)

Please shoot me links to projects your working on or awesome things you’ve released! news@thinkvitamin.com

Handpicked by,

Chrissie (@tenaciouscb)

Vitamin: PHP Basics: Installation [Video Tutorial]

Keir Whitaker — Wed, 28 Jul 2010 11:21:48 +0000

It’s Wednesday and time for our first free weekly helping from the Think Vitamin Membership video library.

Today Jim looks at getting started with the popular programming language PHP. In this 8 minute video he shows you how to install PHP and write your first lines of PHP code.

QuirksMode: Opera’s problems on mobile

Wed, 28 Jul 2010 10:07:11 +0000

In the mobile browser space all the advanced browsers are based on WebKit. That’s fine — WebKit is an excellent rendering engine — but if all browsers were based on WebKit I would start to worry about a monoculture. At least some browsers should be based on other rendering engines, as far as I’m concerned.

The only serious mobile candidate for “other rendering engine” is Opera. But I’m starting to wonder whether it can keep up with the WebKit browsers. With the recent release of Samsung Dolfin Opera Mobile has firmly dropped from third-best to fourth-best mobile browser on my list.

The problem is not that Opera isn’t innovating. It is. But I’m starting to wonder about the direction that innovation is taking.

Witness the recent release of Opera Mobile 10.1 beta for Symbian (on my 40th birthday; thanks, guys). I went through the press release, which highlights the following changes:

Geolocation is now supported (although it doesn’t give the coordinates in my test page). That’s cool; it’s definitely something that’s extremely important on mobile.
Vega graphics library and Carakan JavaScript engine. That’s fun to have, but I’m not sure if it’s the most important step Opera could have taken right now. I’ll get back to this.
Various improvements to the user interface.

And that’s it, according to the press release. (border-radius is supported, maybe some other stuff too, and there will be some bug fixes here and there, but I haven’t yet studied it sufficiently to give you a full list.)

Relative importance

Nowadays all desktop browsers are innovating like mad in their JavaScript engines. For about a year and a half or so, significant improvements in JavaScript speed have been the Holy Grail of browser making, and every new release of every browser now routinely claims to be the fastest browser available.

(So routine has this claim become that I do not believe any of them any more. Besides, as far as I can tell they’re all testing JavaScript Core speed, while the biggest bottleneck is the speed with which DOM changes are made.)

Now on desktop this is a very important development. On mobile it’s also important, but I feel there are several other topics that are even more important than JavaScript speed, and that Opera is ignoring these topics.

Point is, a super-fast JavaScript engine is relatively worthless if you can’t properly set up a JavaScript-heavy interface. And the very first requirement for a JavaScript-heavy interface is that you always know exactly what the user is doing, so that you can react to his actions naturally and great UX is born.

It’s in the latter part of that equation that Opera Mobile has serious problems. I feel that, while innovating in JavaScript engines, Opera is forgetting basic mobile functionality without which a fast JavaScript engine is pointless.

Touch and viewport

There’s a reason I started my foray into mobile browsing by studying the touch events and the viewport dimensions. These two functionalities are absolutely vital to building compelling mobile interfaces.

The touch events allow us to follow exactly what the user is doing to the touchscreen. Without these events you can only detect whether the user clicks somewhere. That is enough for some interfaces, but others will definitely want to react to more subtle actions from the user.

The viewport dimensions are important for knowing how much of your site the user is currently seeing on his screen. An example will clarify why this is important.

I’m currently working on a little side project that involves writing the perfect JavaScript touch-scroll interface. This presupposes the touch events: without them it’s absolutely impossible to create a compelling UX.

However, I want several scrollable areas on the same page, and with that comes the problem of deciding when to allow a user to scroll. If the user has zoomed in and sees a little bit of one scrollable area on the edge of his screen, it makes sense not to scroll that area when he touches it, because it might confuse him. Instead, we should wait until the scrollable area covers most of the screen before allowing a scroll action. My prototype with this behaviour works pretty intuitively.

However, in order to know whether the scrollable area is on the screen I must be able to read out the dimensions of the visual viewport. I need to know which part of the page the user is currently viewing, compare it to the scrollable area, check their coordinates, and decide whether the user is allowed to scroll. That’s something that few browsers support right now.

Android and Samsung support the touch events, but not the visual viewport dimensions. Symbian, BlackBerry and IE support the visual viewport dimensions, but not the touch events. All other browsers, including Opera Mobile, support neither. So this script only works on the iPhone, which is the single browser to support both.

So this interface, which I feel is an example of a mobile-specific UX, will not work on Opera Mobile, regardless of the speed of its JavaScript engine. That’s what I mean when I say that I’m wondering about Opera’s direction of innovation.

Opera Mobile simply must support the touch events and the viewport dimensions.

Zooming

But Opera Mobile has an even larger problem, and that is zooming. Basically it has the worst zooming functionality of any mobile browser I tested. It seems Opera ignored the emerging standard for touch-based zooming, and instead created its own system. That’s fine, as long as the system works. But it doesn’t.

So what exactly is wrong with Opera’s zooming? Basically everything.

Two levels

Opera has only two zooming levels: in and out. Initially you see the entire page, just as on all other mobile browsers. When you zoom in, however, you go to one single pre-defined zooming level, and once you’ve arrived there your only option is to zoom out again.

This behaviour is not unique to Opera Mobile. Many other second-tier mobile browsers, such as Symbian WebKit on touchscreen Nokias, or IE, have only two zoom levels.

But there are two other characteristics that make the Opera zooming experience uniquely lousy.

Pre-emptive narrowing of text

Opera kind of pre-emptively narrows your text into columns that fit snugly in the screen when you zoom in. Although that’s excellent behaviour to display when the user actually zooms in (as Android does), doing this beforehand makes no sense and has the ability to destroy your page’s graphic design.

Here’s my compatibility master page as it should display on mobile (Dolfin on Samsung Wave). Note that the text in the table stretches all the way from left to right, as it should:

And here is the same page on Opera Mobile 10.10 (Nokia N97). Here the text in the table is narrowed to the width Opera is going to take later on, when you zoom in:

In this particular case I don’t mind much, but this feature has the ability to completely destroy a well-designed page. As far as I know you can’t do anything against this effect and will have to accept the damage it does to your page.

Single tap

But by far the worst feature of Opera’s zoom is the user interaction. On touchscreens an industry standard is emerging for zooming. You either pinch-zoom or you double-tap. Some browsers don’t support pinch-zoom, but the double-tap works pretty well, too.

However, Opera in its wisdom uses not a double-tap but a single-tap interface. Tap once when zoomed out and you will zoom in on roughly the area you tapped on.

This is terrible. In order to understand why, take a look at my Touch test page. It’s fully zoomed-out:

This is how I designed the page: I want it to be usable even fully zoomed-out. Thus I can load the page, hit Record, and record an event sequence of my choice.

But what happens in Opera Mobile when I hit Record with a single tap in order to start recording? It. Bloody. Zooms. In! That makes my test page much harder to use.

To be fair, Opera Mobile 10.10 does not zoom at all in pages that have a <meta viewport>, as my test page has. That solves this particular issue, but I feel it’s still a stop-gap solution. All other browsers do allow the user to zoom in on a <meta viewport>-enhanced page. (Some even allow you to zoom out.)

Opera’s problems

Concluding, Opera Mobile has a serious zoom problem that must be addressed in addition to the touch event and viewport dimension problem.

I feel that addressing these issues is more important than yet another faster JavaScript engine or yet another UX upgrade. Besides, as long as zoom remains lousy the UX can be upgraded only so much. Zooming is a fundamental part of the mobile UX; without it many other innovations just don’t make sense.

So in order to remain relevant on the highest tier of mobile browsing, Opera will have to concentrate on three things:

Fix zooming: double-tap interaction, many more zoom levels, no pre-emptive narrowing of text columns.
Support the touch events.
Allow us to read out the viewport dimensions.

I more-or-less expect the busy engineers in Oslo to be working on these problems, and I assume that the next major Opera Mobile upgrade will bring significant improvements here.

If it doesn’t, I’m afraid Opera is out of the race for the top spot. That is not necessarily bad: it could always forget about the top tier and instead concentrate on the low-end smartphone market. Right now Opera Mobile is available only for Symbian and Windows Mobile, and on those operating systems it’s the best available browser.

Without a serious upgrade of mobile-specific functionality ruling this second tier is the best Opera can hope for. The top tier will be WebKit-only.

ajaxian: YUI 3.2.0 preview release 1 "� touch events support, transitions and browser-specific loading

Chris Heilmann — Tue, 27 Jul 2010 18:34:02 +0000

Over at the the YUI blog the team just announced the preview release of YUI 3.2.0. YUI3 now has some interesting new features that the team wants you to try and tell them if they work out for you. The changes to the already very powerful library are quite ambitious:

Touch event support for mobile interfaces including flick and move gestures
Browser capability loading - which means that every browser gets the least amount of code necessary to make it work
Transition support for the animation module - meaning only browsers that don't support CSS3 transitions get the JavaScript animation fallback
An update to the CSS grids to allow for more flexible layouts
A ScrollView widget similar to the one in Apple iOS
The uploader has been transitioned over from YUI2 to YUI3

So check out what is on offer and give the YUI team feedback on what would be nice to have and what is broken. In their own words:

The goal of a preview release is to make it as easy as possible for all of us in the community to evaluate progress of the upcoming release and provide feedback. Please take some time to test 3.2.0pr1 and let us know what you find by filing tickets in the YUI 3 bug database marked as "Observed in version"� 3.2.0pr1. We'll do our best to address preview-release questions on the YUI 3 Forums, too.

There are three ways to get started with the preview release: YUI 3.2.0pr1 is available on the CDN via the 3.2.0pr1 version tag "� so you can reference preview-release files like http://yui.yahooapis.com/combo?3.2.0pr1/build/yui/yui-min.js. If you switch to this seed file for the preview release, all subsequent use() statements will continue to load YUI 3.2.0pr1. Or You can download the full YUI 3.2.0pr1 from YUILibrary.com, including source code and examples for all components. Or you can simply explore the functioning examples roster.

Vitamin: Recurring Billing For Web Apps

Kieran Masterton — Tue, 27 Jul 2010 13:00:55 +0000

Increasingly web application developers and entrepreneurs are turning to the “Software As A Service” (SaaS) model to monetize their products.
Together with this growth has come the need for reliable recurring billing systems and in turn a number of enterprising folks have built said solutions and fittingly used the SaaS model to monetize their efforts.

In this article we will look at how these services work, why you’d want to use them, the various options available, and how they differ from one another. Hopefully it should give you a better idea of which service is right for you and how you plan to use it.

Why do I Need this Service?

There are many tools that are making web application development easier and easier, whether that be development frameworks such as Rails and Django or services like Amazon Web Services and Google App Engine, recurring billing systems are no different.

Building a billing system can be a complicated process with issues such as how to handle failed transactions, when and how to recharge cards, and not to mention all the data protection issues surrounding storing financial information and PCI compliance etc. These services allow you to abstract these concerns and let you focus on building the software you care about.

How do They Work?

The services all have a number of core functions in common. They provide a web application interface where you can create different products and configure pricing options. The service then deals with taking and storing your customer’s credit card details (normally with a PCI compliant third-party).

The information about customers, products and subscriptions is then exposed via a secure API which allows you to hook your app into the service. A fairly simple, elegant and, in my experience, reliable solution to something that could potentially be a major headache for app developers.

Essentially as a developer you have two options:

Option One

You choose to forward paying customers to the service’s hosted payment pages. This is the quickest and simplest way to get started. These pages are secure and accept query string parameters to pre-populate fields such as name and email address.

Successful payments will then be forwarded to a callback URL and any change to a subscription’s status will be posted back to your app via a post-back URL.

Both of these URLs are specified by you in the product settings of the billing service. Obviously, you would be mad not to validate the callback with a API query and likewise you will also need to check the nature of the subscription status change upon post-back notification.

Option Two

The process is almost identical to option one, however, you do not send users to the service’s hosted page to take payment. Your application collects (but does not store) all payment details and that data is then delivered to the billing service via their API.

In this instance the onus is upon you to take the user’s credit card details securely and handle the API’s response appropriately. However, the obvious benefits of this option is that the user’s experience is seamless, you have complete control over user interface design and user’s are unaware you’re using an external billing service.

Billing Systems vs. Payment Gateways

Amidst these technical decisions it is also important remember that these billing services are not payment gateways, they do not carry out the card transitions. They purely deal with the business logic of charges, re-charges, charge backs and data storage. In order to charge the card and for the money to end up in your account the billing service provider hooks into the API of your payment gateway of choice.

This means that it is important to check which payment gateways these service providers support. Some support more than others and until recently some have had a very limited choice of gateways.

Some common payment gateways include:

There are also differences in these gateways and it is important to choose the right one for you and the billing service you choose.

Something to consider is that most of the gateways mentioned above require a merchant account which you would have to arrange with your bank. However, a lot of people avoid this by using Paypal Payments Pro where the money is transfered into a Paypal account ready for you to withdraw.

If you’d like to know more about merchant accounts hear what Ryan has to say about his experience in this arena on Think Vitamin Radio Episode 7.

What’s on Offer?

There are a good range of providers to choose from and unlike some services they do vary in their cost, features and pricing model. Here’s a breakdown of a few of the big players in the space.

Chargify

Chargify is seemingly the solution with the richest set of features and the lowest barrier to entry. They offer a free account which is limited to 50 paying customers plus 1,000 non-paying customers.

Their pricing model is clearly designed with the thought that those first 50 customers are the hardest to acquire and once you have those customers paying X amount per month you can afford to pay for their higher volume service.

These start from $49 a month for up to 500 customers and is graduated there on up to $2,499 per month for unlimited customers. As a result of these graduated monthly fees Chargify does not add any per-transaction cost, so within their pricing brackets your costs are fixed.

The people behind @chargify on Twitter are extremely helpful both in explaining their own service and in offering advice about merchant accounts and receptive banks in both the UK and USA.

This is unsurprising as Chargify is brought to you by the guys behind Grasshopper and if you’re a Rails person it is also worth noting that Chargify’s CEO and Founder is Lance Walley who was also Co-Founder of Rails hosting provider Engine Yard. Both these companies are known for their excellent software and, in my experience, great customer service which bodes well for Chargify.

http://chargify.com/

Spreedly

Spreedly is a younger service and therefore less feature rich. For example, I expressed an interest in charging a set up fee. A one-off fee that is only charged upon sign up. This can be useful to those services that have a fixed overheads for each user who signs up and something that’s easy to set up on Chargify.

However, Spreedly don’t currently offer this feature, but they say it is something that they are keen to do in the future. Likewise, at this point they don’t seem to have the choice to create add-ons for customers to add to their purchase at point of sale. Again, this is very useful for SaaS businesses offering bolt-on services.

Spreedly also takes a slightly different approach to Chargify in terms of pricing. They have a flat-rate monthly charge of $19 but also take 20c or 2% (whichever is the lower amount) of each transaction.

As with Chargify this pricing model scales with your business and means that at times Spreedly could be considerable cheaper than Chargify. That said, there are also points of customer volume where Spreedly’s costs will exceed Chargify’s. Plus with Chargify the frequency of your payment transactions is not an issue, if you want to charge users every 14 days you can at no extra cost whereas this would prove an expensive exercise with Spreedly.

A great benefit of Spreedly is the quantity of payment gateways they support. They are clearly focusing on simplicity and their support for gateways which is by no means a bad thing. As with Chargify the folks behind @spreedly were extremely helpful via Twitter and found my questions about their service without the need for a direct @ message. They were happy to answer questions and offer alternative approaches to features that weren’t available yet. In short, Spreedly is definitely worth a look if your current needs are simple and you like the idea of a per-transaction cost.

http://spreedly.com/

CheddarGetter

First up – what a name – CheddarGetter definitely wins in the name game. However, how does it stand up against Chargify and Spreedly. Well, in terms of features CheddarGetter definitely rivals Chargify and exceeds Spreedly. However, their pricing structure is different again. Like Chargify they have graduated montlhy charges based on customer volume with no transaction fees.

As with both Spreedly and Chargify @cheddargetter offer phenomenal service via Twitter. Mention the name CheddarGetter in the context of a question and they will find you and offer support. This proactive approach seems to be the norm is this space but we shouldn’t forget how rare it is to get this kind of customer service.

The major downside of CheddarGetter right now is its lack of payment gateway integration. The limited list of gateways includes Network Merchants and Authorize.net but no Paypal Website Payments Pro for those of you who don’t want to deal with getting a merchant account with your bank. That said, with some more payment gateway integration CheddarGetter has real potential.

https://cheddargetter.com/

But How do I Choose?

As you can see the billing services spaces has quite a spread of different pricing models so they can be hard to compare in terms of price and work out features vs. cost per customer vs. potentially cost per transaction with Spreedly.

Chad Glendenin has an excellent comparison of the pricing of these services including graphs which map customer growth vs. cost of service for all these of the providers I’ve mentioned. These are extremely useful in demonstrating how these services actually compare in terms of price and highlights the customer volume markers where favour shifts from one service to another. He also provides his Python script for generating these figures so that you can run the numbers with your own payment frequencies and prices.

It’s clear that if you expect a very high quantity of subscribers, meaning 15,000+ customers paying monthly, then Chargify’s features and unlimited plan makes them the obvious choice.

However, if you’re expecting very low volume, or your only taking annual payments and this is something you’re setting up on the side of a day job, Spreedly’s per-transaction model and simplicity would suit your needs. However, these are both extreme ends of the spectrum.

Extremes aside, I think this decision is really about features and not price. The costs are marginal compared to whether the service can provide you with what you need. Integration with a billing system while a fairly straightforward process isn’t something that you want to have change after 18 months.

Conclusion

If you’re planning more complicated pricing models, add on products, short payment intervals, or want a metered service where customers pay for their usage then you need to hunt down each service’s feature list and ensure they offer what you need. You are buying simplicity, you’re buying the ability to focus on your own app and abstract the billing logic, make sure the service you choose offers you what you need not just the best price.

Finally, if you guys are using any of these services it would be great to hear from you in the comments about your experiences and your decision making when you chose the service.

QuirksMode: Mobile payments made easy

Tue, 27 Jul 2010 12:06:37 +0000

This is just in: Google seems to be taking steps to allow operator billing. If that’s true it’s huge news.

Note from the outset that the article doesn’t say in so many words that operator billing is coming, although it certainly gives that impression, and plenty of publications translate it as such.

The basic idea of operator billing is very simple: if you want to buy an app, or access to online content, the price is automatically added to your operator bill (or, I assume, deducted from your pre-paid account).

Now I’m not a mobile billing specialist by any means, but I still want to give you an idea of what we’re talking about. If I make any technical mistakes, please correct them in the comments.

The billing process

Just yesterday I made my first Android Market purchase, and although the process was relatively smooth, I still had to fill in all my credit card stuff, make mistakes, being told off, etc. Besides, when I tried to do the same a few months ago, the Android Market rejected my credit card. Why? Probably because the Dutch market wasn’t active yet — but I thought of that only much later. At the moment I was pretty pissed.

Now with operator billing I wouldn’t have all this hassle. I’d just click on whatever I want to buy, give a one-time confirmation “Yes, I do want to spend € 2.39 on this” and be done. When my next operator bill comes around, the € 2.39 will be added to it.

In addition, operators can verify your identity through your SIM card, without you having to do anything. No more hassle with credit card numbers. (In fact, the only parties that have a lot to lose from operator billing are the credit card companies. Expect resistance from them; they’ll probably say it’s unsafe or something.)

Thus operator billing is by far the most user-friendly way of making mobile purchases. That’s what makes it so important. Besides, it also opens up the mobile marketplace to those that do not have a credit card.

A question of identity

However, Google’s rather vague announcement does leave some questions unanswered. No doubt that’s because Google is still figuring out how to answer those questions. But let’s review them anyway:

What do I have to do in order to make a purchase? A one-step system is within reach; I hope it will be implemented.
How will my identity (and thus my bill) be verified?
How will the various parties communicate?

The last question is probably the most important one. If I want to make a purchase through operator billing, there are three parties involved: me, the selling party, and the operator. Somehow, the selling party has to connect to the operator to figure out exactly who I am, and to make a request to put € 2.39 on my bill for my purchase. In addition, the operator has to pay that money (maybe minus a fee) to the selling party.

The JIL 1.2 API gives us some clues as to how this system is going to work. This API, that will eventually be implemented in Vodafone 360 phones as well as, one hopes, many others, has two properties that are meant specifically for operator billing (p. 16):

Widget.Device.AccountInfo.phoneUserUniqueId
Widget.Device.AccountInfo.phoneOperatorName

Thus, when purchase times comes around, the store has some grip on your identity. It will have to send off a communication to the specified operator stating that user with unique ID X wants to make a € 2.39 purchase.

The operator will have to make some effort to verify this information; after all I might be able to hack a phone to send false unique IDs. Thus the operator will probably send me an SMS “Are you sure you want to purchase product X for € 2.39?“ Once I reply to that SMS the purchase is made and downloading can commence.

Still, I hope that the process will become even more user-friendly. The same JIL specification defines a way to send an SMS from a widget. Thus, if I want to purchase something the system could automatically generate an SMS for me and send it off to the operator. Thus the operator will be able to verify my intent by comparing my unique user ID with the SIM card through which the SMS was sent. If they match the purchase is made and downloading can commence.

That’s one step less, and thus more user-friendly. Hell, if it’s implemented correctly I don’t even have to switch to my SMS application. (The operator still has to tell the store “Purchase made, proceed with download.” But a proper system will not bother me with the details.)

Unfortunately the JIL 1.2 spec does not yet contain the methods that will be used for actual payments, nor the exact workflow. Besides, it’s unclear which operators Google is talking to right now. Probably US-based ones, and of those only Verizon is part of the JIL consortium. The others might use other APIs. (Come to think of it, so might Verizon. One never knows.)

Future expansion

Let’s close on a positive note and assume that a system roughly similar to what I describe above will actually be in place in two years or so. Apart from the increased user-friendliness of the purchasing process, what will it bring?

The basic answer is Long Tail. Increased user-friendliness and the scrapping of the requirement to own a credit card may entice more consumers to make a mobile purchase. That would be good.

The real benefit will lie with developers, though. In theory, the system could be set up so that individual developers who offer one or two apps for download on their own site can also use it.

Thus the requirement to offer your wares through one or more app stores might also be scrapped. That could be especially important to cross-platform apps such as W3C Widgets. Whichever phone with whichever operator ends up at the developer’s site, they can all make a purchase, provided they support widgets.

One more nail in the app stores’ coffin would be the opportunity to make in-app purchases; say some articles from a news site or a few new levels for your game. Operator billing is explicitly meant for such purchases, too. And if we can use operator billing in our apps, too, the app store infrastructure is basically not necessary any more.

Picture the following:

I write a news reader app as a W3C Widget. Anyone can download it for free from my website.
If you like my app you can share it with your friends. Just send over the widget via Bluetooth. No more complicated user-unfriendly Send-To-Friend systems necessary.
But how do I make money? By selling access to the actual articles. Every article you want to read costs you, say € 0.02. Alternatively, you can buy a day of unlimited access for, I don’t know, € 0.99.
All the billing is done in-app through the operator. My users never have to do anything beyond saying “Yes, I want to buy this article.”

Where’s the app store in this process? Nowhere. We don’t need it any more. Wouldn’t that be something?

(I should note that although sending widgets via Bluetooth is possible nowadays — I’ve done it — the process is not very user-friendly yet. But this functionality is definitely coming; it’s not a pipe dream.)

Waiting for Google

So I’m impatiently waiting for Google to announce more details. Exactly how will their system work? What does the user have to do? Which operators? Questions, questions.

Anyway, the future of mobile payments has come one step closer.

Vitamin: Around the Web: Inspiredology, Avatars in Motion, & Quite Strong

Chrissie Brodigan — Tue, 27 Jul 2010 03:40:30 +0000

Hey there!

It’s Monday, so this roundup is devoted to all things web design (ux, photo, illustration, art, graphics, CSS, jQuery, tutorials, and more). Some links are newsworthy, some retweeted across Twitter, and others just meet our "awesomeness"� requirement, and regardless we hope you'll enjoy them. Without further delay:

Ever wonder what avatar development looks like when it gets really really good? Tiny Speck’s Glitch released a perfect & highly fun video about this very thing (via @playglitch)
Inspiredology launches a fun redesign (anticipate some mad scientist quirk!)
This might be the best read you read this week. “A Real Web Design Application” (via @jasonsantamaria)
A fun find on Pinterest, Art & Design – Type & Love
5 creatives of the female variety, all based in Chicago, have united as @quite_strong (you’ll enjoy the quirktastic Twitter background) & indeed they are worth a follow, great things are ahead from this group

Wildcard: Trent Walton shared a little tip on how he and @yarcom design rounded avatars on Design-Swap, and a bonus? Dan Mall & Brian Hoff have swapped!

Please send me links to your projects, so we can help promote you and your work!

Handpicked by,

Chrissie @tenaciouscb

ajaxian: Canvas Color Cycling

Michael Mahemoff — Tue, 27 Jul 2010 00:21:55 +0000

Interest in Canvas, as well as mobile apps, has led to a renaissance of old-school 8-bit graphics. Joe Huckaby of Effect Games has been playing around with color cycling, leading to some stunning effects.

Anyone remember Color cycling from the 90s? This was a technology often used in 8-bit video games of the era, to achieve interesting visual effects by cycling (shifting) the color palette. Back then video cards could only render 256 colors at a time, so a palette of selected colors was used. But the programmer could change this palette at will, and all the onscreen colors would instantly change to match. It was fast, and took virtually no memory.

There's a neat optimization going on here too: instead of clearing and redrawing the entire scene with each frame, he only updates the pixels that change:

In order to achieve fast frame rates in the browser, I had to get a little crazy in the engine implementation. Rendering a 640x480 indexed image on a 32-bit RGB canvas means walking through and drawing 307,200 pixels per frame, in JavaScript. That's a very big array to traverse, and some browsers just couldn't keep up. To overcome this, I pre-process the images when they are first loaded, and grab the pixels that reference colors which are animated (i.e. are part of cycling sets in the palette). Those pixel X/Y offsets are stored in a separate, smaller array, and thus only the pixels that change are refreshed onscreen. This optimization trick works so well, that the thing actually runs at a pretty decent speed on my iPhone 3GS and iPad!

Vitamin: Exception Handling in PHP5

Lorna Jane Mitchell — Mon, 26 Jul 2010 13:00:30 +0000

This article follows on from my earlier posts, introducing OOP in PHP, taking a closer look at OOP concepts in PHP, and also covering the various magic methods on offer in PHP 5. We’ll now move on to look at exceptions, which is how PHP 5 handles errors in an object-oriented way.

What are Exceptions?

Exceptions are the PHP 5 way of flagging up an unexpected event. They contain an information message, and can be extended just like any other object. Exceptions are thrown rather than warnings in newer PHP extensions, although you do still see extensions returning errors.

When an exception is thrown, we either catch it where it happens, or it causes the code to return to its calling context. If it isn’t caught there, it returns again, and so on. As usual it is easier to explain with examples than words!

Here is an example in which DateTimeZone objects are created, first with a valid timezone string of ‘Europe/Amsterdam’, then another with an invalid timezone ‘nonsense’:

$timezone = new DateTimeZone('Europe/Amsterdam');
var_dump($timezone);
 
$timezone2 = new DateTimeZone('nonsense');

As the documentation explains, DateTimeZone throws an exception when called with unexpected data. This indeed happens if you run the above script, and the exception appears as an error message from PHP, looking something like this:

Exception: DateTimeZone::__construct(): Unknown or bad timezone (nonsense) in /...../exception1.php on line 6

We don’t want our entire application to stop and spit out errors over a nonsense timezone, and working with exceptions means we can do so much more with these situations than we can with errors. We “catch” exceptions and can use the information in the exception itself and in the context of the current scope to decide how best to react.

This is a great improvement on the previous situation of having a few different error levels and only being able to choose whether to display, log or ignore each level as was the situation before PHP 5.

Handling Exceptions

We handle exceptions with a try/catch block like this:

try {
    $timezone2 = new DateTimeZone('nonsense');
    echo "time!";
} catch(Exception $e) {
    echo "Oops!  Something bad happened!";
    print_r($e);
}

The “try” bit goes around the code that you would normally write, but which contains operations which can cause an exception. The “catch” bit states what kind of exception to catch, and contains the code to execute if we do catch anything.

If you ran this script with a valid timezone as the argument to the DateTimeZone constructor, you would see the “time!” output and never enter the code inside the “catch” block. However in our example, an exception will be caused and so we jump straight into this block, without echoing “time!”.

This is a fairly key concept – the code in the try block actually stops and we jump into the catch block and start executing from there. Any code after the point at which the exception is throw simply isn’t run.

Inside an Exception

Exceptions can hold all sorts of information. If we inspect our Exception thrown by DateTimeZone’s constructor using print_r, we’d see something like this:

Exception Object
(
    [message:protected] => DateTimeZone::__construct(): Unknown or bad timezone (nonsense)
    [string:private] =>
    [code:protected] => 0
    [file:protected] => /home/lorna/data/personal/publish/thinkvitamin/exceptions/exceptions2.php
    [line:protected] => 4
    [trace:private] => Array
        (
            [0] => Array
                (
                    [file] => /home/lorna/data/personal/publish/thinkvitamin/exceptions/exceptions2.php
                    [line] => 4
                    [function] => __construct
                    [class] => DateTimeZone
                    [type] => ->
                    [args] => Array
                        (
                            [0] => nonsense
                        )
 
                )
 
        )
 
    [severity] => 2
)

Walking through the object, there are many useful elements here:

message This contains a useful and relevant information message
code By default this is zero but we can use this to include a numeric error code with our exception
file Path to the file where this exception was thrown
line Line number where the exception was thrown
trace This is the stack trace, so you can see the stack of calls which were made before this exception was thrown

This is all valuable information and we can use it to inform how we handle errors in the catch block in our code. In addition we’ll take a look at how we can set these ourselves by making our own exceptions a little later on.

Throwing Exceptions

It isn’t only PHP itself that can throw exceptions, we can use exactly the same functionality in our own code. Here is a really simple example, taken directly from the PHP manual itself, of how to throw an exception manually.

function inverse($x) {
    if (!$x) {
        throw new Exception('Division by zero.');
    }
    else return 1/$x;
}

We simply throw a new Exception object, that we create as we need it. The string passed into the constructor becomes the object’s message property, and we can also pass a second argument to the constructor if we want to set the code property as well.

It is usual to throw exceptions in functions or methods, and then catch them from the location they are called – this lets the calling code decide what to do in the context of what it intended and is much more flexible than simple errors or having your methods return false and set an error string somewhere, which I’m sure is how I solved this before exceptions were introduced in PHP 5.

Extending Exceptions

The Exception object by itself is great, but we can extend it so that we can return additional information and different types of exceptions – so if one of a number of different scenarios actually happens, we can respond differently. Consider this script and in particular the takeTwoNumbers function:

class BigNumberException extends Exception { }
class FavouriteNumberException extends Exception { }
 
function takeTwoNumbers($a, $b) {
    if($a > 15 || $b > 15 || ($a + $b) > 20) {
        throw new BigNumberException('Keep it simple with smaller numbers');
    } elseif($a != 3 && $b != 3) {
        throw new FavouriteNumberException('But three is my favourite number!');
    } else {
        return $a + $b;
    }
}
 
try {
    echo takeTwoNumbers(3,9) . "\n";
    echo takeTwoNumbers(4,16) . "\n";
    echo takeTwoNumbers(7,5) . "\n";
} catch(Exception $e) {
    echo $e->getMessage() . "\n";
}

The function accepts two numbers, checks the values, and if there are any problems, throws a relevant exception. If the values are OK (and yes, this is a totally contrived example, in an effort to illustrate the concept without any complicating factors like the real world getting involved!) then the function simply adds them together and returns them.

Our calling script calls the function 3 times, with different number sets. The first one executes fine and the numbers get added together. However the second includes a large number and so an error is thrown, causing our code to jump to the “catch” block, and so the third function call is never made.

Although we declared empty classes to extend Exception here and so only the class name changed, you can do all sorts of things to help record the information you need. We would set custom error messages here (remember the helpful error message returned by DateTimeZone?), set error codes, or even set new properties of our own.

It depends on your application which of these is helpful but having the custom exception classes makes it very nice and tidy to do so. The differing class names let us detect what *kind* of a problem occured and what we want to do in response. When we catch an exception, we can state what kind of an exception we wanted to catch – so we can narrow ourselves down to only dealing with a known situation. We can also use multiple catch blocks, like this:

try {
    echo takeTwoNumbers(3,9) . "\n";
    echo takeTwoNumbers(4,16) . "\n";
    echo takeTwoNumbers(7,5) . "\n";
} catch(BigNumberException $e) {
    echo "Big Number: " . $e->getMessage() . "\n";
} catch(FavouriteNumberException $e) {
    echo "Favourite Number: " . $e->getMessage() . "\n";
}

In this example, we can handle the two types of exception differently. If any other type of exception were to occur, it wouldn’t be caught here, but instead would “bubble” up the stack, getting returned from the end of the second catch block to wherever this code was called from – in this very simple example we are in a simple PHP file but if we were nested in functions, the code would keep on returning until PHP caught the exception, or until it reached the top at which point it would show an error like the one we saw at the start of this post.

Uncaught Exceptions

So if an exception is thrown in a method, and not caught, it returns from the function to where that function is called from. If it isn’t caught here, it returns to where this code was called from, and so on until it reaches the top of the stack. If it gets to the top of the stack, uncaught, we’ll see the error we saw at the beginning of the post.

We can also give PHP instructions about how to handle any exceptions that get this far, using set_exception_handler. Many frameworks will do this and return nicely formatted messages, often logging the detail of the error so that users do not see it but developers can do so.

Here’s an example of a catch-all exception handling function:

function my_exception_handler($exception) {
  error_log("Uncaught " . get_class($exception) . " exception: " . $exception->getMessage() . "\n");
}
 
set_exception_handler('my_exception_handler');
 
throw new Exception('Oooops!');

All we need to do is declare our exception handling function and then tell PHP to use it for uncaught exceptions. This simple example simply passes a string to error_log function, which you can configure to behave however you need it to for your system. In a real-world application you might want to notify administrators of the problem or perhaps provide some nice feedback to the user in addition to logging the error.

Exceptions in Your Applications

Hopefully this has given some insight into what you can do with exceptions and how they interact with the rest of your object-oriented application. Even functional code needs awareness of exceptions since some core language elements now throw them, so it is worth making sure you have the exception handler declared alongside your existing error handler even if you don’t need to be extending or throwing exceptions yourself.

Are you extending the Exception class? What do you use this for? I’m really interested to hear about the various applications of this theory so let me know in the comments!

QuirksMode: New kid on the browser block: Samsung Dolfin

Mon, 26 Jul 2010 12:25:36 +0000

Back in early June I got a Samsung Wave that runs the brand-new bada OS and did some brief tests of the native Dolfin browser. In the past few days I’ve done some more extensive testing, and the verdict is in: good browser, well on the way to becoming excellent.

(Oh, and Dolfin ought not to be confused with Dolphin, which is a skin for Android WebKit.)

It’s Samsung’s philosophy that it will not compete in a market unless it belongs to the top three of that market. In the case of the mobile browsing market Samsung has succeeded: from nothing, Dolfin has become the third-best mobile browser in the world. Only iPhone and Android are better.

If you’re keeping track of the mobile browser landscape you should add Dolfin to your A-list. It’s easily good enough, and Samsung has big plans with the bada operating system. Somewhere in 2011 the installed base of Dolfin will pass that of Safari iPhone, and bada might even become a competitor to Android. (Samsung sure hopes so.)

I have updated my mobile pages with Dolfin data. (By the way, I also tested Android 2.2 while I was at it: few changes. There’s not a single difference with 2.1 in my great WebKit table.)

The good parts

Dolfin is only the third browser in the world to support the touch events, after iPhone and Android, and that’s a large part of the reason I count it as the third-best mobile browser.

Mobile browsers for touchscreen phones just must support these events by the end of the year, or they’re out of the race. (Opera, Firefox, Microsoft, NetFront, Nokia, BlackBerry, you have been warned.)

Dolfin’s implementation is even slightly better than Android’s. If I do a pinch-zoom test on my touch test page I use two fingers, and during replay I want the browser to show the position of both fingers. iPhone does so, Android doesn’t. Now Dolfin also shows both fingers’ position.

Unfortunately Dolfin is not quite up to iPhone quality: my multitouch drag-and-drop does not work. Still, the stuff it does support is quite impressive for a browser that didn’t exist at the start of this year.

Dolfin’s responsiveness to pinch-zooming is good. One friend who’s used to the iPhone even said it’s better than Apple’s implementation. I’m not quite prepared to go that far yet, but it easily gives Android a run for its money.

Dolfin incorporates a very modern WebKit version, and in my great WebKit table it is the best mobile browser, narrowly above Android 2.1/2.2 and comfortably above the iPhone 3.1 (4 not yet tested).

I’m currently working on a little side project: the perfect scrolling layer script for touchscreens. Obviously it should work in all three browsers that support the touch events. Of the three Android gives me the biggest problems right now, with Dolfin smoothly sailing along in the wake of the iPhone without any serious problems.

Dolfin is just a bloody good browser.

The buggy parts

Still, not all is rosy. I found a few bugs in Dolfin, and I’ll enumerate them here for the benefit of the Samsung team:

The viewport dimension properties are an absolute mess. Not only do they generally give wrong data, but a few of them change meaning when a <meta viewport> is present in the page. This must be addressed as soon as possible; it’s a show-stopper.
There’s a bug in the touchstart event. When you assign an event handler to it and execute it once, the event handler is removed. See this test page for the effect. Works fine on iPhone and Android, but fails in Dolfin the second time you want to drag the item.
The workaround, obviously, is setting the touchstart event handler again ontouchend. That works fine.
Dolfin is over-eager in firing the scroll and contextmenu events. Basically they always fire, even if an action does not result in a scroll or a contextmenu. (In fact, I haven’t yet discovered any contextmenu on Dolfin.)
These events should only fire if the scroll or contextmenu action actually take place.
The event coordinates are wrong: clientX/Y and screenX/Y copy the values of pageX/Y, while they should report the coordinates relative to the visual viewport in CSS pixels and in device pixels, respectively.
A personal peeve: on the browser software keyboard the “Go” button is located on the left. A standard is emerging whereby it’s the right button that says “OK, do it,” while the left button says “Never mind.” I got confused by Samsung’s button placement more than once.
Samsung bada is supposed to support W3C Widgets, but there is no way for developers to upload test widgets to the phone. In practice that means nobody will test on Samsung bada. This situation must be rectified.

Still, such bugs are only to be expected from a first release. In general Samsung has delivered a good browser that’s only a few small steps away from becoming excellent. I will follow Samsung’s next moves with interest.

ajaxian: Looking at JS emulator core for GameBoy

jvaughan — Sun, 25 Jul 2010 03:29:06 +0000

JavaScript as a general-purpose "Turing-complete language" is illustrated - the example discussed in the first part of a series: How a CPU can be emulated through JS, and how one might start building an emulation core for the GameBoy console. Looking forward: How a game image can be loaded into the emulator over the Web. For now: Hello, Z80! Check out Ice Station ImRannazar!

Vitamin: Around the Web: Forrst's App Contest, inForums, Cow Clicker

Chrissie Brodigan — Sat, 24 Jul 2010 03:37:15 +0000

Hey there!

It's very late on Friday night!(woo-hoo!), so this roundup is devoted to all things “awesome.”

Some links are newsworthy, some retweeted across Twitter, and others just meet our "awesomeness"� requirement, and regardless we hope you'll enjoy them. Without further delay:

Design Informer’s Jad Limcaco releases inForums
Cow Clicker is a Facebook game about Facebook games. It’s partly a satire, and partly a playable theory of today’s social games, and partly an earnest example of that genre. (via Ian Bogost)
Guide to layouts in web design (via Six Revisions)
Forrst users self-organize an app contest (it’s awesome, well-designed, & expect some insider info)
Where’s it Up is a site that tells you where in the world any site is up (via Paul Reinheimer)

Wildcard: Handwritten Tweets Express More (via Michael Beckwith & discovered via Grace Smith’s fabulous Twitter stream)

Please shoot me links to projects your working on or awesome things you’ve released! news@thinkvitamin.com

Handpicked by,

Chrissie (@tenaciouscb)

Vitamin: CSS3 Transitions Part 1 [Video Tutorial]

Keir Whitaker — Fri, 23 Jul 2010 10:30:59 +0000

It’s Friday and time for our second free weekly helping from the Think Vitamin Membership video library. Today we move our attention to CSS3 Transitions.

Don’t forget 2 new videos are added to the library every day, to find out more about Think Vitamin membership videos and all the other benefits check out the site.

Vitamin: The 7 Sins of Managing Web Projects

Rob Mills — Fri, 23 Jul 2010 10:30:25 +0000

Managing web projects is both tough and satisfying in equal measures. Every project is a new learning curve and even though I'm educated from every project I work on, new problems are presented to me on a daily basis.

Some problems and challenges on the other hand, rear their head time after time, and I have classified these in line with the 7 deadly sins, renaming them of course as the 7 sins of managing web projects.

Pride

As a Project Manager it is easy, too easy, to blame clients or members of the project team when things go wrong. You should never be too proud to admit when mistakes have been made and as manager of that project you should take ownership of trying to resolve the issue.

At some stage in the project you will almost always have to compromise on something or face an issue that wasn't planned for. It is far more productive to focus on the solution, so identify the problem, agree the course of action to getting it resolved and get things back on track.

Envy

Depending on the process you adopt on your projects, chances are you will indulge in some sort of competitor research. Upon doing so we can learn what works and what doesn't for others.

It is unlikely that you will find a site that answers your client's brief down to the last pixel but with trends emerging seemingly overnight and with work being shared more freely through sites like Dribbble, Twitter and others, there is probably a site out there that you like, that you really like.

It is easy to be jealous of other sites and want to incorporate bits of them in your own. That's fine of course as we can all be inspired by others but don't let envy stomp all over your creativity. Ensure your website is not a tapestry of others. Be original, make sure you answer your client's brief and consider their audience throughout the project. Be inspired by others but don't copy them.

Gluttony

Clients are demanding, naturally they want as much as they can for as little money as possible. Who wouldn't?

This is where we have to say no though. Don't try to cram everything into phase 1. Be realistic about what is achievable based on the allocated budget and timescales. Agree on the core tasks, essential pages and functionality that have to be incorporated for initial launch.

Anything else can be achieved during retainers or additional phases. Trying to incorporate a little of everything will mean you are spread too thinly. Nobody wants to be a jack of all trades and nor should your client's website be.

Lust

It is important to love what you do; being passionate will motivate the project team, fuel creativity and ensure that even the most wearing of projects will reach the finish line. The key though is not to get too involved. Doing so can cloud your judgement when it comes to making those tough project related decisions.

Take a step back and be impartial. Does your work answer the brief? Refer back to the signed off project scoping/briefing document to check this before proceeding. Immerse yourself in your client's world and in the project but not at the expense of bumbling along answering yes to everything.

Anger

It is easier said than done at times but don’t lose your cool when client demands reach fever pitch or things aren't going right. I don't think I've ever worked on a project where I wasn't pushed to my limits at some point. This is good though, being challenged helps us learn, quickly.

Instead of getting wound up though, focus your energy on trying to plan as much as possible at the start of the project and adopt standard risk assessment processes into your planning phase such as SWOT analysis (strengths, weaknesses, opportunities, threats).

Greed

Delegation is one of qualities of a good Project Manager. It isn't to be confused with passing the buck, rather delegating tasks across the team so people are used to their strengths. Don’t try to handle everything yourself, it will only end in tears, big over budget, behind schedule tears!

The role of the Project Manager is to ensure things get done, to budget and on schedule so there is no time to be greedy. Project work is all about communication and collaboration. Share the work and the glory (and the problems).

Sloth

Continuing from the last point above, don’t let members of the project team drag their feet. As Project Manager you will need to keep them motivated and involved throughout the project. Be firm with the project team, set clear tasks, deliverables, responsibilities and deadlines.

Report back throughout the project so the team know what has been achieved, feedback from the client is communicated and any changes in deliverables is understood. The minute anyone in the team feels uninvolved in the project is the minute they will lose enthusiasm for it.

Communication throughout is paramount to any project being successful and in my experience, never underestimate the power of the simple words, "�please' and "�thank you'."�"� Just seven?

Are there any sins that I have omitted? If you have your own please share them in the comments below.

ajaxian: Dojo 1.5 is Out and it's Feature Packed!

Rey Bango — Thu, 22 Jul 2010 18:06:14 +0000

The Dojo project continues to pump out goodness announcing version 1.5 of the Dojo Toolkit with a number of new and exciting features.

Dylan Schiemann had this to say about the release:

The JavaScript world is evolving at an intense pace. We're very pleased with this release of Dojo, which offers the stability needed for existing apps and browsers, while introducing some of the capabilities of building great apps of the future.

Some of the biggest updates came to the Dijit UI library with the addition of the new Claro theme which helps provide a nice desktop look-and-feel to web applications as well as improvements to the charting and drawing components of the library.

And Dojo team lead Pete Higgins added:

If you haven't seen the new theme Claro, you should. Julie Santilli and her awesome design team at IBM put some incredible design and style on top of an already stable and accessible UI library

The theme is incredibly clean. Check out some of the controls styled using Claro:

Other important updates include:

Strong support for HTML5 & CSS3 features such as local storage, transforms and Canvas with fallback
Implementation of dojo.Stateful
Update to dojo.Deferred to leverage a new underlying Promises-based API

In addition, new initiatives are underway to provide solutions for the ever-growing and important mobile space:

dojox.mobile: lightweight mobile web widgets
dojox.mobile.app: mobile application development framework
embedjs: Dojo API, optimized for mobile
TouchScroll: scrolling layer for WebKit Mobile
wink: mobile web app toolkit

This release continues the project's philosophy of modularity allowing developers to leverage the library for anything from simple DOM manipulation to full-blown RIA development. Dojo 1.5 is immediately available for download and sports impressive, updated documentation to get you started quickly.

QuirksMode: Antennagate and Apple’s hubris

Thu, 22 Jul 2010 15:57:37 +0000

Apple continues to startle me, and I do not mean by its iPhone 4. (I haven’t yet seen it, so I can’t say anything useful about it.) No, what I mean is the ongoing Antennagate problems, and even there I do not mean the actual problem, but Apple’s way of dealing with it. And even there I do not mean Antennagate as an isolated PR incident, but as yet another chapter in how Apple spends 2010 to piss off the world at large.

Antennagate

The problem with Antennagate is not the actual technical issue itself. That issue may or may not be severe, may or may not occur on other phones, and is probably solved adequately by the covers Apple is now giving away. Frankly I don’t care about the details.

No, the problem is in how Apple handled the entire affair. Not its acknowledgement of the problem itself, or giving away the covers; those are proper, correct responses to the technical issue.

John Gruber made an interesting remark:

It’s telling that the criticism surrounding this issue has shifted, quickly, from speculation about a technical defect in the iPhone 4 hardware to criticism over the tone of Apple’s response to it.

The hardware defect is only a sideshow, and the way Apple is dealing with it is far more important to the world. Gruber is completely right in pointing this out, yet I believe he draws the wrong conclusions from it.

PR is crucial for Apple. Good PR has created a legion of Apple fanbois and a chattering class of tech commentators that consistently paints Apple in the best light possible. A serious PR flap is far more dangerous than a technical issue because it can cost Apple the support of the tech commentators (and possibly even the fanboi legion, but that will take more than a mere year full of Fuck Yous).

Thus I believe that Gruber is right, yet wrong. Weighing Apple’s tone and response is more important than the technical issue. Antennagate is about PR, and not about the iPhone 4’s antenna.

In that light, Tomi Ahonen points at an important mistake Apple made:

Why include that unnecessary hostile attack on the rest of the industry? That was a red flag to the rivals, and a clear challenge to the press to go compare. This is a lose-lose for Apple, even if others are implicated too, every time Death Grip is mentioned, Apple is the leading culprit of the news story. Every time the iPhone 4 is reminded to have Death Grip problems! And for every story where rivals are also implicated, there will be stories where at least one of the rivals is not shown as bad, or in the worst case, that Apple's iPhone 4 comes out worst at Death Grip. Apple's news coverage will be bad - or worse.

In other words, exactly because Steve Jobs wanted to implicate other phones in this problem, Antennagate will come back to haunt him. We can expect a string of press releases from other mobile players, saying something along the lines of “In contrast to Apple’s iPhone 4, our flagship product X does not suffer from an antenna problem.”

Note that it does not matter who’s right here. Even if Jobs is completely right and the other phone vendors are lying through their teeth, the world will again and again be reminded of Antennagate. That’s not disastrous, but it’s certainly a major annoyance that will hurt the iPhone 4’s sales figures somewhat.

Still, Antennagate alone will not spell doom and disaster for Apple. I would expect the hubbub to die down within a few months — if Antennagate were an isolated incident.

Problem is, it isn’t an isolated incident.

Apple pisses off everybody

I said it before and I’ll say it again: this year, Apple is being serious about pissing off absolutely everybody in sight. I do not think this is a viable long-term strategy, and I do think that if Apple keeps this up long enough it will eventually run into serious problems.

So what exactly did Apple do wrong?

First things first: in 2007 it barged in on the mobile market, changed the rules, and succeeded beyond everybody’s wildest dreams. That’s of course a huge success for Apple, and rightly celebrated as such, but it has also created a host of enemies: basically all other powerful mobile players. That’s not a disaster, but it does mean wolves are on the prowl, and Apple has to keep its defenses in order.

Its main line of defense, as always, is PR. And it’s exactly here that cracks are starting to show. Let’s recap Apple’s year so far:

It pissed off Adobe by rejecting any kind of Flash on the iPhone. The problem here is not so much Adobe itself, which is facing serious trouble in making the move to mobile, but the Adobe fanboi legion, which got thoroughly angry. Adobe, too, has a powerful PR machine, and it knows how to reach designers. Adobe’s point of view has found powerful defenders. (So has Apple’s, but that’s not the point. It would have been far better to continue to let the Adobe hordes sleep.)
PR translation: the iPhone is a closed platform, and Apple is proud of it.
Closely related is the major SDK license flap when Apple banned 3rd-party runtimes from the iPhone. There are solid technical reasons for this, but that’s not the point. It’s one more PR flap and a serious gamble. To quote one analysis:

The proposition is this: Apple is betting it can grow its platform fast enough, using any means necessary, that developers will stick around despite all the hardships and shoddy treatment. Each time it chooses to do what it thinks is best for the future of the iPhone OS platform instead of what will please developers, Apple is pushing more chips into the pot.

Besides, once again attention was drawn to Apple’s almost frivolous app rejections. The problem here is not that Apple rejects some apps, but that the rules aren’t clear.
PR translation: iPhone developers should bloody do what Apple tells them. The iPhone is a closed system that’s wholly dependent on Apple. Start loving it.
Apple announced a lawsuit against patent infringements by HTC. To quote one analysis:

Apple could be hoping for a chilling effect from other handset makers looking to avoid a legal battle. But Apple is walking a tightrope. It needs to whack HTC without drawing Google and Microsoft into the fight. Riddle me this: Can you realistically just focus on the hardware here? If so perhaps Apple can prosecute a surgical strike on HTC. The reality is that the smartphone software and hardware are intertwined. You can expect that Google and Microsoft will defend their code at some point.

In other words, Apple may have bitten off more than it can chew. In any case it has aligned some of its most powerful competitors against it.
PR translation: Apple will bully its weakest competitors on grounds that are not comprehensible to the general audience.
Then it pissed off Mac developers by focusing WWDC wholly on iOS.
PR translation: Fuck off, Mac devs. You’re not important any more.
The case of the stolen prototype. I don’t really care about the legal aspects. The only thing I see is a large, legendarily closed company suing some journalists and assorted helpers.
PR translation: Fuck you for not obeying our rules. We’ll send our Gestapo after you.
I cannot help but be impressed by a closing remark on Gizmodo, the site that unveiled the stolen prototype:

If you think that Gizmodo shouldn't have shown you the iPhone before Apple wanted you to see it, you’re accepting that Apple should be the one to control news about its products. That's not an irrational position, but let's be honest about what it means.

[...]

It hands back the control of the story to Apple because some are more comfortable believing Apple's machinations are infallible than that they’re a company made up of human beings who try to control the news cycle — and that even the best laid plan can fall apart because of a single human mistake.

This is the flip side of the huge amount of attention the US tech world lavishes on Apple. Now that Apple is on the way to becoming a bully some media will gleefully report on it. It’s a new kind of Apple news, after all, and inherently more interesting that the next release of iWhatever.
And now there is Antennagate.

(Incidentally, there are two groups that Apple hasn’t pissed off yet, and that I don’t expect them to piss off, either. They are consumers, who get their covers against Antennagate, and web developers, who’re still allowed to play with the most advanced mobile browser in the world. I continue to believe that web development is Apple’s ace in a hole. If everything else goes wrong, Apple will still have the best mobile web platform in the world.)

Is any of these mistakes fatal? Certainly not. Apple handled the technical aspects of Antennagate correctly, its rejection of Flash and the new SDK license agreements are defensible from a UX perspective, its dissing of Mac developers is understandable in the light of its mobile strategy, and I don’t doubt the lawsuits against HTC and the prototype culprits have a solid legal grounding. Finally, the PR flap is manageable in every case taken by itself.

Hubris

However, if we take all these issues together we see Apple spending 2010 by sending a cheerful Fuck You to people of all colours and all nations, and especially its own developers and former allies.

Is Apple suffering from imperial overstretch? Is Apple guilty of an old-fashioned case of hubris?

Judging from the evidence that’s certainly a possibility.

Fortune’s wheel. What goes up must come down. The throne of the once-almighty king is toppled because he grew overconfident.

Those are powerful story lines that have interested humanity for at least 2,500 years. Since they conform to some sort of basic human expectation of how history works, the tech commentators who are Apple’s PR mainstay could start to pursue them in order to present a different perspective and gain more readers. (Come to think of it, so am I.)

Right now Apple is doing everything in its power to push those story lines. In the long run that is not healthy.

I feel Apple has a PR problem, but isn’t aware of it, possibly because it doesn’t want to be aware of it.

Now let’s see how this plays out. The story isn’t done yet, and who knows, Apple might even see the errors of its ways before it’s too late.

Wisdump: Prettier Posts: Clean Up Those Listings

Thord Daniel Hedengren — Thu, 22 Jul 2010 15:50:17 +0000

It’s about time we clean up the blogosphere, it doesn’t have to be this ugly, and not everyone needs to hire me or my likes to get a pretty blog. There’s a lot you can do yourself, and most of it is related to your content.

Take a look at your average listing of posts, usually your front page but it could also be a category page or an archive. Post after post after post after post. Boring? Might be. Long? In most cases, yes. Too long? Yep, I’d say so.

I believe in using read more functionality, in other words, in just displaying some of the content (if the post is a semi-long or long one) in post listings. If you display a 20 paragraphs long post after a 30 paragraphs long post, but before a 50 paragraphs long post, then you have a very ugly page.

By using read more functionality, available in any good blogging software, you can show as much content as you like in your listings, and it shouldn’t be too much.

Take a look at Wisdump, for instance. You’ll find a Read the rest of this entry link on most of the posts I’ve written, only very short ones get published in its whole in the listing. Even less gets published on my blog, rethord.com, but the principle is the same – the only thing that varies is the font size, and that means I’ll have to make the read more break earlier.

If you’re a WordPress user you might be tempted to use the_excerpt, which publishes what you put in the optional excerpt box, or cuts your posts for you. That’s fine for long listings, but if you want an attractive front page, for instance, you want full control, and that means you’ll have to use the optional excerpt box on every post, otherwise it might look like crap since you can’t control where the post will get cut in a per-post basis.

Today’s homework is to take a look at your post listing. Do you have long post after long post after long post? Then reconsider, because it doesn’t look good, and it doesn’t offer the reader a decent overview.

The lack of read more in the blogosphere is both a usability and a design problem. It’s not practical to present big chunks of content in lists, and it looks like shit. That’s the bad part.

The good part is that you can fix it on your end, right away. So please do.

Vitamin: Think Vitamin Interview: Dan Cederholm at FOWD London 2010

Keir Whitaker — Thu, 22 Jul 2010 14:00:59 +0000

Earlier this year whilst attending Future of Web Design London I recorded a few interviews.

First up is my chat with Dan Cederholm, designer, author and co-creator of one of the most popular design focused apps Dribbble. Thanks to Dan for taking the time to chat.

You can listen below or download the mp3 directly.

Stopdesign: My Measures & Dimensions

Douglas Bowman — Tue, 20 Jul 2010 15:00:00 +0000

I just discovered an iPhone app named My Measures & Dimensions that lets you take any photo and quickly draw dimensions on top of objects or spaces in the photo. Typically, I use a piece of scrap paper for this, and end up forgetting to bring it with me when I need it. After photos are marked up with measurements, they can be emailed to anyone, or added to the iPhone’s photo library.

So far, this app seems incredibly useful for several purposes. I’m using it to quickly record the measurements of rooms in our house. It’s also handy to note the dimensions of some bookshelves in our daughter’s room, so we’ll know what can fit inside. I can easily imagine several other uses too. Here’s a direct link to My Measures in the iTunes Store. link

QuirksMode: The Firefox problem

Tue, 20 Jul 2010 11:00:06 +0000

In recent weeks Firefox 4 beta 1 and Opera 10.60 were released, and I could also put my hands on a working Chrome 4. I added all these browsers to the compatibility tables, which are now all updated, except for the Events one.

There’s little difference with my earlier reports, except that the new Firefox beta is making a serious effort to support the background module. It’s not there yet, but Firefox is not as disastrously behind as it was a month back.

Firefox

Of course Firefox remains a pain in other respects: still no support for contains(), incorrect indexing of attributes (it’s essentially random), no innerText or outerHTML, no sane second argument for the add() method for select boxes, a colorDepth of 24.

All these bugs are Firefox-only, with the exception of the attribute indexing, which is also a problem in IE. Frankly, I’m starting to get fed up with Firefox and its haughty refusal to implements useful methods and properties found in all other browsers. But maybe that’s a passing phase. Maybe I’ll pick another browser to be annoyed at next time around.

Events

I haven’t yet updated the Events table, partly because it’s such a lot of work (it takes me as much time as all other tables combined), and partly because I do not expect huge changes. I tested various problems in IE9, and sadly found no improvements.

I’m not sure when I’ll have the time to do the Events table; I hope before I leave on holiday in early August.

ajaxian: A Little PIE with that CSS3?

Rey Bango — Mon, 19 Jul 2010 15:51:00 +0000

Everyone's chomping at the bit to leverage new HTML5 and CSS3 features but with some older browsers not supporting them, hacks are still needed to make things work in a cross-browser fashion. We've seen libs that make things easier such as Remy Sharp's html5shiv and Modernizr and now we can add another one.

Jason Johnston's new PIE library makes it easy to rendering several of the most useful CSS3 decoration features within Internet Explorer versions 6 through 8. He took an interesting approach by using IE DHTML Behaviors to style the elements and provide the necessary functionality to emulate the CSS3 functionality. So to add rounded corners to an element, your CSS code might look like this in plain 'ole CSS:

PLAIN TEXT

CSS:

#myElement {
background: #EEE;
padding: 2em;
-moz-border-radius: 1em;
-webkit-border-radius: 1em;
border-radius: 1em;
}

To add support in IE 6-8 using PIE, you'd add this:

PLAIN TEXT

CSS:

#myElement {
...
behavior: url(PIE.htc);
}

PIE currently has full or partial support for:

border-radius
box-shadow
border-image
multiple background images
linear-gradient background images

Unfortunately, there seems to only be one demo at the moment, which is border-radius rendering via the home page, but it's still seems like a good start with a lot of future potential.

I've never personally used IE DHTML Behaviors or HTML Components so I looked them up and found these intro links for those who might be interested in better understanding them:

Using HTML Components to Implement DHTML Behaviors in Script
Introduction to DHTML Behaviors

Microsoft - IEBlog: How IE9 Platform Preview Feedback Changed the JavaScript Standard

ieblog — Fri, 16 Jul 2010 21:43:00 +0000

When we first introduced our plans for Internet Explorer Platform Previews we said that “developers and people interested in standards and web development can try out new platform functionality and provide early feedback.” We are now getting such feedback on a daily basis and are using it to improve IE9. However, sometimes the impact of the feedback extends beyond just IE9. Here is the story of how some recent feedback regarding the third IE9 Platform Preview resulted in a correction to the new ECMAScript 5^th Edition (ES5) standard for JavaScript.

The ES5 standard became official in December 2009 and the third IE9 Platform Preview is the first widely distributed implementation of some subtle details of the ES5 specification. ES5 was designed to be highly compatible with existing websites and the Ecma International TC39 technical committee worked to avoid any non-security related changes that might break existing JavaScript code. However, perfection generally does not exist in the world of software so with the third IE9 Platform Preview we were very interested to see if any ES5-related compatibility problems with existing sites would show up.

Soon after releasing this platform preview, we received reports that some web-apps that use the jQuery framework did not work correctly in the preview. We tracked the problem to a specific jQuery API method that in some cases passed a caller provided value to Object.prototype.toString without first checking if the value was null or undefined. Specifically, some calls to this jQuery method:


isFunction: function( obj ) {
     return toString.call(obj) === "[object Function]";
},

failed with an exception: “TypeError: Object expected”. Further analysis showed that toString in the above code was the built-in method Object.prototpe.toString and that the failures occurred when isFunction was being called with undefined as its argument. Why does an exception occur in IE9 and not in previous versions of IE or other browsers? It is because the third IE9 Platform Preview in standards mode actually conforms to the ES5 specification for Object.prototype.toString.

According to the prior editions of the ECMAScript specification, calling any built-in method using null or undefined as the this value passes the “global object” (in browsers this is the DOM window object) to the method as its this value. This opens a number of potential security holes for frameworks that aim to support mash-ups in a secure way.

The ES5 specification changed this so that null or undefined is not replaced with the window object and the definition for each built-in method was updated specifically to deal with receiving these values as their this value. The ECMAScript technical committee tried to do this in a way that preserves backwards compatibility for normal usage and throws an exception in cases where that is not possible. Object.prototype.toString was specified in ES5 to throw such an exception. This created the compatibility problem described above.

This problem can be easily corrected by modifying the jQuery code with the additions shown in red:


isFunction: function( obj ) {
     return obj && toString.call(obj) === "[object Function]";
},

The jQuery team actually intends to make this change. However, such a change will not correct the thousands of locally hosted copies of jQuery that already exist on the Web. With the broad use of jQuery, it is clear that the ES5 specification contains a significant compatibility problem. It is fairly obvious how we can modify the IE9 ES5 implementation to eliminate the problem. We can just return the same string value ("[object Object]") that IE8 returns in this situation. Such a fix does not reintroduce any of the security problems that ES5 strives to eliminate. However, we do not want to unilaterally introduce such a variation into our implementation of a new standard. It does not help either compatibility or interoperability if IE fixes this problem one way, and other browsers either don’t fix it or fixed it a different way.

As soon as we understood the problem and the possible solution, I raised this on the TC39 es5-discuss mailing list as a backwards compatibility issue. My first post on the issue went out at 5:51 PM on June 25, a Friday. By 10 PM there were responses from TC39 members representing Apple, Mozilla, and Google. We all agreed that this was a compatibility issue that needed to be fixed, and that in this case throwing the exception was unnecessary and undesirable. We also initially agreed that the idea of returning the same string value as ES3 for these cases sounded like a good idea. However, in further messages over the weekend we realized that browsers currently don’t all return "[object Object]" in this situation, some other values that were observed include "[object Window]" and "[object Global]". A proposal was made to return "[object null]" and "[object undefined]". This seemed to be a better solution as it not only fixes use cases such as jQuery’s but it also explicitly distinguishes null and undefined from actual objects. It is also better for browser interoperability because it requires that all browsers produce identical results rather than the ES3 situation that allowed different browsers to produce different results.

By Tuesday, the consensus on the mailing list was to follow this final proposal. As soon as that agreement was reached, I passed the revised Object.prototype.toString specification on to our IE9 JavaScript development team so they could make the fix in time to widely test it with the next IE9 platform preview build. Mozilla has also indicated that they will be incorporating this fix into a future Firefox beta. I also updated the official TC39 Erratum for ES5 so this specification change is recorded there (section 15.2.4.2).

Web standards are complex software artifacts and like all software, they contain bugs. Sometimes the best way to find and fix compatibility bugs is to implement and deploy the standard on widely used browsers. This generally takes place in the context of early releases such as the IE9 platform preview builds. So, when you as a web developer are providing feedback on such releases you aren’t just providing feedback on a specific browser you are also providing feedback on the new and emerging standards that it implements. Of course, for this feedback to be worthwhile, browser implementers and standards authors need to be able and willing to quickly respond to feedback that identifies significant problems. The rapid response to the ES5 jQuery toString problem and other issues on es5-discuss show how browser implementers and other TC39 members can and do work closely together to create a more compatible and interoperable Web. But it all starts with your feedback, so please keep it coming.

Allen Wirfs-Brock
Microsoft JavaScript Language Architect

ajaxian: It's Friday. Take the time to learn the Web with a splash of French, German, and Irish

Dion Almaer — Fri, 16 Jul 2010 17:34:34 +0000

The week has been long. Much code has been written. There is much more to do, but Friday is for relaxing a little. Take some time, sit back and watch, as three fantastic videos are available for you:

French: Paul Rouget of Mozilla, shows you the future

Paul builds the best demos. ever. At the Mozilla Summit in Whistler, he shows off what you can do when you remix HTML5, CSS3, SVG, WebGL, and WebSockets. A must see.

German: Building an awesome social HTML5 engine

Paul Bakaus of Dextrose (and jQuery UI fame) recently launched the Aves Engine, a social gaming engine in pure HTML! Dextrose also joined forces with Effect Games to bolster its Web gaming might. Paul gave a talk at Google explaining the technology, and it just went live:

"Irish": Paul shows you jQuery c0de

Ok, Irish by name, and maybe a touch by nature.... but not by nationality. Paul Irish has been doing an amazing talk at conferences where he walks through the jQuery source code to teach you fun and frolics of JavaScript. He picked up ScreenFlow and did it again to reach you all. Paul is a gem in our community, and at 52 minutes.... you will still want more:

Have a great weekend!

Microsoft - IEBlog: The CSS Corner: Better Web Typography For Better Design

ieblog — Fri, 16 Jul 2010 00:04:00 +0000

Lost In Translation

“Web design is 95% typography”. So much of the content produced and consumed on the web is text yet designers and users have been confined to a set of compatible fonts available across client operating systems. Escaping this typographical island has involved everything from cross-browser CSS workarounds, graphics-based solutions and even plug-ins, with trade-offs ranging from extra storage and bandwidth to reduced accessibility.

As a result, typefaces have too often been one of the first casualties of the translation from Photoshop design mock-up to live web page.

Not The Same CSS

Solving this challenge required an interoperable CSS syntax to describe font resources. While IE added support for CSS2’s @font-face rule as long ago as 1997, the differences between this earliest of implementations and the far more recent ones supporting CSS3 Fonts have given rise to CSS design patterns built to ensure the same rule works for all users. A notable example is the bulletproof @font-face syntax developed by Paul Irish from Google, et al.

But crafting a cross-browser @font-face declaration turned out to be half the problem.

No Common Web Font Format

Internet Explorer’s @font-face implementation supports EOT (Embedded OpenType) fonts, a compressed font encoding submitted to the W3C in 2008. Following WebKit’s lead in 2007, Mozilla and Opera added support for raw TrueType and OpenType fonts. Raw fonts work well if your fonts’ end-user license (EULA) allowed you to serve them from your web server. While this is true for many free fonts, this is not the case for the vast majority of commercial fonts. Web authors are thus effectively cut off from the richest font catalogs available. If they choose EOT they are able to license a number of commercial fonts for web use but only IE renders them.

This leaves a challenge for the industry. The major browsers support two incompatible solutions and commercial font EULAs are generally incompatible with one of them. This spawned dedicated hosting services like TypeKit to help designers license typefaces for their site and use them across browsers. These services, however, may not offer all or even any of the desired fonts that a web developer needs for their site. In some cases, a font set could even require multiple subscriptions.

WOFF

In late 2009, type designers Tal Leming and Erik van Blokland working together with Mozilla’s Jonathan Kew proposed a new web font container format to address the concerns of font vendors without reducing web author choice. It was well received and submitted to the W3C in April 2010 by Mozilla, Opera and Microsoft. Today, Firefox 3.6 supports WOFF and other browser vendors will be following soon.

Font foundries have also rallied behind the new format and already offer WOFF-encoded fonts for web use. Among them, Monotype Imaging, Ascender Corporation, FontShop and Typotheque provided us with the great WOFF fonts used in our our Testdrive demos.

Same CSS, Same Web Font Format

Starting with Platform Preview 3, IE9’s @font-face implementation conforms to the CSS3 Fonts module; supported font formats include EOT and WOFF as well as raw fonts with embedding permissions set to installable.

In future posts, we will look into IE9’s web font support in more detail, as well as the available techniques for cross-browser typography. In his latest post on the FontBlog, Greg Hitchcock offers rich context on the art and science behind the technologies involved in web typography.

We look forward to your feedback on this Preview release, as well as ongoing work within the W3C to extend the reach of the typographic web.

Sylvain Galineau
Program Manager

Wisdump: Authority Profile: Rand Fishkin

Josh Dunaway — Wed, 14 Jul 2010 23:49:44 +0000

For my first post here, I wanted to introduce a new idea, an authority profile. I want to create a small database of people that help answer the question, “who should I be following online?”

The first person on my list to talk about is Rand Fishkin. Who is Rand Fishkin? Well, first off all the SEO girls want Rand Fishkin. Being a dude, I really can’t say either way why that is, but I am pretty impressed with the site he has built. Rand is the CEO and Co-founder of SEOmoz, a site that includes a blog with over 10,000 RSS readers according to Feedburner. It was voted the best SEO blog in 2006 by Search Engine Journal, and has been mentioned in numerous high level places like USA Today, Washington Post, and Newsweek Magazine.

The reason Rand is an authority is because of his mix of understanding of Finance, due to majoring in the subject, the web, from all his years of experience and bringing it all together. His articles on SEOmoz are some of my favorites, and the site is just a gold mine of information. You can find him at Search Engine Strategies & Pubcon conferences around the world, and of course on SEOmoz.

Microsoft - IEBlog: Caching Improvements in Internet Explorer 9

ieblog — Wed, 14 Jul 2010 23:26:00 +0000

The network plays a crucial role in the overall performance of a web browser. The best way to improve network performance is to minimize the volume of network traffic by using HTTP compression and taking advantage of the browser cache.

We’ve made a tremendous number of improvements to the way that Internet Explorer 9 caches content to ensure that as many resources as possible are loaded from the cache. This post describes those improvements which are now available in the third IE9 Platform Preview which was released last month.

Understanding Caching

Let’s start with a quick refresher on how caching works in browsers. At a high level, web browsers make two types of requests over HTTP and HTTPS—conditional requests and unconditional requests.

An unconditional request is made when the client browser does not have a cached copy of the resource available locally. In this case, the server is expected to return the resource with a HTTP/200 OK response. If the response’s headers permit it, the client may cache this response in order to reuse it later.

If the browser later needs a resource which is in the local cache, that resource’s headers are checked to determine if the cached copy is still fresh. If the cached copy is fresh, then no network request is made and the client simply reuses the resource from the cache.

If a cached response is stale (older than its max-age or past the Expires date), then the client will make a conditional request to the server to determine whether the previously cached response is still valid and should be reused. The conditional request contains an If-Modified-Since and/or If-None-Match header that indicates to the server what version of the content the browser cache already contains. The server can indicate that the client’s version is still fresh by returning HTTP/304 Not Modified headers with no body, or it can indicate that the client’s version is obsolete by returning a HTTP/200 OK response with the new version of the content.

Obviously, conditional requests result in better performance than unconditional requests (because the server need not retransmit the entire file if the client’s version is fresh) but the best performance is obtained when the client knows that the version in its cache is fresh and the conditional revalidation can be avoided entirely.

Extremely Long-Life Cache Headers

While RFC2616 recommends that servers limit freshness to one year, some servers send Cache-Control directives specifying a much longer freshness lifetime. Prior to IE9, Internet Explorer would treat as stale any resource with a Cache-Control: max-age value over 2147483648 (2^31) seconds, approximately 68 years.

With Internet Explorer 9, we now accept any value up to 2^63 for the max-age value, although internally the freshness interval will be truncated to 2^31 seconds.

Vary Improvements

The HTTP/1.1 Vary response header allows a server to specify that a fresh cached resource is valid for future reuse without server revalidation only if the specified request headers in the later request match the request headers in the original request.

For example, this enables a server to return content in English with a Vary: Accept-Language header. If the user later changes their browser’s Accept-Language from en-US to ja-JP, the previously cached content will not be reused, because the Accept-Language request header no longer matches the request header at the time that the original English response was cached.

With Internet Explorer 9, we’ve enhanced support for key Vary header scenarios. Specifically, IE9 will no longer require server revalidation for responses which contain Vary: Accept-Encoding and Vary: Host directives.

We can safely support these two directives because:

All requests implicitly vary by Host, because the host is a component of the request URL.
IE always decompresses HTTP responses in the cache, making Vary: Accept-Encoding redundant.

Like IE6 and above, IE9 will also ignore the Vary: User-Agent directive.

If a response contains a Vary directive that specifies a header other than Accept-Encoding, Host, or User-Agent (or any combination of these) then Internet Explorer will still cache the response if the response contains an ETAG header. However, that response will be treated as stale and a conditional HTTP request will be made before reuse to determine if the cached copy is valid.

Redirect Caching

Internet Explorer 9 now supports caching of HTTP redirect responses, as described by RFC 2616. Responses with Permanent Redirect status (301) are cacheable unless there are headers which forbid it (e.g. Cache-Control: no-cache) and those with Temporary Redirect status (302 or 307) are cacheable if there are headers which permit it (e.g. Cache-Control: max-age=120).

While this significantly improves performance, web applications that are misconfigured might not work as expected after this change. For example, we’ve found a few commonly-visited sites that use a pattern which looks like this:


> GET / HTTP/1.1 
< 301 Redirect to /SetCookie.asp

> GET /SetCookie.asp HTTP/1.1 
< 301 Redirect to /

The site’s goal is to have the homepage determine if the user has a cookie set, and if not, send them to a page that sets the cookie. The problem is that the server has chosen a 301 for this task, and a 301 is cacheable. Hence, IE will simply redirect between these two cached redirects on the client (never again contacting the server) until the user gets bored and closes the browser. Notably, any version of IE would hit a redirect loop in the scenario above if the user had disabled cookie storage for the site in question.

If your site makes use of redirects, you should ensure that it is configured to avoid redirect loops by ensuring that any redirect that relies upon side-effects (e.g. testing or setting a cookie) is marked uncacheable.

HTTPS Caching Improvements

A few months ago, I mentioned that Internet Explorer will not reuse a previously-cached resource delivered over HTTPS until at least one secure connection to the target host has been established by the current process. This can cause previously-cached resources to be ignored, leading to unconditional network requests for content that was already in the local cache.

In IE9, the unnecessary cross-host HTTPS requests are now conditional requests, so the server can simply return a HTTP/304 Not Modified response for unchanged content. While a round-trip cost is still incurred, significant performance improvements are gained because the server does not need to retransmit the entire resource.

Back/Forward Optimization

For IE9, we’ve made improvements so that clicking the back and forward buttons results in faster performance.

RFC2616 specifically states that a browser’s Back/Forward mechanisms are not subject to cache directives:


History mechanisms and caches are different. In particular history
mechanisms SHOULD NOT try to show a semantically transparent view of
the current state of a resource. Rather, a history mechanism is meant
to show exactly what the user saw at the time when the resource was
retrieved.

By default, an expiration time does not apply to history mechanisms.
If the entity is still in storage, a history mechanism SHOULD display
it even if the entity has expired, unless the user has specifically
configured the agent to refresh expired history documents.

In previous versions of Internet Explorer, when the user navigated back or forward, IE would check the freshness of resources if they had been sent with the must-revalidate cache-control directive, and in numerous other circumstances depending on how recently the resource was downloaded. In IE9, the INTERNET_FLAG_FWD_BACK flag behaves as described on MSDN, and IE will not check the freshness of cached resources when the user navigates Back or Forward.

As a result of this optimization, Internet Explorer 9 can perform far fewer conditional HTTP requests when navigating with Back and Forward. For example, the following table shows the improvement when going Back to a typical article on a popular website:

IE8

IE9

Improvement

Back/Forward Navigation

Request Count: 21

Bytes Sent: 12,475

Bytes Recv: 216,580

Request Count: 1

Bytes Sent: 325

Bytes Recv: 144,617

Request Count: -20 (-95%)

Bytes Sent: -12,150 (-97.4%)

Bytes Recv:-71,963 (-33.3%)

Now, I mentioned that we ignore caching directives when navigating back and forward, so alert readers may be wondering why IE9 still makes one request when clicking Back on this site. The reason is that IE will not commit to the cache any uncacheable resource. An uncacheable resource is one delivered with a Cache-Control: no-cache directive or with an Expires date in the past or an Expires date not later than the Date header. Therefore, the browser is forced to redownload such resources when the user navigates Back and Forward. To improve performance and enable a resource to be reused in Back/Forward navigation while still requiring revalidation for other uses, simply replace Cache-Control: no-cache with Cache-Control: max-age=0.

Unlike the other improvements in described in this post, back/forward optimizations are not visible in the Platform Preview build because it does not have a back button.

Heuristic Cache Improvements

Best practices recommend that web developers should specify an explicit expiration time for their content in order to ensure that the browser is able to reuse the content without making conditional HTTP requests to revalidate the content with the server. However, many sites deliver some content with no expiration information at all, relying upon the browser to use its own rules to judge the content’s freshness.

Internet Explorer allows the user to configure what should happen when content is delivered without expiration information. Inside Tools > Internet Options > Browsing history > Settings, you will see four options:

These four options have the following behavior:

Every time I visit the webpage	Any resource without explicit freshness information is treated as stale and will be revalidated with the server before each reuse.
Every time I start Internet Explorer	Any resource without explicit freshness information is validated with the server at least once per browser session (and every 12 hours thereafter in that session).
Automatically (Default)	Internet Explorer will use heuristics to determine freshness.
Never	Any cached resource will be treated as fresh and will not be revalidated.

These options only control the browser’s behavior when content is delivered without expiration information; if the content specifies an explicit policy (e.g. Cache-Control: max-age=3600 or Cache-Control: no-cache) then the browser will respect the server’s directive and the options here have no effect.

In earlier IE versions, the Automatic Heuristics were simple and only affected cached images, but IE9 improves the heuristics to match RFC2616’s suggested behavior:


if the response does have a Last-Modified time, the heuristic
expiration value SHOULD be no more than some fraction of the interval
since that time. A typical setting of this fraction might be 10%.

If Internet Explorer 9 retrieves a cacheable resource which does not explicitly specify its freshness lifetime, a heuristic lifetime is calculated as follows:

max-age = (DownloadTime - LastModified) * 0.1

If a Last-Modified header wasn’t present in the server’s response, then Internet Explorer will fall back to the “Once per browser session” revalidation behavior.

As a result of the improvement to heuristic caching, Internet Explorer 9 can perform far fewer conditional HTTP requests when reloading many pages. For example, the following table shows the improvement when revisiting a typical article on a popular website:

IE8

IE9

Improvement

Revisit in new browser session (PLT2)

Request Count: 42

Bytes Sent: 26,050

Bytes Recv: 220,681

Request Count: 2

Bytes Sent: 1,134

Bytes Recv: 145,217

Request Count: -40
(-95.3%)

Bytes Sent: -24,916 (-95.6%)

Bytes Recv: -75,464(-34.2%)

The Caching Inspector in Fiddler will show you when a response expires, based on the headers provided on that response. For instance, here’s what you see for a response which contains an ETAG and Last-Modified header, but no expiration information:

Other Networking Improvements

In this post, I’ve enumerated the improvements in Internet Explorer’s caching code that help ensure web sites can make the most efficient possible use of the network. Of course, web developers should continue to follow best practices and specify their desired cache behavior using the Expires and Cache-Control headers, but even sites that fail to do so will load more quickly in IE9.

In a future post, I’ll describe other improvements we’ve made to the IE9 Networking Stack to further improve page load times.

-Eric Lawrence

ajaxian: Synthetic Event Library Syn Aims to Make Testing Easier

Rey Bango — Wed, 14 Jul 2010 16:54:17 +0000

The team at Jupiter IT have release Syn, a library which allows you to create synthetic events for use in testing. This standalone library is meant to assist in testing complex UI behavior by simulating user actions such as typing, clicking, dragging the mouse.

Testing rich, dynamic web applications sucks. At Jupiter, we've tried almost every testing solution available (qUnit, Quick Test Pro, Selenium, JsUnit, Env.js, TestCase) and all of them suffer from some fatal flaw.

Problems:

Manual - A tester has to run the tests manually on every supported browser. People are lazy.

Unit Tests Only - We need to test the app as a whole and complex UI behavior like drag-drop.

Low fidelity - We need to make sure the tests are reporting accurate results.

Difficult to write - We sling JS like a ninja monkey throws poo. We want to write tests in a nice JS API.

Expensive - A QTP license is 5k a person! I'd rather buy a vacation.

Support - We want to test Mac and Linux browsers.

We've solved all of these problems in our upcoming FuncUnit testing framework. It's a mashup of qUnit, Selenium, Rhino, and Env.js. But its core library, Syn, which does the work of simulating user actions with very high fidelity, is what we are releasing today.

So by using code like this:

PLAIN TEXT

JAVASCRIPT:

Syn.click( {},'hello' )
.type( 'Hello World' )
.drag( $('#trash') );

you can simulate clicking an element with id='hello', typing "Hello World", and then dragging your mouse from that element to an element with id='trash'.

Pretty cool stuff. Check out their demo to see how playback occurs.

Eric Meyer: Events Sold Out and Coming Up

Eric Meyer — Tue, 13 Jul 2010 19:20:52 +0000

Just before noon (Eastern U.S. time) today, An Event Apart Minneapolis sold its last available seat. That’s three events so far in 2010 and three sell-outs. If you were hoping to join us in Minneapolis but hadn’t registered yet, we’re sorry we won’t see you there! You can contact our Event Manager to get put on the waiting list, or you can join us for one of the remaining two shows of the year: Washington DC and San Diego.

There are strong reasons to prefer either one. In Washington DC, we’ll have our second-ever A Day Apart, a full day of in-depth learning with Jeremy Keith and Ethan Marcotte taking on the topics of HTML5 and CSS3, respectively. We ran A Day Apart in Seattle earlier this year as something of an experiment, and it was such a huge hit that we immediately decided to add it to a future show. We settled on Washington DC for a variety of reasons, not least of which was that the hotel had the space available to add a third day. So far as we know it’s the last time we’ll do A Day Apart in 2010, so if you’re interested, it’s the place to be.

San Diego, on the other hand… well, it’s San Diego! In November! It’s also the last chance to see our 2010 lineup of speakers, who’ve been consistently hitting it out of the park with insightful thinking and bold challenges to the status quo. We may never again see this particular combination of pure smarts and talent, so if you can’t make it to DC (or you’d rather just hit the beach in advance of Thanksgiving) then come on down.

From mobile design to advanced CSS to the latest in HTML5 to smart content to wonderful design, the sessions at AEA this year have been outstanding. The audience feedback has been really incredible, almost overwhelming. If you haven’t seen this year’s lineup, you should really consider checking it out. We’d love to see you there!

(P.S. Want to hear more about An Event Apart’s origin story, growth, vision, and future? Tune in to The Big Web Show this Thursday at 1pm Eastern U.S.! I’ll be a guest along with Andy McMillan—he of the fabulous Build Conference of Belfast—talking about web conferences and more. And if you miss the live show, don’t worry; there will be a lovingly edited version up shortly after we’re done taping.)

ajaxian: An alternative way to addEventListener

webreflection — Tue, 13 Jul 2010 13:00:42 +0000

I can't believe none of us knew DOM2

This is how a tweet from @SubtleGradient, re-tweeted by @jdalton, has been able to steal my rest tonight ... and this post is the consequence ...

What's new in a nutshell

There is a W3C Recommendation about addEventListener behavior, which clearly specify the second argument as an EventListener.
The new part is that no library I know has ever used a proper EventListener interface, preferring the classic attached callback instead.

PLAIN TEXT

JAVASCRIPT:

// this is how it is
document.addEventListener(
"click",
function (evt) { /* stuff */ },
false
);

// this is how it could be as well
var listener = {
handleEvent: function (evt) {

this === listener; // true

// and evt === classic event object

}
};

document.addEventListener("click", listener, false);

Benefits

The most common case that may disappear is well explained in this MDC addEventListener page.
Rather than bind inline or add anonymous functions to make our object call context preserved, we can simply add an handleEvent method to whatever object and pass it as EventListener.
Moreover, being close to full ES5 support and "use strict" directive where arguments.callee disappears, it may be more than handy to be able to perform such operation:

PLAIN TEXT

JAVASCRIPT:

An opened door for custom listeners

As I have recently posted, custom listeners implementation can be truly handy when we are dealing with events driven applications, but as soon as I have read the tweet, I had to rewrite a fresh new way to create a listener. Please note that following code is assuming that the browser supports both DOM Level 2 and Array extras, which is true for all modern browsers, mobile oriented included.

PLAIN TEXT

JAVASCRIPT:

function createEventListener() {

/*! Andrea Giammarchi for Ajaxian - Mit Style */

// a function declaration reused internally
function notifyEvent(callback, i, stack) {
// use DOM Level 0 events strategy
// to stop the loop if necessary
// checking if the result is exactly false
if (callback.call(
// the curent object as context
this,
// the classic event as first argument
event,
// the called callback (life easier)
callback,
// again the current context
// if the callback has been bound
this
) === false) {
// if false, reassign the current stack ...
eventListener["@"+event.type] = stack.slice();
// ... and break the current forEach loop
// (or, for the record, whatever Array.extras)
stack.length = 0;
}
}

var
// local scoped object, reachable internally
// usable as mixin so instances won't be polluted
// with all possible event types
// the type is prefixed in any case
// so that name clashes should be
// really rare however we use the object
eventListener = {

// we attach to a proper stack
addEvent: function (type, callback) {
var
// try to retrieve the stack ...
stack = (
// if already there ...
eventListener["@" + type] ||
// otherwise we create it once
(eventListener["@" + type] = [])
),
// as addEventListener, don't attach
// the same event twice
i = stack.indexOf(callback)
;
// so if it was not there ...
if (-1 === i) {
// FIFO order via stack
stack.push(callback);
}
},

// called via addEventListener
// the "this" reference will be
// the eventListener object,
// or the current instance
// if used as "class" mixin
// or via Object.create / clone / merge
handleEvent: function (e) {
// retrieve the stack
var stack = eventListener["@" + e.type];
// and if present ...
if (stack) {
// set temporarily the local event var
event = e;
// notify all registered callbacks
// using current this reference
// as forEach context
stack.forEach(notifyEvent, this);
// let the GC handle the memory later
event = null;
}
},

// how we remove the event, if any ...
removeEvent: function (type, callback) {
var
// try to retrieve the stack ...
stack = eventListener["@" + type],
// find the index ...
i
;
// if the stack is present
if (stack && ~(
i = stack.indexOf(callback)
)) {
// remove it
stack.splice(i, 1);
}
}
},

// I could have called this variable tmp
// but it's actually the current event
// once assigned ... so ...
event
;

// ready to go!
return eventListener;

}

Here a usage example:

PLAIN TEXT

JAVASCRIPT:

var lst = createEventListener();

/** mixin example (add a slash before this line to test)

function MyEventListener() {}
MyEventListener.prototype.addEvent = lst.addEvent;
MyEventListener.prototype.handleEvent = lst.handleEvent;
MyEventListener.prototype.removeEvent = lst.removeEvent;

lst = new MyEventListener;

// */

document.addEventListener("click", lst, false);

lst.addEvent("click", function click(e, callback, object){

alert([
callback === click, // true
this === lst, // true
this === object, // true
e.type === "click" // true
]);

// test that furthermore this
// callback won't be fired again
this.removeEvent("click", callback);

// add delayed a callback
// without any valid reason :-)
setTimeout(function (self) {
// test addEvent again
self.addEvent("click", function () {
alert(2);
});
}, 0, this);

// block the current notification
return false;
});

// the event fired only the second click
lst.addEvent("click", function () {
alert(1);
});

/** de-comment the mixin example to test
// that no @click is attached ;-)
for (var key in lst) {
alert(key);
}
// */

Advantages

both evt.stopPropagation() and evt.preventDefault() are not able to break the current notification of all attached listeners, if added to the same node, and while the FIFO order gives to the node "owner" or creator the ability to pollute the event object with some flag such evt.pleaseDontDoAnyOtherActionHere = true, not every library, script, or framework, may respect or understand this flag. With custom events we can adopt better strategies to actually avoid any other operation if this is what we meant, because we arrived before over the node and we may like to be that privileged
being custom, we can also decide which argument should be passed for each callback, simplifying most common problems we may have when dealing with listeners
we can better decouple DOM and listeners, being able to remove whatever amount of callbacks simply calling once node.removeEventListener(evt.type, this, false); inside any kind of notification
being based on standard and modern browsers, we can use native power, in this case provided by forEach and indexOf operations, so that performances will be best possible
thanks to automatic context injection, we can still reuse callbacks for different listeners, through bind, or simply considering the current context once called (or in this case the third argument by reference, if the context is different)

Last but not least, if we would like to fire an event we can bypass DOM initialization using handleEvent directly, e.g.

PLAIN TEXT

JAVASCRIPT:

lst.handleEvent({
target: document.querySelector("#myid"),
type: "click",

// custom properties
pageX: 0,
pageY: 0,

// stubbed methods
preventDefault: function () {},
stopPropagation: function () {}
});

Compatibility ?

Apparently both W3C behavior and provided examples are compatible with every modern browser with DOM Level 2 support, and I believe this is great.
The only one behind here is IE9 pre 3, but again @jdalton has acted at speed light, thanks!

ajaxian: Quilt: Stitching Your JavaScript Modules Together

Rey Bango — Tue, 13 Jul 2010 12:00:27 +0000

It floors me what young, talented developers are building these days. Kit Goncharov, who only recently turned 17, just cranked out Quilt, a JavaScript preprocessor written in JavaScript.

Quilt is very similar to the Sprockets JS preprocessor in that it allows you to improve code organization by logically separating your code into multiple modules within their own specific directories. Instead of having one massive JavaScript file with all your source code in it (increasing the potential for errors and complications), you can break out your code into separate physical files and at build time, allow Quilt to roll it all up, line by line, into a single file, ready for deployment. Via support for directives, you can tell Quilt about dependencies to ensure your builds are structured the right way.

In addition, if you use third-party frameworks in your code, Quilt allows you to specify a "load path" or "search path" which tells the preprocessor where to look for your specific lib. Then, when you build the final concatenated output, the library is included right in the source code.

Although Quilt was heavily inspired by Sprockets, it does have several significant differences. Perhaps the most obvious is that it's written in pure JavaScript (as opposed to Ruby) and runs on Rhino. This means it's very portable and easy for JS developers to understand. Quilt also uses a slightly different syntax than Sprockets for including files (for instance, it allows single-quoted pathnames, and uses backticks instead of angle brackets for specifying third-party code), and can strip multi-line comments as well as single-line ones.

As our client-side applications continue to grow, these types of solutions are becoming increasingly important for having a well-structured and maintainable codebase and it's great to see that the future development leaders are taking that into consideration. Be sure to check out Quilt along with Kit's other projects on GitHub.

ajaxian: Strobe; A hot new HTML5-touch startup founded by Charles Jolley

Dion Almaer — Mon, 12 Jul 2010 12:03:23 +0000

Charles Jolley: "I started working in SproutCore almost 5 years ago because I believe the future of software development lies in native-style apps in the web browser. It is the platform of the future and when that shift change happens, I want to be there with the technology. Now, I believe that time is almost finally upon us. It's time to double down, and that is why I am leaving Apple."

Congrats to Charles as he starts a new adventure. At Apple, he lead the charge on the open source SproutCore framework which powers Mobile Me and a bunch more.

He recently showed off SproutCore Touch and with it a killer demo. Instead of just saying "the Web can do as good a job as 'native' apps for some purposes" he showed it. He and SproutCore folk were there with two iPads. One had the native iPad NPR app, and the other had a *week long* port to SproutCore Touch. The funny thing.... the touch version performed better and even had a nice hidden feature. If you are listening to NPR and go to another app, it kept playing! Who knew!

For anyone wondering what the new company means for SproutCore, Charles makes it clear:

First, SproutCore is now and will always be totally free and open source. I think this business of charging for a commercial license is not an effective way to grow a project. Sure you make a little cash, but at what expense to the community? My goal is to make SproutCore and all of the developer tools that surround it totally free to everyone. All I ask is that you participate in the community somehow to make things a little better for those who come after you.

Second, now that I am no longer held back by big-company legal restrictions, I am going to be much more involved with the platform. Very soon I will post some new example code. Some others are working on new documentation and build tools to ease that pain as well. Starting this fall, my new company will also start to offer online and in person training and mentoring courses to your team get up to speed quickly. We can also finally get started in that book.

My goal is that by the end of the year, any average developer can pick up SproutCore, build, and deploy a basic app without feeling lost. This is open source and I can't usually guarantee timelines but at least now we can do what we need to make it happen.

With Strobe he wants to revolutionize "digital publishing". Put your thinking hats on to noodle on that one. One thing is for clear... it isn't just about making SproutCore Inc (as he discusses above).

Congrats Charles!

Wisdump: My Design Process, from Sketch to ZIP

Thord Daniel Hedengren — Thu, 08 Jul 2010 15:22:09 +0000

Today I’ll just point you to a post over at Devlounge, titled My Design Process, by yours truly. Basically, it’s a five step walkthrough on how I tackle design projects, generally speaking.

First, Consider the Problem
Second, Bring Out the Sketchbook
Third, Do that Mockup Thing
Fourth, Time to Code
Finally, Deliver and I'm Done

Take a look. I’m off to watch Alice Cooper hang himself.

Eric Meyer: Fixing Font Display in Thunderbird 3.1

Eric Meyer — Thu, 08 Jul 2010 12:59:26 +0000

If you upgraded Thunderbird and discovered that the fonts used to display messages suddenly changed, and worse still, you were unable to get all messages to obey your font display settings, then this post is most likely for you.

Here’s what happened to me: I upgraded to Thunderbird 3.1, and suddenly all my messages were in a font I didn’t recognize or appreciate. I insist on seeing only the plain text version (technically, the text/plain part) of all my e-mail; and what’s more, that it be displayed in a monospace font. Courier 13, in my case.

So I made sure “View > Message Body As” was still set to “Plain Text”, which it was. Then I went into the preferences and messed around for a bit. Eventually I set every font setting I could in “Preferences… > Display > Formatting > Advanced…” to be Courier and have a size of 13, and also to make sure that “Allow messages to use other fonts was not checked. All this was done, and Thunderbird relaunched to make sure the preferences stuck. They did, and most of my mail was displayed as I intended. And yet a number of messages, such as those generated by Basecamp, were still displaying in this new, thoroughly unwanted font.

At first I thought it was happening with any HTML mail, but after viewing source on a bunch of messages (using command-U, same as in any Gecko browser) that didn’t seem to be true. I Googled about and came across a post on Daniel Glazman’s blog which decried the problem in terms very similar to those I’d have used. Unfortunately, all the comments on the post told me was that the interloping font is Menlo, that this was a deliberate decision by the Thunderbird team, and that they didn’t seem to understand why anyone might be annoyed as hell to have their font settings changed out from under them with no apparent recourse. What they didn’t tell me was how to fix the problem.

Eventually, I tweeted a complaint—you know, the way you do—and Bryan Watson got me pointed in the right direction. Something just told me that if I dug around in the hidden preferences, I’d find what I needed. So I went to “Preferences… > Advanced > Config Editor…” and searched for “Menlo”. I got three hits, and it suddenly became clear what was happening: Menlo was being used for Unicode-based mail. Further, it would seem, the GUI options in “Preferences… > Display > Formatting” don’t affect the settings for Unicode mail. For whatever reason.

So I ran a new search in the Config Editor, this time for “unicode”. That got me several results, but it also got me what I needed: the settings for both the font face and the font size used to display monospace and “fixed” type in Unicode mail.

Accordingly, I changed three lines in the Config Editor—the ones in the screenshot which are boldfaced and have a “user set” value for the “Status” column—and with that, my mail was displayed the way I wanted it, which is to say the way it had been displayed for years, which is to say the way it would have continued to have been displayed if Thunderbird hadn’t silently changed the settings on me and then refused to honor my reasserted preferences.

If you’ve encountered a similar problem, now you can do what I did and hopefully avoid some of the annoyance I experienced in trying to get my mail client to behave properly.

[Update 8 Jul 10: Mook wrote in to point out where this setting is buried in the preferences UI, for those who might want to set it without diving into the Config Editor. Thanks, Mook!]

I’m also really rather annoyed that Thunderbird can’t seem to remember that I don’t ever want to see the Message Pane, but that’s a reported bug and I only hope that they fix it sooner rather than later.

ajaxian: Ben and Dion Step Down as Editors of Ajaxian.com

Ben Galbraith — Wed, 07 Jul 2010 20:48:51 +0000

In the spring of 2005, the two of us gave our first Ajax talk together. The subject of the talk was DHTML, but Jesse James Garrett had just coined "Ajax" a few days previous, so we sprinkled the term throughout the slide deck. We needed a place to put some source code that accompanied the talk--an RSS reader was called "RSS Bling". Ajaxian.com was born.

Here's a random picture someone took of us right before we gave that first talk:

(Surely we're just reviewing the slides in this pic, not hurriedly hacking together something at the last minute.)

Because the Ajax space was moving so quickly, we wanted a place to track the fun hacks, great libraries, and fantastic showcases that were coming out daily, so we started using Ajaxian to post Ajax news and very occasionally, an editorial. It's fun to think back to those early times; the web world was drunk with new possibilities and no one was really quite sure how the draw the boundaries.

After a few months, things were moving so fast we thought it would be great to get the emerging Ajax community together. With help from Jay Zimmerman of No Fluff Just Stuff and Chris Haven, we put together the first Ajax Experience show in San Francisco. It was incredibly fun seeing so many of the folks in person we'd been covering on the site, and sharing with the broader developer community what was now possible.

Our little Ajaxian blog grew over time--we still remember with awe when someone compared the traffic Ajaxian sent them to Slashdot--and we've gone on to co-produce several more Ajax Experience shows. It's been a thrilling ride.

Now, years later, it's time for us to formally hang up our Ajaxian hats. We've always juggled the site with our full-time jobs (various start-ups, Google for Dion, Mozilla, Palm, and now HP), and posting daily while balancing families and work can wear on you after a while--we can't do it all anymore. TechTarget (the company that has owned Ajaxian.com for some time) will take on editorial ownership of the site. We will still carry on posting every so often--it's in our blood--but it won't be on a regular schedule.

This transition comes at an important time for us. Palm was an opportunity to show the world that an OS based on the Web can be fantastic, but now, with HP's resources behind Palm, there's an even bigger opportunity ahead that will require all of our focus and energy. Oh, and it's summer, too. :-)

Thanks for being there for us over the years. We look forward to the next series of adventures. With HTML5 continuing to build steam and browser innovation hotter than ever, it is going to be a great time for us Web folk.

As always, you can keep up with us on Twitter: Ben and Dion.

All the best,

Ben and Dion

Eric Meyer: In Defense of Vendor Prefixes

Eric Meyer — Wed, 07 Jul 2010 17:53:44 +0000

…that having been the original working title for “Prefix or Posthack“, my latest article for A List Apart. (Sort of like Return of the Jedi had a working title of Blue Harvest.) In a fairly quick read, I make the case that vendor prefixes are not only good, they have the potential to be great and to deliver greater interoperability and advancement of CSS.

So far the reaction has been overwhelmingly positive, which frankly came as a bit of a surprise. The annoyance factor of prefixes is undeniable, and it’s been my experience that annoyance dramatically hardens opposition regardless of whether or not there are good reasons to oppose. I could flatter myself that the agreement is due to the Obvious Rightness of my argument, but I suspect it’s actually that I merely articulated what most people had already instinctively decided for themselves. Which isn’t a bad place to be.

Anyway, if you haven’t already, feel free to decide for yourself by reading the article"�which, I feel like mentioning for no clear reason, is only the fourth piece I’ve ever written for ALA.

Microsoft - IEBlog: A GPU-Powered Shopping Experience with Amazon.com

ieblog — Tue, 06 Jul 2010 23:48:00 +0000

A few weeks ago, we talked about the performance characteristics of our Flickr Explorer sample. We showed how hardware acceleration benefits real world scenarios such as browsing photos, and how easily web developers can build these types of applications.

Recently, we released a new set of demos alongside the third IE9 Platform Preview. Today we’re going to discuss the Amazon Shelf concept application (also see the companion Channel 9 video).

Much like Flickr Explorer, Amazon Shelf is written using standard HTML, CSS and Javascript. Amazon Shelf also incorporates a key new HTML5 feature – the canvas element. Canvas is an incredibly powerful way to draw directly to the screen using simple Javascript API calls.

When you launch Amazon Shelf, you’re shown a list of the top selling books from Amazon. This data is retrieved using the Amazon Product Advertising API. You can search for specific books, browse, and “open” books to view detailed information and customer reviews.

This demo uses common patterns that you find across many interactive web applications and games. There is one main loop that updates the books and other objects on the screen, and performs simple hit testing to support interacting with the elements on the canvas.

Canvas, like all graphics in IE9, is fully hardware accelerated by default. When IE9 users browse to a website that uses canvas, IE will automatically leverage the full capabilities of the PC to provide a great experience with levels of performance not possible with today’s browsers. Using IE9, Amazon Shelf is generally able to maintain a responsiveness of 60 frames per second, which is considered realtime. Today’s browsers are only able to achieve framerates of 1-8fps which is a small fraction of the performance provided by IE9.

We recently blogged about using the Windows Performance Tools to analyze browser performance. Using these tools, we’ve taken some measurements of loading Amazon Shelf in the top browsers available today. We used the same hardware and methodology discussed in the past. Let’s look at the CPU and GPU activity graphs to better understand how the demo performs in these browsers.

Note: Internet Explorer 8 is not included in this comparison since it does not support the Canvas element.

First up is Chrome 5. Chrome is able to update the screen once every 0.99 seconds, yielding a frame rate of about 1 FPS during the bookshelf load animation. This results in a very slow, choppy experience. One core on this dual core machine is fully utilized, and the GPU is not employed by the browser at all.

Here are the results for Safari 5. During the load animation, Safari does not attempt to render the scene at all, resulting in an effective 0 frames per second. Again, one core on the CPU is fully utilized and the GPU remains untouched.

Next up, Firefox 4 Beta. We used Minefield 4.0b2pre nightly for this analysis. Again, our tests ran this latest nightly build of Firefox (like all the others) in the default configuration. This means hardware rendering with the GPU was not enabled in Firefox.

Here are the results for Firefox. The animation is rendered properly, and the screen is updated twice every .25 seconds, yielding a frame rate of about 8 FPS.

Finally, let’s take a look at Internet Explorer 9 Platform Preview 3. We see that IE9’s full usage of the GPU results in a steady, smooth frame rate of 60 FPS. The CPU handles the task without any trouble and rests frequently while the GPU renders Amazon Shelf to the screen.

There is a meaningful difference in the experience when running the demo in IE9 compared to other browsers. Check out Amazon Shelf on www.ietestdrive.com to see for yourself.

We’d like to thank Amazon for their help in putting this demo together, and embracing the new GPU powered, standards based markup enabled by Internet Explorer 9.

Our team can’t wait to see what other graphically rich experiences web developers armed with hardware accelerated Canvas will dream up!

Seth McLaughlin
Program Manager for IE Performance

QuirksMode: Mobile Developer Economics report

Mon, 05 Jul 2010 16:07:23 +0000

Vision Mobile just released its Mobile Developer Economics report in which it presents the result of a poll of 401 mobile developers across the eight main platforms: Android, iPhone, BlackBerry, Symbian, Windows Mobile, Flash, Java ME, and the mobile web.

If you’re interested in the mobile developer world, download and read the report. It’s free, though a valid email address is required. Below I treat some interesting aspects of the research, including the quote from me Vision Mobile decided to publish.

Platforms

The parity between the installed base of a platform and the amount of apps available is totally absent. As one would expect, the iPhone app store offers way more apps than the OS’s relatively humble market share warrants. No surprise here. (p. 10)

What is surprising is that the most popular platform among the 401 developers is not the iPhone, but Android with 60%. iPhone comes distinctly second at around 50%, and the third most popular platform, Java ME, is not far removed from it. No clear iPhone superiority here.

The mobile web does decently at 40% (i.e. 40% of the developers use the mobile web from time to time). Flash is used by about 20% of developers. The long tail is composed of Linux, BREW, bada, and webOS. It should be noted, however, that bada has only just been released. Thus its meager score is quite understandable. This is not the case for the other three platforms. (p. 12)

It should be noted that developers who used Java ME were rather negative about the platform. One said:

The vast majority of Java ME developers have lost faith in the write-once-run-anywhere vision

Incidentally, which technology do you think has the best chance to take over this write-once-run-anywhere vision? Hint: it has existed for twelve years already and has already been deployed across all smartphones.

Striking it rich

Why do developers choose a platform? The clear number one reason is market penetration at 75%, with revenue potential coming second at 50%. The existence of an app store or a development community is important for only 40% of the developers. (p. 13)

Frankly I believe that reason number two is going to disappear. Mobile development is not a goldmine, although obviously you can earn a decent living by making apps for others.

On page 26 the report explicitly treats the long-tail economics. If you’re just a random developer who tries to make boatloads of money by selling apps, will you succeed? Vision Mobile doesn’t think so.

The economics for long-tail developers - i.e. the per-capita profit for the average developer - remains dubious at best.

In other words, Apple’s App Store is not a shortcut to riches. It can’t take the place of the hard work of founding a succesful startup, making a compelling product that people want to use, and selling it to a large player.

The App Store will dole out only niche income to most developers. Obviously there will be one or two notable exceptions to that rule. It’s a casino, after all, and the luck of the draw can be with you. Wanna try? Have fun, but don’t complain that you don’t make any money.

Why is this so? The report pinpoints two main reasons:

First, there are plenty of “garage developers” around who create apps not for the money, but for status among their peers. Usually they offer their work for free or a nominal fee. If such a free app competes with your paid one, tough luck.
The huge crowding especially in Apple’s app store forces developers to lower their prices in order to remain competitive.

Mastering a platform

How much time does it take to master a platform? Android clocks in fastest with five months. The mobile web comes second with six (yay!), though it has to share this place with Flash. Then comes iPhone with about 7.5 months. By far the toughest nut to crack is Symbian, where it takes 15 months before you’re proficient enough with the platform to write a couple of moderately-simple apps. (p. 32)

Operators

Finally, the report talks about operators, and this happens to be a subject I’m deeply interested in. The general conclusion is that operators don“t care a hoot about mobile developers, and treat them badly. Questions aren’t answered, there is a complete lack of focus with initiatives and websites cropping up all over the place, and operators aren’t interested in the long tail of niche developers.

In other words, ADHD-suffering marketing people jump hither and tither, and don’t care about anything remotely resembling long-term planning. I don’t think that’s going to change in the near future.

Furthermore the operators refuse to send people to industry conferences, instead electing to hold their own. I’ve been to several such events, and although it always works in the sense that it’s a moderate-good conference with moderate-good speakers, the fact that they’re free to enter but not free from marketing speak means that they’re soon forgotten.

I am convinced that the operators’ approach to conferences is wrong. I hope to prove that within the next year.

Which brings me to the quote from me Vision Mobile decided to include (p. 43/44):

The first mobile company to TRULY reach out to web developers will have an edge over the competition, but right now I don’t see any candidates. Except for Google, obviously. (And Apple, but they’re playing their own game.) If Google became an operator our problems would be solved.

To be honest I completely forgot about this thought until Vision Mobile contacted me for permission to quote me. Reading it back I feel I’m on to something. So yes, I agree with myself.

Wondering what Google’s next step will be? Becoming an operator. Especially in the totally dysfunctional American market. They’ll bring simple mobile billing to the world. Unless the traditional operators do it first, but there’s little chance of that.

Interesting idea, no? Not easy, no sir, not at all. But it’s the obvious next step as far as I’m concerned. Operatorship is where the money is. And where the need for innovation is greatest. We don’t have to expect anything from the current marketing-driven bunch.

ajaxian: text-rendering: optimizeLegibility; //Can you read me now?

Dion Almaer — Fri, 02 Jul 2010 11:27:52 +0000

text-rendering: optimizeLegibility;.

Awesome.

Microsoft - IEBlog: IE9 Includes Hardware Accelerated Canvas

ieblog — Fri, 02 Jul 2010 01:24:00 +0000

var ctx0, ctx1; var canvas0, canvas1; var wave = 1; var direction = 1; var timer; var HEIGHT2 = 100, WIDTH2 = 400; var count = 0; var currentX = 0, currentY = 0, lastX = 0, lastY = 0; var r = Math.floor(Math.random() * 255) + 70; var g = Math.floor(Math.random() * 255) + 70; var b = Math.floor(Math.random() * 255) + 70; window.onload=init; function init() { // Check to see if canvas is supported if (!document.createElement('canvas').getContext) return; // Set up canvas0 ctx0 = document.getElementById("canvas0").getContext("2d"); ctxWidth = document.getElementById("canvas0").width; ctxHeight = document.getElementById("canvas0").height; // Set up canvas1 canvas1 = document.getElementById("canvas1"); ctx1 = canvas1.getContext("2d"); ctx1.lineWidth = 25; ctx1.lineCap = "round"; // Add event handlers if (canvas1.addEventListener) canvas1.addEventListener("mousemove", OnMouseMove, false); else if (canvas1.attachEvent) canvas1.attachEvent("onmousemove", OnMouseMove); // Start the renderLoop timer = setInterval(renderLoop, 16); } function OnMouseMove(e) { if (typeof e == 'undefined') e = canvas1.event; if (typeof e.offsetX != 'undefined' && typeof e.offsetY != 'undefined') { currentX = e.offsetX; currentY = e.offsetY; } else { var relPos = getRelativePos(e.clientX, e.clientY); currentX = relPos[0]; currentY = relPos[1]; } } // My thanks to QuirksMode.org for the insight here function getRelativePos(x, y) { var curleft = curtop = 0; var obj = document.getElementById('canvas1'); if (obj.offsetParent) { do { curleft += obj.offsetLeft; curtop += obj.offsetTop; } while (obj = obj.offsetParent); } // Webkit isn't compliant with CSS OM View here; thus, we need to grab scrollTop from body instead of documentElement if (document.body.scrollLeft > 0) { var scrollLeft = document.body.scrollLeft; } else { scrollLeft = document.documentElement.scrollLeft; } if (document.body.scrollTop > 0) { var scrollTop = document.body.scrollTop; } else { scrollTop = document.documentElement.scrollTop; } return [(x - curleft + scrollLeft), (y - curtop + scrollTop)]; } function drawLines(ctx, x, y) { ctx.save(); ctx.beginPath(); ctx.moveTo(lastX, lastY); ctx.lineTo(x, y); ctx.strokeStyle = "rgba(" + r + "," + g + "," + b + ", 1)"; ctx.stroke(); ctx.restore(); } function clearLines(ctx) { // Clear first ctx.fillStyle = "rgba(0,0,0,0.05)"; ctx.fillRect(0, 0, WIDTH2, HEIGHT2); // Change up color if (count++ > 50) { count = 0; r = Math.floor(Math.random() * 255) + 70; g = Math.floor(Math.random() * 255) + 70; b = Math.floor(Math.random() * 255) + 70; } } function renderLoop() { // Draw lines clearLines(ctx1); drawLines(ctx1, currentX, currentY); lastX = currentX; lastY = currentY; drawSimpleShapes(ctx0); } function drawSimpleShapes(ctx) { // Draw background if (wave >= 60 || wave <= 0) { direction = -direction; } var gradient1 = ctx.createLinearGradient(0, 15, 0, 70); gradient1.addColorStop(0, "blue"); gradient1.addColorStop(1, "white"); ctx.clearRect(0, 0, 300, 70); ctx.fillStyle = gradient1; ctx.beginPath(); ctx.moveTo(0, 35); ctx.quadraticCurveTo(75, 70 - wave, 150, 35); ctx.quadraticCurveTo(225, 0 + wave, 300, 35); ctx.lineTo(300, 70); ctx.lineTo(0, 70); ctx.fill(); wave = wave + direction / 5; // Draw green rectangle ctx.beginPath(); ctx.fillStyle = "rgba(0, 255,0,.3)"; ctx.rect(10, 10, 50, 50); ctx.fill(); ctx.stroke(); // Draw blue circle ctx.beginPath(); ctx.fillStyle = "rgba(0, 0, 255,.3)"; ctx.arc(105, 35, 25, 0, 2 * Math.PI, true); ctx.fill(); ctx.stroke(); // Draw lines with decreasing widths ctx.strokeStyle = "black"; ctx.lineWidth = 10; ctx.beginPath(); ctx.moveTo(155, 15); ctx.lineTo(205, 15); ctx.stroke(); ctx.lineWidth = 8; ctx.beginPath(); ctx.moveTo(155, 29); ctx.lineTo(205, 29); ctx.stroke(); ctx.lineWidth = 6; ctx.beginPath(); ctx.moveTo(155, 41); ctx.lineTo(205, 41); ctx.stroke(); ctx.lineWidth = 4; ctx.beginPath(); ctx.moveTo(155, 51); ctx.lineTo(205, 51); ctx.stroke(); ctx.lineWidth = 2; ctx.beginPath(); ctx.moveTo(155, 59); ctx.lineTo(205, 59); ctx.stroke(); // Draw image var image = document.getElementById("ie-logo"); ctx.drawImage(image, 220, 0, 70, 70); }

With the recent release of the latest IE9 platform preview, we talked about how we're rebuilding the browser to use the power of your whole PC to browse the web, and to unlock a new class of HTML5 applications. One area that developers are especially excited about is the potential of HTML5 canvas. Like all of the graphics in IE9, canvas is hardware accelerated through Windows and the GPU. In this blog post we discuss some of the details behind canvas and the kinds of things developers can build.

Canvas enables everything from basic shapes to fully interactive graphics

Canvas is a way to program graphics on the web. The <canvas> tag is an immediate mode 2d drawing surface that web developers can use to deliver things like real time graphs, animations or interactive games without requiring any extra downloads.

At the most basic level, canvas enables you to draw primitives like lines, rectangles, arcs, Bezier curves, quadratic curves, images and video like the following:

This image is a simulation of what you'd see in a canvas enabled browser.

Please use the IE9 preview to see these examples running in canvas.

The Canvas Pad demo on the IE test drive site goes into detail on the canvas syntax and enables you to easily experiment with a wide range of examples. Feel free to make changes to any of the samples that are there to see how it works -- for example, try changing colors or sizes of things.

Taking things a step further, you can use JavaScript to animate canvas drawings or make interactive experiences. The next example draws lines as you move your mouse (or as you move your finger on touch enabled devices) over the black box. You could also choose to have your canvas experience react to keyboard input, mouse clicks or any browser event.

This image is a simulation of what you'd see in a canvas enabled browser.

With canvas support in IE9, you can move your mouse over the black box and draw lines.

By utilizing the full power of the PC with hardware acceleration for graphics and fast JavaScript for animation, web developers can use IE9 to build deep, graphically rich experiences. Since canvas is an element like other elements in HTML, it participates in the page layout and its API is exposed to JavaScript so it can be fully incorporated into a web page's design. This makes it possible for sites to include things like live data visualizations, games, splash pages and ads without the need for any extra downloads or plugins.

The IE testdrive site includes several examples that demonstrate the kinds of things that sites are now able to do in an interoperable way.

Shopping

The Amazon Shelf shows what shopping for books could look like when the web site designer is able to use the kind of graphics, animations and smooth transitions that canvas enables.

var vid = document.getElementById("myvid"); if(vid && vid.canPlayType && !vid.canPlayType("video/mp4").match(/^(probably|maybe)$/i)) { vid.parentNode.insertBefore(vid.firstElementChild, vid); vid.style.display = "none"; document.getElementById("image1").style.display="none"; document.getElementById("div1").style.width="377px"; } /*script to hide the play image if in IE8 */ if (vid && vid.canPlayType==null) { document.getElementById("image1").style.display="none"; document.getElementById("div1").style.width="377px"; }

Immersive game experiences:

The following demos showcase some gaming concepts like physics, character animation, collision detection and mouse interaction coupled with hardware accelerated graphics. In these demos, you'll notice that not all browsers can update the screen with the same frequency (FPS or frames per second). IE is able to maintain a high FPS by using Windows technologies to make use of your GPU - your computer's hardware that's optimized for rendering graphics.

FishIE Tank

This demo makes use of sprites to animate the fish and basic collision logic to redirect the fish when they hit the edges of the tank. It's also good for measuring graphics performance because you can change the number of fish to increase or decrease the graphics load.

var vid = document.getElementById("myvid2"); if(vid && vid.canPlayType && !vid.canPlayType("video/mp4").match(/^(probably|maybe)$/i)) { vid.parentNode.insertBefore(vid.firstElementChild, vid); vid.style.display = "none"; document.getElementById("image2").style.display="none"; document.getElementById("div2").style.width="377px"; } /*script to hide the play image if in IE8 */ if (vid && vid.canPlayType==null) { document.getElementById("image2").style.display="none"; document.getElementById("div2").style.width="377px"; }

Asteroid Belt

The asteroid in the demo follows your mouse, scales and rotates. It's an example of direct interactivity that you might find in a game.

Mr. Potato Gun

A physics engine in this demo defines how the different parts of Mr. Potato head are launched from the gun and then how they react when they bounce off the ground. Many games use some form of physics engine like this to manage particle movement and their response.

Canvas Zoom

This demo enables you to start with a very wide angle on an image like this mountain range and then zoom in very close image like people at a picnic. For games, it's an interesting example of scaling and smooth transitions.

Demos from around the web:

There are some pretty amazing demos floating around the web and I'd like to share a couple of our favorites -- there are many more. An important part of implementing canvas is that we do it in an interoperable way so that developers can use the same markup. To help achieve this goal, we're always looking for examples that work and those that don't. A future canvas blog post will go into detail about how we work to be interoperable and what we do when there's an issue reported.

I hope you enjoy some of these canvas examples from people around the web.

Cloth Simulation

This demo is interactive and the cloth is responsive to movement and gravity.

Zwibbler

The shapes in this drawing app are preserved so you can select and then move, resize, or change their styling.

Liquid Particles

The particles in this demo are drawn to or repelled from the mouse.

Kaleidoscope

This one does a nice job of drawing you in "� it's engaging and interesting to watch the patterns as they evolve.

Nebula Visualization

The alpha blending used by this demo are really well done. The result is a cloudy atmospheric look. It's graphics intensive and it's still very fast and smooth in IE9.

Animated Reflection

The author of this demo says, "The script is currently using 80% of my cpu so it's not really practical. Hopefully we will be getting JIT'd javascript sometime soon."� Well, now JavaScript is compiled in IE9. It generally uses about 1% of my CPU.

Asteroids in Canvas

This is a full game with nice graphics, collision detection, keyboard interactivity, score keeping and"� green lasers.

Particle Animation

See your name in lights. This is another demo that includes a particle system. You can run this with 300 or 1500 sprites. Go ahead and bump it up to 1500.

We're looking forward to seeing the kinds visual experiences web developers will be able to build with a fully hardware accelerated browser.

Give it a try yourself. Watch the videos, get the latest platfrom preview, try out the canvas demos and build some examples of your own. If you find a bug in how canvas works or where the same markup behaves differently, please report bugs on Connect.

- Thanks, Paul Cutsinger and Jatinder Mann

ajaxian: Firefox 4 with lots of speed improvements and inline SVG

Chris Heilmann — Thu, 01 Jul 2010 15:26:49 +0000

Mozilla went to London, England yesterday night to give a workshop about Mozilla Add-Ons and show some of the cool new stuff coming in Firefox 4.

Probably the most impressive thing (next to the new Add-Ons Builder based on Bespin) was the upcoming Features of Firefox 4:

HTML5 Video display
Painting with Canvas
Image manipulation with Canvas – pixel testing, face detection with opencivitas
Green screen technologies in images and video by detecting pixel colours.
HTML5 embedded inside SVG (yes!)
SVG as an IMG
SVG as a CSS background
SVG filter/mask/clip
SVG animations
Inline SVG inside HTML5
CSS3 (selectors, @font-face, 2D Transforms, Transitions, Shadow, Gradients ,calculations – calc(2em-10px) )
APIs: Geolocation, Offline (IndexDB, localStorage, AppCache, FileAPI – binary content of a file input, file drag and drop, web workers, websockets)
Websockets controller running the presentation from the mobile.
WebGL

They proved some of the points with demos:

CSS3 filters and SVG masking on HTML5 Video:

Highly interactive video interface with SVG masking and transitions:

WebGL in Firefox 4 and on Android:

After this, Tristan Nitot covered some of the other features of Firefox 4, especially the upcoming speed improvements:

As to upcoming features to the core of Firefox, we heard about:

TraceMonkey (a new Javascript engine)
Lazy Frame Construction
Reducing I/O from the main thread
Improved startup Time
Hardware accelleration
GPU text/graphics/video rendering
Using GPU for text rendering
JavaScript JIT (JaegerMonkey)
HTML5 parser running own thread
slicker interface
no more modal dialogs
no startup interuptions
updates in the background

For an in-depth report on all the things shown, check out this live blog post.

ajaxian: Keep your vows; Keeping wed to Node

Dion Almaer — Thu, 01 Jul 2010 11:14:55 +0000

Vows can be a beautiful thing. Alexis Sellier of LESS fame, is becoming an open source star. This time around he brings us Vows an asynchronous-friendly behavior driven development framework for Node.js.

Write you BBD specs like this:

PLAIN TEXT

JAVASCRIPT:

// division-by-zero-test.js

var vows = require('vows'),
assert = require('assert');

// Create a Test Suite
vows.describe('Division by Zero').addBatch({
'when dividing a number by zero': {
topic: function () { return 42 / 0 },

'we get Infinity': function (topic) {
assert.equal (topic, Infinity);
}
},
'but when dividing zero by zero': {
topic: function () { return 0 / 0 },

'we get a value which': {
'is not a number': function (topic) {
assert.isNaN (topic);
},
'is not equal to itself': function (topic) {
assert.notEqual (topic, topic);
}
}
}
}).run(); // Run it

and you get a very nice report card out of the other end:

With macros you end up with very nice DSL syntax such as:

PLAIN TEXT

JAVASCRIPT:

{ 'GET /': {
topic: api.get('/'),
'shoud respond with a 200 OK': assertStatus(200)
},
'POST /': {
topic: api.post('/'),
'shoud respond with a 405 Method not allowed': assertStatus(405)
},
'GET /resources (no api-key)': {
topic: api.get('/resources'),
'shoud respond with a 403 Forbidden': assertStatus(403)
},
'GET /resources?apikey=af816e859c249fe'
topic: api.get('/resources?apikey=af816e859c249fe'),
'shoud return a 200 OK': assertStatus(200),
'should return a list of resources': function (res) {
assert.isArray (res.body);
}
}
}

// or even
{
'GET /': respondsWith(200),
'POST /': respondsWith(405),
'GET /resources (no key)': respondsWith(403)
}

The website itself goes into exquisite detail on the install process, sample usage, and more. The website also happens to be beautiful itself, and full of HTML5 markup to boot.

WebDev FeedHouse

W3C: XHTML Modularization 1.1 - Second Edition is a W3C Recommendation

W3C: First Draft of Emotion Markup Language (EmotionML) 1.0 Published

W3C: Privacy Workshop Participants to Study Data Usage and Handling

W3C: First Draft of WOFF File Format 1.0 Published

W3C: Last Call: Cascading Style Sheets (CSS) Snapshot 2007

W3C: Cross-Origin Resource Sharing Draft Published

W3C: W3C Releases Unicorn, an All-in-One Validator

W3C: The Multilingual Web - Where Are We? Find out at the W3C Workshop

W3C: HTML Media Capture Draft Published

W3C: Last Call: Web Services SOAP Assertions (WS-SOAPAssertions)

W3C: Last Call: Mobile Web Application Best Practices

W3C: RDF Workshop Report Emphasizes Support for JSON, Turtle, Other Formats

W3C: Last Call: Authoring Tool Accessibility Guidelines (ATAG) 2.0, Implementing ATAG 2.0

W3C: For Review: Updated Techniques for Web Content Accessibility Guidelines (WCAG)

W3C: Contacts API Working Draft Published

Vitamin: PHP Login Form Part 1 [Video Tutorial]

QuirksMode: Four mobile links

Wisdump: Anorexic vs. obese layouts: you can't please everyone, but you should try

Elasticity is tricky

Custom-tailored user experience

Related reading:

ajaxian: Canto.js: An Improved Canvas API

Vitamin: Around the Web: CSS3 Animations, Agile + UX, Processed Identity

Vitamin: PHP Basics: Installation [Video Tutorial]

QuirksMode: Opera’s problems on mobile

Relative importance

Touch and viewport

Zooming

Two levels

Pre-emptive narrowing of text

Single tap

Opera’s problems

ajaxian: YUI 3.2.0 preview release 1 "� touch events support, transitions and browser-specific loading

Vitamin: Recurring Billing For Web Apps

Why do I Need this Service?

How do They Work?

Billing Systems vs. Payment Gateways

What’s on Offer?

But How do I Choose?

Conclusion

QuirksMode: Mobile payments made easy

The billing process

A question of identity

Future expansion

Waiting for Google

Vitamin: Around the Web: Inspiredology, Avatars in Motion, & Quite Strong

ajaxian: Canvas Color Cycling

Vitamin: Exception Handling in PHP5

What are Exceptions?

Handling Exceptions

Inside an Exception

Throwing Exceptions

Extending Exceptions

Uncaught Exceptions

Exceptions in Your Applications

QuirksMode: New kid on the browser block: Samsung Dolfin

The good parts

The buggy parts

ajaxian: Looking at JS emulator core for GameBoy

Vitamin: Around the Web: Forrst's App Contest, inForums, Cow Clicker

Vitamin: CSS3 Transitions Part 1 [Video Tutorial]

Vitamin: The 7 Sins of Managing Web Projects

Pride

Envy

Gluttony

Lust

Anger

Greed

Sloth

ajaxian: Dojo 1.5 is Out and it's Feature Packed!

QuirksMode: Antennagate and Apple’s hubris

Antennagate

Apple pisses off everybody

Hubris

Wisdump: Prettier Posts: Clean Up Those Listings

Related reading:

Vitamin: Think Vitamin Interview: Dan Cederholm at FOWD London 2010

Stopdesign: My Measures & Dimensions

QuirksMode: The Firefox problem