Recursive Drawing is an exploration of user interface ideas towards the development of a spatially-oriented programming environment.

The mobile landscape today is all but monopolized by WebKit, as a result, most of the tooling and infrastructure to support mobile web development on the frontend is taking place in the WebKit Inspector, so I’ll focus on it, and take a deep dive into its entire feature-set and how and when to use it.

Google and the Chrome team have been pumping a ton of resources into the WebKit Inspector. The changes have enabled a whole new class of complex and ambitious applications that would have otherwise collapsed on their own weight. This is great news, of course, but as I talk to more and more web developers about their process and tooling, it became clear to me that many of them haven’t caught up with the changes or aren’t making effective use of the tooling available. This blog post attempts to remedy that, not only by walking you through the inspector’s feature set, but also highlighting certain techniques for bug hunting and feature development that I’ve found to be indispensable.

Baseline vs. progressive JPEGs

Baseline are the “normal” JPEGs, the type of JPEG that all image programs write by default. The browsers load them top-to-bottom as more of the image information comes down the wire.


Loading a baseline JPEG, click to enlarge

Progressive JPEGs are another type of JPEGs, they are rendered, as the name suggests, progressively. First you see a low quality version of the whole image. Then, as more of the image information arrives over the network, the quality gradually improves.


Loading a progressive JPEG, click to enlarge

From usability perspective, progressive is usually good, because the user gets feedback that something is going on. Also if you’re on a slow connection, progressive JPEG is preferable because you don’t need to wait for the whole image to arrive in order to get an idea if it is what you wanted. If not, you can click away from the page or hit the back button, without waiting for the (potentially large) high quality image.

A reason against progressive JPEGs I’ve heard is that they look a bit old school and that users might be underimpressed, if not irritated, by the progressive rendering. I am not aware of a user study that focuses on this issue, please comment if you have heard or conducted such a experiment.

One of the more interesting questions raised by the new iPad and its retina display is whether or not web sites should deliver higher resolution images when there is no way to know the connection speed. AppleInsider found that Apple.com is being prepped to deliver high-res images and documented how you can test it in Safari on your desktop.

As you can imagine given my research on responsive images, I was keenly interested to see what approach Apple took.

What they’ve chose to do is load the regular images for the site and then if the device requesting the page is a new iPad with the retina display, they use javascript to replace the image with a high-res version of it.

The heavy lifting for the image replacement is being done by image_replacer.js. Jim Newberry prettified the code and placed it in a gist for easier reading.

I unashamedly maintain that there is so much more to being successful on the mobile web than dealing with screen size. But I do accept that dealing with screen size is at least a first step.

Thank goodness then, that the matter of screen size is so simple and well understood.

Really?

As web developers, we will often need to know the screen size of the device we are displaying content on. Perhaps on the server, perhaps on the client, perhaps to be used as a clause in a media query.

But how best to measure it? And what are we measuring anyway? On the client-side, for instance, a variety of ways exist to determine screen and page size: things like screen.width, window.outerWidth, document.body.clientWidth, and so on. But these properties are infamously unspecified by any standards: so what do they all mean – and how reliable are they on mobile browsers?

I haven’t done serious web work — HTML web work, that is — since I last worked on Manila 10 years ago.

I’ve done some small things — the system that generates this blog, for instance — but I haven’t had the chance to use almost any of the newer web technology. I’ve never written a Rails app, used JQuery, or deployed to a virtual server.

So when I had the chance to re-do the websites for our company and main product, I was excited — because it meant I could try some of the new technologies and learn some things.

As mobile devices have continued to evolve and spread, so has the process of designing and developing Web sites and services that work across a diverse range of devices. From responsive Web design to future friendly thinking, here's how I've seen things evolve over the past year and a half.

Sharing a link is one of the simplest and most social actions you can take on the web. It should be consistent across platforms. And Facebook has broken it (at least to leave Facebook) adding unnecessary complexity and poor user experience to an action the rest of the web thrives on.

But it isn’t just Facebook.

Other media entities are yielding their presence to the stream and short-circuiting the ability for users to share their content. They are helping Facebook gaslight the web.

Folio Focus has an article up titled ‘How to Choose a Web Designer’. It talks a lot about using design galleries to find someone experienced, who fits your budget and has the right style and skillset.
But these questions are trivial compared to the important stuff. They’re questions to ask the designer himself after you’ve identified him as a likely candidate.
Here, in five simple steps, is how to actually choose a web designer:–

For as long as I remember, HTTP cookies have been vilified as a grave threat to the privacy of online browsing; wrongly so. That said, the mechanism itself is a very interesting cautionary tale for security engineers - and that will be the theme of today's feature.
Cookies were devised by Lou Montulli, a Netscape engineer, somewhere in 1994. Lou outlined his original design in a minimalistic, four-page proposal posted on netscape.com; based on that specification, the implementation shipped in their browser several months later - and other vendors were quick to follow.

Artikel om "grid-based design" för webbsidor. Innehåller även exempel på en del snygga sajter.

Hur man kör IE8, IE7 och IE6 samtidigt i en Windows-installation.

En bra genomgång av Javascript.

Ett tips om hur man kan använda Quicksilver för att söka webbsajter (eller sökmotorer).

Rasmus Lerdorf visar hur man bygger en enkel webbapplikation med SQLite, PDO och lite Ajax.

En översikt över avancerade sökmöjligheter hos Google.

En artikel om Yahoo! Web Services och hur man kan använda dem.

A List Apart om hur man bäddar in flash-filmer på ett sätt som fungerar med webbstandarder.

Hur man gör en droppskugga som ligger stilla när man scrollar sidan.

Hur man gör en global reset av allt "vitutrymme".

Artikel om Stand för Safari

En artikel om PNG. Detta är ett test för att se hur bra Furl fungerar.