If we take Steve Jobs at his word, then a question for web developers to ponder is whether or not this new TV will include a browser. Let’s take a look at some of the arguments for and against including a browser.

Reasons why a new Apple TV will not include a browser

• The current Apple TV does not have a browser.
• Browsers on TVs have not had the best user experience and adoption has been low.
• When announcing the latest Apple TV, Steve Jobs said, people “don’t want a computer on their TV. They have computers. They go to their wide-screen TVs for entertainment. Not to have another computer. This is a hard one for people in the computer industry to understand, but it’s really easy for consumers to understand. They get it.”

Reasons why a new Apple TV might include a browser

• Apple TV is built on top of iOS and has the WebKit rendering engine built in.
• People jailbreaking their Apple TV have been able to get access to the browser.
• There is a good chance that an App Store for Apple TV would be one of the major mechanisms for getting new content to the Apple TV.
• If Apple TV had an App Store, support for embedded webviews would be necessary as many apps these days combine native and web components including Apple’s own iTunes, Apple Store, and App Store apps.
• If embedded webviews and an App Store are available, someone will build a browser absent a specific policy from Apple against browsers. Such a policy seems unlikely as it would be difficult to enforce and cause an unnecessary backlash.
• If others are going to create browsers for the platform, it makes sense that Apple would want to define the default browsing experience by shipping Safari on the platform.
• Steve Jobs has a history of dismissing something until Apple has solved how it wants to implement it (see: multi-tasking in iOS).

Why worry about what Apple will do?

It wasn’t too long ago that people believed no one wanted to use the web on their mobile phones. The iPhone proved that to be wrong.

Now we hear similar refrains about how no one uses the web on their TV. If Apple releases a new TV and they include a browser, we may again see a shift in user behavior that would disprove those assertions.

If that happens, the challenges of building web pages will again increase as we all start to consider how to address a new form factor that we’ve long ignored.

But since I wrote the post, the idea that advertisers want to target mobile web differently than desktop web keeps coming back into my thoughts.

Last year there was a bit of debate about whether or not there is such a thing as the mobile web. I wrote about this in my post On My Context. There are links in that post to much of the online conversation at the time.

I don’t want to rehash all of that conversation. Instead, I want to highlight one paragraph from my post on the business challenges of RWD:

Sometimes advertisers just want to advertise on one form factor and not another. App developers who want to drive app store purchases may not be interested in advertising on desktop. An advertiser interested in location-based advertising is also unlikely to consider responsive advertising desirable.

I wrote that paragraph without thinking much about it. It seemed obvious then and even now I find it hard to refute.

When it comes to advertising, it seems clear that there is value in distinguishing the mobile web from the desktop web (and yes, the tablet web, the tv web, etc.).

Whether or not the way advertisers look at the mobile web can or should influence the way web site publishers look at the web is a separate question. A question that I keep finding myself pondering without resolution.

Search Engine Optimization

Google, Bing and Yahoo all have different search bots for mobile. Google’s recommendations on how to make sites mobile friendly are all based around building separate sites and then ensuring that the Google mobile bot is redirected to the mobile version. Matt Cutts has talked about this in a video answer and Google has gone so far as to describe how you should redirect the Google mobile bot in some detail.

What does this mean for sites using responsive web design? Honestly, I don’t know. Nor does anyone else it appears. There is some question about whether or not mobile SEO is even worth pursuing.

But it is worrisome. Google recently announced that mobile website optimization now factors into mobile search ads quality. I’ve seen no indication that Google is considering responsive web design in its definition of mobile optimization. The announcement linked to several case studies and articles illustrating separate sites as the approach.

This is probably a problem with the search engines and not with responsive web design as a technique, but if a company relies on search engine traffic for revenue, it likely won’t matter who is to blame.

Advertising

There’s been a lot written about the difficulty of incorporating advertising into responsive design. Most of the focus has been on the fact that ads aren’t designed to be responsive breaking responsive layouts.

But there is another more structural issue: sometimes advertisers just want to advertise on one form factor and not another. App developers who want to drive app store purchases may not be interested in advertising on desktop. An advertiser interested in location-based advertising is also unlikely to consider responsive advertising desirable.

Will responsive web designs be able to participate in the growing mobile advertising opportunity?

Analytics

Most web analytics tools that support mobile provide an option to use a server side way of tracking instead of tracking via JavaScript. This is offered because many older devices either don’t support JavaScript or support it so poorly that using JavaScript-based tracking code is problematic.

Bryan and Stephanie Rieger have talked about how in their experience switching to the server-side code will show a lot more mobile traffic from a wider variety of devices than if you stick to the JavaScript version.

The problem is that you can’t run both the JavaScript and the server-side (mobile) variant on the same page. The analytics vendors recommend using the server-side code on your mobile site and the JavaScript one on your desktop site because the JavaScript version has a lot more data and features than the server-side one.

Sites using responsive web design will need to choose between more accurate data about the total mobile traffic (server-side tracking code) or deeper information about a small set of visitors (JavaScript tracking code).

Content Delivery Networks (CDNs)

On a responsive web design that takes care to provide only the assets that are appropriately sized for the device requesting the page, the images will vary based on the device. This causes problems with content delivery networks that have become accustomed to being able to cache a single asset for all devices or at worst caching a desktop and a mobile version of the asset.

As Ronan Cremin put it, CDNs may now need to cache different images based on the entire spectrum of devices accessing a site. FWIW, depending on how they are implemented, this can be a problem for separate sites as well.

One way in which RWD does not resemble the transition to standards

The move towards responsive web design has been compared by many to the changes that happened when web design went from being table-based to using web standards and CSS layouts. The Boston Globe’s new site has been compared to the impact that the ESPN and Wired redesigns in proving the value of web standards.

It may be that my faulty memory, but I don’t remember a similar list of potential drawbacks from a business perspective to making the change to CSS-based layouts. If anything, things standards-based layouts had great business benefits because of the increased semantic markup leading to better search rankings and the leaner code helping with page performance and bandwidth costs. Yes, like responsive web design, retraining staff and changing infrastructure could be a major undertaking, but there wasn’t concern that making a change would negatively impact search rankings or make analytics more difficult.

And I honestly don’t know how big of a problem any of these things are with the exception of the analytics problem which seems clearly to be a pickle. It may be that search engine rankings aren’t impacted at all. But the fact that we don’t know seems like something that should be sorted out and considered if those things are critical to the success of a given project or client.

And to be 100% clear, I’m not saying people shouldn’t do responsive web design. Even if you were to build separate sites, you should still do responsive web design for the separate sites.

I’m simply saying these are challenges and concerns that I don’t think we’ve currently got good answers for.

But we’ve got a problem. We came up with a fun theme (Zombie Apocalypse!) to make the workshop interesting, but we’ve heard people were reluctant to register for the workshop because they didn’t get it.

Since we heard about the registration problem, we’ve lept into action:

• We’ve rewritten the workshop description so it is clearer what people will learn at the workshop.
• We’ve posted a fun preview of the talk. The preview made me giggle multiple times when I read what Lyza had wrote.
• We’re here asking for your help.

We need your help getting the last minute word out. If you can take a moment to share the event, we would appreciate it. Particularly if you know people in New York who would benefit, we would be grateful if you pass the word onto them directly.

And of course we have discounts to share

WebVisions has provided us with a way to save 40% on conference passes. There are two options:

1. Save 40% off a conference pass, get a FREE pass to Thomas Phinney’s “Web Typography Best Practices” workshop ($250 value) and a 60-day unlimited WebINK account (register at http://wvnyc-webink.eventbrite.com/), OR
2. Save 40% on conference passes to WebVisions NYC and receive a FREE Workshop pass ($250 value) to Kevin Hoyt’s “Web Standards Playground” (register at http://wvnyc-adobe.eventbrite.com/).

I honestly had to read that a few times to make sure I understood the deal correctly. Seriously, 40% off and you get a free workshop? My guess is that Adobe and WebINK are helping sponsor the discounts which is pretty cool way to get into a workshop and save money.

WebVisions is a fantastic event

WebVisions is new to New York, but it has been going on in Portland for several years now. It always has fantastic speakers and the line up in New York is no different. Please help us make the event a success.

Thanks in advance for spreading the word. We greatly appreciate it and promise we’ll be less cutesy and more descriptive in our workshop abstracts from now on.

I concur. A couple of months ago, I asked what you preferred as a solution for responsive images. At the time, I didn’t have a strong opinion. But over the last couple of weeks, I’ve become increasingly comfortable with a direction that Scott Jehl, Ethan Marcotte and I discussed on twitter recently.

Short run solution: preparse attribute

In September, Scott Jehl proposed a solution that might be fairly easy for browser makers to implement in the short run: adding a preparse attribute to the script tag.

Like the defer and async attributes, there is a general use case for document authors to be able to tell the browser that a piece of javascript will impact the loading of assets and thus should be executed before parsing begins. There are probably even use cases that have nothing to do with asset downloading where telling the browser to execute javascript before parsing would be beneficial.

One of the other suggestions for solving this was for browsers to standardize on how they load assets. I don’t like that idea because it prevents browsers from experimenting on ways to parse pages and load assets more quickly.

If authors explicitly tell the browser when javascript loading matters (preparse, defer or async), it allows browser makers to experiment freely in other situations.

Long run solution: improvements to img tag

In the long run, I don’t like the idea that solutions require javascript. Images are content or presentation which means it should be possible to handle it with HTML and CSS alone.

Therefore, I would like to see one of these two improvements to the img tag:

Modified from Bryan and Stephanie Rieger’s Rethinking the Mobile Web talk.

This is my preferred option, but I’m unclear on how older browsers would handle an image tag that contains child elements.

Isaac Lewis put together a test page using this style of markup. It would be great to collect some feedback on old browser support to see if it works or causes problems.

If that won’t work because of legacy browsers, the following variation proposed by Anselm Hannemann should:

Why not headers?

I would love the browser to send more data to the server about the device making the request, but I don’t think servers should be necessary for the image tag to work in a responsive design.

I also think there is a decent chance that screen size is just the first of many headers we’d like the browser to send along. I don’t want to open up pandora’s box, but it would be nice to get something that felt more like a comprehensive solution instead of a bandaid.

Why not a different, progressive image format?

I’d love this, but feel wholly unqualified to judge what it would take. I’m not sure how long something like that would take to implement and what sort of patent minefield might lie there.

So let’s start with the preparse attribute

Unless someone points a major flaw with the preparse idea, I’m going to submit it as a feature request to the appropriate people to get the ball rolling.

Which reminds me, does anyone know where I should start?

The entire post was about what technique to teach in the book we’re writing. A book that has a deadline at the end of the month.

Jeremy writes:

The solution seems clear: we need to standardise on browser download behaviour …which is exactly what the HTML standard is doing (along with standardising error handling).

That would be awesome. Doesn’t help with the book. He continues:

That’s why I was surprised by Jason’s conclusion that device detection is the future-friendly img option.

Two bits of clarification:

1. The thing that makes it future friendly isn’t the device detection. It is the fact that the markup is unchanged. It buys people time until either browsers standardize download behavior, we have a replacement for the image tag or someone finds a yet undiscovered way to solve this problem. Every other technique requires changes to the markup that are specific to a particular solution and rely on browser behavior that hasn’t been standardized.
2. Again, my post was in regards to the questions I asked about which technique to teach in the book. I outlined the constraints of the book series and talked about how I entertained the idea of teaching the noscript technique before being talked out of it. Basically, I provided a lot of context for how I was evaluating the techniques for the book.

In addition to standardizing download behavior, Jeremy describes ways that he would like to see device detection improve. All of these are advances we’d welome. They are things that we might even have time to work on once the book is complete. But they aren’t the constraints I outlined in my posts and thus the rebuttal misses the mark.

So yes, device detection, as Jeremy says, is present-friendly way of keeping you from butchering your markup in a way that kinda, sorta works with today’s browsers, but may not work for tomorrow’s browsers.

However, having clean, semantic markup that so you can quickly replace device detection with a better solution in the future is the part that is attractive and arguably more future friendly than picking one of other unproven solutions and littering your markup in the hopes these solutions prove to work in the long run.

With that, I’ll conclude the same way I did my last post:

At least that’s how I see it for the book. For your project and use case, it depends.

The post worked. I got some great feedback, and I’ve decided against using noscript in the book.

Instead, I’m going to use Sencha.io SRC (aka TinySRC) in the book. Much to my surprise, it seems like the most future friendly option.

The problem with the noscript version

Sometimes I need something explained to me multiple times before I get it. Understanding why using noscript was a problem for semantic markup was one of those times.

Fortunately, Stephen Hay got through my thick skull with this paragraph from an email he sent:

Noscript means we get an empty arbitrary container element and a noscript element in our HTML, which is meaningful only within the context of this particular solution. Other methods, take Scott Jehl’s
data-attr method as an example, at least begin with an image element. This, in contrast to the noscript technique, is meaningful in *any context in which HTML can be understood*, whether by machines or by people.

Brad Frost and Bryan Rieger also provided helpful feedback that reinforced Stephen’s point and jarred me back to my senses. And Steve Souders pointed out a bunch of performance issues I hadn’t fully considered.

Device detection as the most future friendly option

In a follow up email, Stephen laid out a line of logic that made choosing to teach TinySRC a no brainer. I will attempt to paraphrase it here.

While there are many responsive imgs techniques, they primarily fall into three main approaches:

1. Client side solutions that rely on cookies and browser parsing order. — These solutions can be done with semantic markup, but they rely on current browser behavior. Yoav Weiss has done some tests on preloaders and cookies showing that images sometimes get downloaded before the cookie is set. Because this is based on the current way browsers parse documents and not a standard, it could break at any time.
2. Noscript techniques. — Works reliably, but is an obvious hack (and a brilliant one). Not sustainable because the markup of the page no longer contains the full meaning that it once had.
3. Images being handled by device detection. — Device detection uses the user agent string to make decisions. I’ve been referring to device detection as the third-rail of web development. Like politics and religion, device detection is a topic you want to avoid if you want to have pleasant conversations. But a lot of people use TinySRC without incident.

For the book, we need to pick something that will stand the test of time. That’s what makes me nervous about option 1. Who knows when it will suddenly stop working (if it hasn’t already given Yoav’s tests).

Between options 2 and 3, we have a hack that requires us to change our markup in a solution-dependent way (noscript) and a solution that relies on the very thing most web developers have come to despise (user agent based detection). Here I must quote Stephen again because he says it so well:

When you asked about future-friendliness, I tried to think ahead to the future and imagine what the state of these documents might be. My stance is that when we no longer need device detection, we simply remove it. All of our files are intact, as they have been left alone. Our markup is still meaningful. The content is still properly structured. Not so with the noscript hack, which requires us to revert to the markup we could have had in the first place. The choice—for me at least—was clear: device detection is a pluggable solution, which can be “unplugged” once a better solution comes along.

The idea that something like TinySRC is a pluggable solution which can be unplugged is incredibly compelling. We don’t have a fantastic, client-side only solution. Or at least, we don’t have one that I feel confident enough in to include in a book and not fear that it will look foolish six months from now.

Plus, Stephen is not a fan of device detection. He isn’t simply falling back to what he is comfortable with. If anything, it is the opposite of what he would prefer to do.

I do have some concerns about teaching something that relies on a third-party like Sencha.io SRC, but I feel James Pearce will keep it running through sheer force of will if nothing else. And if it does go away, the book does teach device detection fundamentals which would give someone the basic tools they need to create their own image service.

How strange it is to think of device detection as the most future friendly of the three options? I find it hard to argue with the logic.

At least that’s how I see it for the book. For your project and use case, it depends.

After agonizing over this for a couple of weeks, I’m leaning towards using the noscript technique as the primary example in the chapter with additional information on where to find the other approaches.

I’m towards this approach despite the fact that Scott Jehl, Ethan Marcotte and Brad Frost all feel that the noscript technique isn’t future friendly. So as you can imagine, I’m terrified that I’m making a big mistake.

As I understand it, the argument against noscript as a technique is that it isn’t semantic markup. The attributes for the eventual img tag are put on the noscript tag which isn’t where they belong. Attributes for images belong on the img tag.

I’m probably butchering the arguments against noscript which is why I’m writing this post in hopes of understanding it better before it is too late for the book.

Why teach the noscript technique

Here are the reasons why I’m leaning towards using the noscript technique in the book:

• We need to use one technique to build a web page in the chapter.
  A few people suggested talking about a few different techniques and their relative merits instead of teaching one technique. That might work in a different kind of book, but won’t cut it for a Heads First book. Every chapter is structured to include a real project, exercises and working code.

  We can talk about how all of this is very new, but at some point we need to show how to the handle images on the web page that the learner is building in the chapter.

  It is easiest to think of the chapters as stories. We have a protagonist (the learner) and a journey they are on. Teaching multiple techniques would be choosing one path for the story, go down that path, and then suddenly say, “Alright, now let’s go back to where we started and go down that other path.” It wouldn’t work.

• I want to avoid server-side resizing of images.
  I know server resizing of images is probably a core part of a long term solution, but I need to teach the challenges of determining the size of the screen and picking the appropriate image. How do you tell the browser what image to download? After we’ve taught the challenges, then we can talk about server-side resizing. Otherwise, it seems like there is a magical black box taking care of things for us.

• I can’t guarantee that the other techniques will work.
  Every other client-side technique relies on assumptions about the order in which browsers will load assets. We’ve already discarded dynamic base tags because the browser behavior changed and images were getting loaded twice. Yoav Weiss has done some tests on preloaders and cookies showing that images sometimes get downloaded before the cookie is set. This will result in multiple image downloads.

• We don’t have a wide deployment of any of these techniques.
  The Boston Globe’s images haven’t been fixed yet. Our book deadline looms. Whatever we choose is going to be unproven.

• I can explain why noscript works. Yes, the noscript solution is easier to implement because it doesn’t require Apache rewrite rules and cookies, but that alone wouldn’t be enough to cause me to shy away from it. We’re teaching WURFL in the book so we’re not shying away from teaching complex things.

  When I say I can explain how noscript works, I mean I can explain clearly why images don’t get downloaded. The browser knows before the page loads whether or not javascript is available. If it is available, the img inside the noscript tag won’t get loaded. This behavior is easy to understand and reliable. It has worked this way since the noscript tag was created.

  After all of this research, I still don’t have a clear explanation of the preloading behavior of browsers. Without doing extensive testing or reviewing the loading code for every browser, I don’t think we’re ever really going to understand how it works nor be confident it won’t change in the future.

• Elegance of a wading hippo notwithstanding, noscript works.
  As far as I can tell, it works 100% of the time. I’ve been trying to think of conditions in which it wouldn’t work and haven’t come up with any.

• Tyler Sticka would teach noscript.
  In addition to being a fabulous web designer, Tyler teaches a college course on web design and development. I had the opportunity to speak to his students last year. When I think about whom we’re writing this book for, I think about people like Tyler’s students. Because of that, Tyler’s endorsement means a lot to me.

To summarize, it feels like I have to choose between semantic purity and something that works reliably. Because the focus of the book is on the practical, not the theoritical, I think we have to choose the solution that works while pointing out the problems with it. We’re absolutely going to talk about how this is the bleeding edge.

Avoiding a spacer gif mistake

Back in 1995 when David Siegel was writing Creating Killer Websites, it is unlikely that he could anticipate the impact his book had on web development. Similarly, I can’t know what impact our book will have.

While it may be illusions of grandeur to think it matters much which technique we pick in our book, I do feel a great responsibility to avoid doing harm. I don’t want to find myself in Siegel’s shoes five years from now writing a mea culpa about how The Web is Ruined and I Ruined it.

Hence this post. One last chance to hear arguments for why we shouldn’t teach the noscript tag and what we should teach instead.

And if you’re reading this five years from now and the web is in fact ruined: I’m sorry. I did my best.

Here’s what I’ve seen:

• Video (especially embedding third-party video) — Looks like Fitvids.js is the solution a lot of people are using. See also Elastic Video. BTW, if you’re doing a lot of video, it is probably a good idea to look into how you can use HTTP Adaptive bitrate streaming to send different quality video based on data connection and CPU.
• Data tables — Chris Coyier’s excellent Responsive Data Tables article explains three different possibilities for solving this.
• Third-party ad networks and social widgets — This is biggest problem. It’s a problem whether you’re doing responsive design or not. Scott Jehl talks a little about how they handled ads on the Boston Globe in his presentation from the Breaking Development Conference (pg 97).

What am I missing? What other challenges do you see?

One of common conclusion from the commenters is that our current IMG tag isn’t going to cut it. That we need some sort of replacement that is future friendly. This isn’t the first time the idea of expanding or replacing the IMG tag has come up.

I promised to collect some of these proposals so we can discuss their relative merits.

Current proposals and discussions to replace or extend the IMG tag

As far as I know, there hasn’t been a formal proposal submitted to any standards bodies, but there have been several conversations worth highlighting. I was going to try to summarize the various proposals, but there hasn’t been a lot of consensus. I’m afraid that to get up to speed, you’re going to have to read the threads.

Adaptive Images on W3C HTML mailing list

At the end of May, Dom Hazael-Massieux kicked off a lengthy thread talking about Adaptive Images with two ideas: a srclist attribute and new image file format that would be a text file containing a list of images.

The thread continues with many other ideas including new http headers, progressive image formats, and general media formats with queries.

BTW, Adaptive Images has been added as a placeholder on the HTML.next list.

Discussing Alternatives For Various Sizes Of The Same Image & Introducing src Property In CSS As An Option by Robert Nyman

Robert asks the question, “whether various sizes of the same image is really content or presentation?” If it is presentation, then it should be in CSS. Again, great discussion in the comments.

Responsive images using CSS3 by Nicolas Gallagher

“This method relies on the use of @media queries, CSS3 generated content, and the CSS3 extension to the attr() function.” This means it relies on already existing standards without creating anything new. Unfortunately, it doesn’t prevent multiple images from being downloaded and currently only Opera supports the CSS3 content property. That said, if we could get browser makers to change download behavior, this could work with existing standards.

My take on adaptive images, Responsive images – hacks won’t cut it, and Simpler responsive images proposal by Yoav Weiss

No one has been blogging more about the need for a better solution than Yoav. His proposals have changed over time. The simpler responsive images proposal is his latest version, but they are all worth reading to see his thoughts and the feedback on each post.

add html-attribute for “responsive images” on WhatWG mailing list

Anselm Hannemann started a recent thread on the WhatWG mailing list proposing using media- and inline media queries to provide different images. One of the things notable about this thread is that there are some on the list who don’t think the current situation is a problem or if it is a problem, that it is a niché use case. We have some education to do.

Comments on Responsive IMGs Part 1 and Part 2

It seems weird to link to my own posts, but the comments on each post contain some good suggestion. Scott Jehl said, “It’s unfortunate the comment streams of these images posts are separated. Good stuff going on in both.” I agree. Best I can do is link them up with this post.

What are our goals for a replacement for the IMG tag?

As I read through the conversations about the potential replacements or extensions for the IMG tag, I’m struck by the fact that people seem to all see the same problem, but haven’t yet come up with common criteria that could be used to evaluate different potential solutions. Until that exists, we won’t have consensus.

For example, I would love to have the browser send more data via HTTP headers that would allow us to make determinations on the server about what size image to send. But I don’t think that will work as a replacement for the IMG tag because we need something that will work for HTML widgets where the server isn’t part of the picture.

(Psst… but seriously browser makers, more headers would be great!)

So what should be our criteria. Here is start from my perspective:

• It should be an HTML element and not solely CSS because IMGs are often part of the content. IMGs are semantic.
• The solution should work without server content negotiation so that it can be used for HTML widgets. This doesn’t preclude servers being part of the solution, but we need a solution that will work if servers aren’t in the mix.
• Current caching and proxy strategies cannot be ignored. Because of this, different image sizes likely need to be at unique URLs or the wrong size image for a given user will end up cached at the edge of the network.
• It should support arbitrary image sizes and pixel density.
• It should support art direction decisions to change the image at different sizes.
• It should be a framework that will allow for future expansion based on factors beyond screen size. For example, if the browser provides information about the speed of the network connection, the designer or developer should be able to decide on the most appropriate image. We don’t have to define this now, but we shouldn’t box ourselves in to only looking at screens size.

That’s my start on criteria. What did I get wrong? What would you add? And of the various IMG tag replacements that have been suggested, which do you think holds the most promise?