Archive for the ‘Web Basics’ Category

File Under: Mobile, Web Basics

Bandwidth and the Mobile Web Browser

Your website’s view of the tubes. Photo: Stig Nygaard /Flickr

High-resolution screens on mobile devices present web developers with an interesting conundrum — the screens are capable of displaying very high-res images, but on a mobile device bandwidth may be limited. What’s a web developer to do?

The answer, for now, is that there is no good answer; be it bandwidth or image quality you’re going to have to compromise somewhere.

That’s why mobile expert Peter-Paul Koch thinks browsers need to start broadcasting the connection speed of the device. “Browsers, especially mobile ones, should give information about the speed of the connection they’re on,” writes Koch in a recent blog post exploring just what that might look like and how web developers might use that information.

Here’s what Koch thinks developers need:

  1. We need an HTTP header, so that a server-side script can use the information to decide whether to send the lowsource or high-res images. Let’s call it X-Connection-Speed for now.
  2. A JavaScript property, say navigator.connectionSpeed, also makes sense.
  3. Chris Coyier proposed a bandwidth media query with matching min-bandwidth and max-bandwidth. Sure, why not?

Check out Koch’s post for full details on other aspects like units, how connections speed might be calculated and what to do with edge cases — like when the connection speed changes between read and page load (Koch’s scenario imagines a user on a phone in a train with a good connection that deteriorates when the train enters a tunnel).

Koch’s post isn’t a proposal; rather its an exploration of the idea and he’s looking for feedback. There are already some great comments from other developers, including several that question whether web developers should be allowed to decide how much bandwidth a site uses.

While developers might like to be able to control bandwidth and deliver the images they’d like to be seen, that just might be a decision best left to users. For example, I may have a great 4G connection, but my data plan might be a mere gigabyte a month and I may not want to waste it on your high-res images. As David Ellenwood points out in the comments, a YouTube-style approach, choosing a sensible default and then offering up links to higher-res content (e.g., the 480, 720, 1080 options on most YouTube videos) might be the more user-friendly approach.

For now not only do browsers not broadcast connection speed, most don’t even have access to that information at the device level. But there are already proposals to add some sort of bandwidth info to HTTP (like the HTTP Client Hints proposal from Google’s Ilya Grigorik or Mozilla’s proposed Network Information API) and it seems likely that something along these lines will be added before too long. Be sure to read through Koch’s post for some more background and details. If you’ve got ideas, leave a comment on his site.

File Under: search, Web Basics

Pull Your Site Out of the PageRank Gutter With Google’s ‘Disavow Links’

If your site has ever been, as Google’s Jonathan Simon charitably puts it on the Google Webmaster Tools blog, “caught up” in linkspam, Google has a new tool you can use to disavow those inbound links and clear your site’s name.

Google cautions that its new Disavow Links tool should be thought of as a last resort. It’s far better to get any spammy links actually removed from the web. In fact “the vast, vast majority of sites do not need to use this tool in any way,” writes Simon. But for situations where you can’t make the offending links go away — for example, with a client who might have made some bad SEO decisions in the past — Disavow Links offers a solution.

It’s worth noting though that Simon says that any links you disavow will be seen as “a strong suggestion rather than a directive — Google reserves the right to trust our own judgment for corner cases.”

Inbound links are perhaps the best known thing that Google uses to calculate PageRank and order search results. While PageRank is just one of more than 200 “signals” Google looks at to determine where your site will be in search results there’s no question that better inbound links mean your pages end up higher in search results.

There’s a flip side to inbound links though. If the wrong sort of sites point at your site it hurts your PageRank. If you’ve got inbound links from known paid link or other shady link-swapping schemes that violate Google’s guidelines, you can quickly find your site has disappeared from Google’s search index.

For more info on how the Disavow Links tool works, check out the video below from Google’s Matt Cutts. Also be sure to read through the FAQ over on the Google Webmaster Tools blog.

File Under: Web Basics

W3C Helps You Build a Better Web With ‘Web Platform Docs’

The W3C, the group that oversees the development of HTML and other web standards, is moving beyond dry, boring specifications with a new venture into developer documentation. The W3C has just launched an alpha preview of Web Platform Docs, a community-driven site the W3C is hoping will become the go-to source for learning how to build the web.

In other words the W3C is competing with Webmonkey.

We’re okay with that because there’s no such thing as too much high-quality, accurate info on the latest in HTML5, CSS 3 and other W3C standards. And quite frankly, HTML and CSS have grown considerably since the days when Webmonkey’s cheat sheets could tell you everything you needed to know.

Now there’s a plethora of resources for learning how to build the web — the Mozilla Developer Network, the Opera Developer Network and Microsoft’s developer site, to say nothing of the thousands of tutorials on developer blogs. But while there’s plenty out there to teach you what you need to know, finding exactly what you need to know can be challenging. You’re a web developer; you should spend your time building a better web, not searching Google for accurate info on web standards.

The goal of the W3C’s Web Platform Docs is twofold: get tons of great documentation all under one roof, and then — the most challenging part — make sure that it stays up to date. Solving the second problem is no small task. The web is currently littered with great tutorials on CSS Flexbox, which are, unfortunately, all wrong now that the Flexbox spec has been changed. The same is true of Web Sockets tutorials, Indexdb tutorials and any other tutorial on a spec that has changed or might change in the future.

These days keeping up with the rapidly changing world of web standards is a full-time job and who better to tell you what’s going on, how you can use new tools and when browsers will support them than the people actually writing standards and building browsers?

The W3C has managed to bring together some of the biggest names on the web to help create Web Platform Docs. Representatives from Opera, Adobe, Facebook, Google, Microsoft, Mozilla and Nokia will all be lending their expertise to the new site.

While the list of participating companies is impressive, Web Platform Docs is also a wiki that anyone, not just W3C reps, can edit. As the W3C’s Douglas Schepers tells Webmonkey, “anyone can contribute and everyone is on equal footing.”

If your head is bursting with tutorials, code snippets, examples or solutions to common development problems, head on over to the site and sign up so you can contribute. Bear in mind that this is an alpha release. While the site looks great and has the basic features of a wiki up and running, many of the features Schepers mentions in the intro blog post aren’t available just yet. “In the spirit of ‘release early, release often’, we decided to announce the site at the earliest possible point and improve it in public,” writes Schepers.

Right now the content of the site is primarily documentation, but the plan is to include tips and best practices along with up-to-date information on standardization progress and browser support for individual features. Other cool planned features include a way to share code snippets and an API for some aspects of the site.

For an overview of the site and to learn a bit more about where the W3C plans to go with Web Platform Docs, check out the video below.

File Under: APIs, JavaScript, Web Basics

RSS in JSON, for Real?

Photo: Kevin Conboy/Flickr

A short while ago Twitter said they were going to move to JSON over XML, without much explanation other than they like JSON and not XML so much these days, etc. I’m a big believer that everyone has the right to support whatever they want when they want for whatever reason, whether they say the truth or not. Because of that belief, I take with a grain of salt every bit of support for every format and protocol. I assume that just because someone supports it today doesn’t tell you for sure that they will support it tomorrow. Though the penalty is usually pretty high for removing support for interfaces people depend on. They tend to remember it next time you ask for their trust. All that is fair game too.

So anyway, this got me thinking again about the possibility that JSON might take over from XML. What then? Should we give up all the interop we get from RSS just because it uses XML and not JSON? And it’s because of all that interop that that day will never come. A transition may happen over a long period of time, and before it’s complete there will be something after JSON. Because smart people see that, they tend to be conservative about switching just for the sake of switching. It’s why the web, which is entirely an XML application, will keep XML support everywhere for the forseeable future.

In other words, I’d bet with virtual 100 percent certainty that it’s safe to keep producing XML-based RSS feeds.

But people like JSON, there’s no denying that. And a JSONified RSS can totally co-exist with the original XML. So let’s have RSS in JSON? That’s a question that seems worth asking about, at this time.

Turns out it is a very straightforward thing to do. I of course have an RSS feed for Scripting News, the blog you’re reading right now. I wrote a script that maintains JSON and JSONP versions of the same content, automatically. When the RSS is built so are the JSON formats. and

I learned a long time ago to embrace change. It’s why there is a RSS today that is derived from the RSS that Netscape shipped in 1999 and has features of my scriptingNews format shipped in 1997. If the world wants to go to JSON, help it get there in a way that benefits from all we learned in the evolution of RSS from 1997 through 2002. It’s stood up pretty well over the years. And there’s wide support for it, and lots of understanding of how it works. If there is to be a JSON-based syndication standard, we can cut years off the development process by simply accommodating it.

So I put together an invitation to discuss this.

If you find this interesting, give it some thought, and if you have something to say, write a blog post of your own, or write a comment on that page. Obviously there’s no moderation for what goes on your blog, but there will be moderation of the comments. Be aware of that. One feature of the past are personal attacks which are totally pointless and subtract from the discourse, and we should not carry that practice forward. That’s why the moderation. :-)

Otherwise, I totally look forward to hearing what people think.


This post first appeared on Scripting News.

Dave Winer, a former researcher at NYU and Harvard, pioneered the development of weblogs, syndication (RSS), podcasting, outlining, and web content management software. A former contributing editor at Wired magazine, Dave won the Wired Tech Renegade award in 2001.
Follow @davewiner on Twitter.
File Under: HTML5, Web Basics

Popular ‘HTML5 Boilerplate’ Hits 4.0

HTML5 Boilerplate, easy to bolt on. Image: Les Chatfield/Flickr

The developers behind HTML5 Boilerplate have released version 4 of their boilerplate HTML, CSS and JavaScript templates for quickly prototyping HTML5 designs.

You can grab a copy of HTML5 Boilerplate v4.0 from the HTML5 Boilerplate website.

This release is notable for a number of changes including a snazzy new website, cleaned up and reorganized code and the beginnings of a high-resolution-screen @media query. This release is also notable for what it lacks, namely the trademark pink text highlight color which has been ditched in favor of a more neutral blue.

Version 4 of Boilerplate also updates the various code libraries that Boilerplate relies on, including jQuery, Modernizer and the very awesome Normalize.css.

You can see the complete changelog for this version over on Github and get any help you might need with HTML5 Boilerplate at Stack Overflow.