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:
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.
video tag, which is designed to replace Flash video (mostly). Let’s say you have a report that has some filter controls on top that let you narrow the scope of the report. When the report loads, the filter is collapsed. The user opens the filter, changes some of the settings, and submits the form. What is the preferred method for determining whether the filter should be displayed? A related question is whether you should detect the filter’s visibility status in JavaScript or you should check on the server side and use the style attribute to control visibility.
Here are some options:
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?
© rc3.org. Powered by WordPress using the DePo Skinny Theme.