Tim Bray offers a good high level explanation of why hash-bang links are a horrible idea and fundamentally break the web. I like this question:
So, my question is: what is the next great Web app that nobody’s built yet that depends on the simple link-identifies-a-resource paradigm, but that now we won’t be seeing?
That probably explains the Twitter case, since Twitter is an application that rightly has many dynamic elements. But that doesn’t make sense for Gawker, a Web publisher in the business of publishing static blog posts on the Web. Why are they loading that content dynamically? My best guess there is that they hired a developer or manager who had done it that way somewhere else, probably for more sensible reasons. They came to Gawker and decided to just build things in the way that they already understood. That person should probably be fired.
Tim O’Reilly offers a definition of the Internet operating system:
This is the crux of my argument about the internet operating system. We are once again approaching the point at which the Faustian bargain will be made: simply use our facilities, and the complexity will go away. And much as happened during the 1980s, there is more than one company making that promise. We’re entering a modern version of “the Great Game”, the rivalry to control the narrow passes to the promised future of computing. (John Battelle calls them “points of control”.) This rivalry is seen most acutely in mobile applications that rely on internet services as back-ends.
This is a great and important article, an explanation of where we are right now as an industry.
The two questions that I’m interested in trying to answer, or seeing other people try to answer, are:
- What are the keys to preserving the freedom and openness of the Internet given the trends in the article?
- How should people developing applications using the Internet operating system be investing their time right now?
Dojo developer Alex Russell continues to look out for view source:
If HTML is just another bytecode container and rendering runtime, we’ll have lost part of what made the web special, and I’m afraid HTML will lose to other formats by willingly giving up its differentiators and playing on their turf. Who knows, it might turn out well, but it’s not a vision of the web that holds my interest.
I linked to his previous warning on this subject back in January.
The theory is that if all the User-Agent providers implement all these algorithms exactly as specified, complete interoperability will be achieved and people who build Web applications need no longer concern themselves with the differences between User Agents. Which would of course be wonderful.
Will it work? Nobody knows; it’s a science experiment. Just because nobody has ever succeeded in specifying a workable networked object model doesn’t mean this project will likewise fail. But it does mean that when considering the future of HTML5, we should recognize that this is a very hard problem, and there’s no guarantee that that part of it will come off.
From a blog post on HTML5 by Tim Bray.
Form expert Luke Wroblewski compares Apple’s revamped checkout process to their old checkout process. If you do any work designing HTML forms at all, you’ll want to check this case study out. I’m particularly interested in the pros and cons of requiring users to enter their city, state, and zip versus entering just the zip and looking up the city and state. Luke has looked at this issue before.
I hinted at this in my link post, but I thought I’d write up the whole thing in hopes of discussing it. I have a page that will include a Google Map with markers for a number of locations (potentially a large number of markers). For an explanation of how to add markers to a Google Map, check out this page.
So the question is: how do you get the address data from my database to Google Maps?
The process is to geocode the address and then apply the marker to the map. There’s a simple example at that link.
Here are some possible approaches:
I’ve done some searching to find out how people handle this problem, but haven’t seen any good answers yet. Any ideas?
This is a special link roundup related to the W3C killing off XHTML 2 and putting all its eggs in the HTML 5 basket. I’ve posted about this myself here.
style attribute to control visibility.
Here are some options:
- Always leave the filter collapsed initially. I hate this option, though, because it hides important information from the user. If the report is in some non-default state, the user should be able see when it loads what that state is.
- Check to see whether any form parameters were submitted. If there were, add the appropriate
style attribute to the form on the server side.
There are probably other options as well, and all of them will work. Choosing from among them is a matter of ease of maintenance, mostly. Ideas?