The iPhone and iPod touch made Mobile Safari the most popular mobile browser in the United States. Although Mobile Safari is more than adequate at rendering normal Web pages, many Web developers created versions of applications aimed at the iPhone. Here in Part 2 of this "Developing iPhone applications using Ruby on Rails and Eclipse" series, we learn the common use of drill-down lists as a navigation method

I have an oldish ThinkPad (a T42p) lying around that I decided to use as an Ubuntu playground on for a while. I learned a lot playing with it, but now I do most of my Ubuntu-based work in a VM running on my fancy multi-core desktop, and Mandy could use a little portable Diablo II game machine, so today I went to reinstall XP.

After sticking the install disc in, I see the familiar "Setup is inspecting your hardware…" prompt and then… nothing. Just a black screen. Hard drive light is stuck on, the CD eventually spins down and nothing happens. /me scratches head.

After a bit of searching around, it turns out that the Windows XP setup program really doesn’t like it if you have odd partitions on the hard drive, where in this case, odd is defined as the default partition layout as set up by Ubuntu.

So, after a quick download of GParted and a wipe of the hard drive, the install is now cruising along, merry as can be.

Update: Thanks to Will for pointing out a Microsoft Knowledge Base article on exactly this subject.

I’m incredibly excited about the SitePen Dojo Toolbox AIR app that just launched. I’ve been using early versions for a couple of weeks now, and in that time it has earned a privileged place on my desktop. Being able to make local builds without delving to the command line is something that I’ve wanted to be able to show new Dojo users for years and this tool finally makes it easy. There’s more work to do around configuring the profiles themselves, but the new tool demystifies many of the build configuration options significantly. Having a searchable API viewer available is also a godsend. Huge props to the team that put it together!

Edit: I forgot to note one of my favorite parts of the project, namely that because the Dojo build system is written in JavaScript (thanks to James Burke’s awesome work), the build system in the Toolbox doesn’t require Java. Instead, SitePen was able to port the few Rhino dependencies in the build tool to work with the native JavaScript engine in AIR. It’s a minor thing, but it speaks to the excellent engineering behind Dojo’s tooling and the power of having actual web-native technologies inside a desktop app.

You've seen reader comments on weblogs and other Web 2.0 sites, but the Atom protocol makes it possible to create and manage such comments in a very flexible way. Flexible Web annotations is an idea that will open up an entirely new class of Web applications with very little actual new invention. Learn how to create a system to manage annotations for anything on the Web, from nearly anywhere.

Ajax techniques have changed the face of large, commercial Web applications, but many smaller Web sites don't have the resources to rebuild their entire user interface overnight. New features should justify their costs by solving real-world interface problems and improving user experience. This series is teaching you to modernize your user interface incrementally using open source, client-side libraries. In this installment, you learn to turn slow, messy, annoying product-details pages into fast, elegant ones using DHTML and Ajax. You do so using the principle of progressive enhancement, ensuring that your site remains accessible to all sorts of user-agents.

Google Calendar allows Web application developers to access user-generated content and event information through its REST-based Developer API. PHP's SimpleXML extension and Zend's GData Library are ideal for processing the XML feeds generated by this API and using them to build customized PHP applications. This article introduces the Google Calendar Data API, demonstrates how you can use it to browse user-generated calendars; add and update calendar events; and perform keyword searches.

In this issue…

• Official Guinness World Record!
• Firefox 2.0.0.15 released
• Mozilla security metrics project
• Weave 0.2 development milestone
• Two new members of the about:* newsletter family
• Help test-drive the new Mozilla Developer Center!
• Next generation JavaScripting
• Developer calendar
• Subscribe to the email newsletter

Official Guinness World Record!

The Firefox community is the proud holder of a new Guinness World Record. On July 2nd, Mozilla received confirmation from Guinness that we’ve officially achieved the record for the “largest number of software downloads in 24 hours,” with a final total of 8,002,530 downloads. This is another in a long line of wonderful accomplishments for our community. Ever since Firefox was launched in 2004 we’ve relied on Firefox supporters to help spread the word, and we now have over 180 million users in more than 230 countries. It’s an amazing accomplishment, and we’re all extremely grateful. Don’t forget to get your very own personalized Download Day certificate!

Firefox 2.0.0.15 released

As part of Mozilla Corporation’s ongoing stability and security update process, Firefox 2.0.0.15 is now available for Windows, Mac, and Linux. Please note that Firefox 2.0.0.x will be maintained with security and stability updates until mid-December 2008. We encourage you to upgrade to Firefox 3, which is now available at GetFirefox.com. For more information, please see the DevNews blog post.

Mozilla security metrics project

Mozilla has been working with security researcher and analyst Rich Mogull on developing a metrics model to measure the relative security of Firefox over time. The team is trying to develop a model that goes beyond simple bug counts and more accurately reflects both the effectiveness of secure development efforts and the relative risk to users over time. The goal for the first phase of the project is to build a baseline model that can evolve over time. A preliminary version of the project goals and a spreadsheet of the model have been published by the team. These, along with more information about the project, are available through the Mozilla Security blog.

Weave 0.2 development milestone

Weave is a Mozilla Labs project focused on building online services into the browser. The project’s goals are to enhance the new Firefox user experience and increase your control over how you share your personal information between computers, and with other people. Version 0.2 is a major update to the Weave client and to the servers than control it, and has significant new features. For more information, including details about the changes, or to try it out for yourself, check out the Mozilla Labs’ weblog post.

Two new members of the about:* newsletter family

Mozilla has started two new newsletters: about:addons and about:mobile. Strictly dealing with add-on related news and development information, about:addons is targeted at our increasingly large and vibrant addon development community. The more recent addition, about:mobile, is all about Mozilla’s nascent mobile project. Both newsletters plan to publish on a monthly basis, and both are available by email, web, and RSS feed. For more information, including how to sign up, see Mark Finkle’s blog post for about:addons, and Chris Blizzard’s blog post for about:mobile.

Help test-drive the new Mozilla Developer Center!

Eric Shepherd, Mozilla’s Developer Documentation lead and MDC project coordinator, is looking for help testing the new Mozilla Developer Center system and design. Before diving in to help out, it’s important to note that changes made on the test server will not be ported back into the real database. The test version of the site is available at http://devmo.dekiwiki.mozilla.org. For further information and up-to-date details about the state of the server and testing, see Eric’s weblog.

Next generation JavaScripting

Mozilla Labs’ Aza Raskin has posted about “next generation JavaScripting” over on the Labs’ weblog. In it he points to three very interesting recent JavaScript-related projects by folks in the Mozilla community: John Resig’s Processing.js, a port of the Java-based Processing programming language; Atul Varma’s Parchment project, which is a JavaScript-based interpreter for the Z-Machine; and Aza’s own ContextFree.js, a project focused on drawing striking images and making art with minimal amounts of code. Check out the full blog post for more details.

Developer calendar

Monday

• Mobile Meeting
• SUMO Meeting
• General Status Meeting

Tuesday

• Thunderbird Meeting
• Firefox/Gecko Meeting
• Bug Day!

Wednesday

• Mac Gecko Meeting
• Performance Infrastructure Meeting
• Performance/Leaks Meeting
• Platform Meeting
• Crash Reporter + Analysis Meeting
• Weave Meeting
• Calendar Meeting

Thursday

• Thunderbird Bugday

Friday

• Test Day! (now biweekly)

Subscribe to the email newsletter
If you would like to get this newsletter by email, just head on over to the about:mozilla newsletter subscription form. Fresh news, every Tuesday, right to your inbox.

In the middle of May, we were given a mission: create a speedy, offline API documentation viewer and a graphical Dojo build tool. Here we are at the beginning of July, and the result is the Dojo Toolbox 1.0. This article is a first look at this new application.

Adobe® AIR™ has received a good deal of press attention over the past few months, and with good reason. It provides a way for web application developers to use the skills they already have to create cross-platform desktop applications. Starting with Dojo 1.1, Dojo has included support for AIR out-of-the-box. This made AIR an ideal target environment for the Dojo Toolbox.

The easiest way to get the Dojo Toolbox is from SitePen’s Dojo Toolbox page. There’s a widget on that page that can download the Adobe AIR runtime and the Dojo Toolbox quickly, and with a minimum of effort.

Installation of an AIR application is a breeze. When you double click the DojoToolbox.air file, you will see a security verification window like the one below:

Unlike a web application, AIR apps are able to access the files on your computer and have unrestricted access to the internet. For that reason, AIR applications are digitally signed so that you can decide if you trust the application’s publisher with this extra level of access.

We have signed the Dojo Toolbox with a certificate assigned to the Dojo Foundation by Thawte. So, installation of the Dojo Toolbox reflects that the publisher’s identity has been verified. The Dojo Toolbox requires access to your local file system, in order to be able to run builds, and to the internet in order to check for updates and to download the API documentation.

After you accept the security aspects of the installation, AIR asks you where you would like to place the newly installed app, presenting a default that is appropriate for your platform.

One thing you might already have noticed about AIR: its appearance is not the same as a native application. Though AIR apps have many of the capabilities of a native application, the way they are rendered is very much the same as a web application. If you imagine the incredible variety of appearances in web applications, you can imagine the diversity we’re likely to see in AIR applications.

The install process is easy, but updates are even easier. The Dojo Toolbox can check for updates for you and download and install an update with just a couple of clicks.

Unless you unchecked the checkbox on the installer screen, the Dojo Toolbox will launch as soon as it’s ready.

The Screencast

If you’d like to see, rather than read about, the Dojo Toolbox you can either install it for yourself, or take 5 minutes and watch the screencast:

The Dojo Toolbox Application

When you launch the Dojo Toolbox, you’re greeted with a small “launcher” window:

You’ll notice right away that it’s not a native-looking window. That’s another nice feature of AIR: you can create “chromeless” windows that have their own distinctive look and feel.

The Dojo Toolbox is designed to be unobtrusive, so you can leave it sitting around and reach for it whenever you need it. You can drag the launcher around your desktop, and it will remember its position for the next time you launch it.

If you click on the Dojo logo, the launcher will expand so you can access the available tools. Currently, there are three: the API Viewer, Builder and Resources.

Let’s take a closer look at them in the order in which they’re presented.

API Viewer

The first time you launch the API Viewer, it will download the Dojo API documentation zip file and then uncompress it. This file is a version of api.dojotoolkit.org that has been reformatted specifically for the Dojo Toolbox.

When the API Viewer is ready, you’ll get a view of the Dojo API documentation that is similar to the one on the web.

The navigation on the left allows you to easily find a module within the Dijit, Dojo and DojoX packages. Not surprisingly, choosing a module on the left will give you the docs for that module on the right. At the top of the window, there are left and right arrow buttons. Those are like the back and forward buttons in your browser.

One feature that you’re likely to use all the time is the search box at the top. Type in the name of a Dojo function (for example dojo.forEach) or the words that you’re looking for and you’ll get a list of matching help topics.

All of the topics that match any of the terms you enter will be displayed, sorted with a simple scoring mechanism. You can also search for topics that do not include a particular word by putting a “-” before the word.

The API Viewer gives you amazingly fast access to the wealth of information available in the Dojo API documentation. Even on an airplane!

Introducing the Builder

The Builder tool is the most complex tool in the current Dojo Toolbox. It has many options spread out over three tabs.

You can productively use the Builder without touching most of those options. The goal with the Builder is to provide an easier way to take advantage of the power of Dojo’s build system, which was previously available only as a command-line tool.

Dojo’s build system can dramatically reduce page load time by cutting the number of requests that the browser needs to make and reducing how much data is sent on each of those requests. Internet Explorer has a default limit of just two simultaneous requests, which means that reducing the number of requests required can have a huge impact on page load time.

To use the Builder, there are just two things you need to provide it: the top directory of the copy of Dojo of which you wish to make a build, and the location of a profile file. Assuming that you already have a copy of Dojo that you have downloaded previously, you can click the “Select Directory…” button to choose the directory containing your Dojo. The Builder will remember that choice so that you can select it next time.

Next, you need a profile file. The profile describes how JavaScript modules will be collapsed into separate JavaScript files. You can learn more about creating profiles from the online Dojo Book. Once you have a profile available, you can click the “Select File…” button to select that profile for building. As with your Dojo directory, the Builder will remember which profile was last used for building, so that you can easily grab it again.

And that’s all you absolutely have to choose before you can run a build. Click the “Build It!” button, and you’re off to the races.

While the build is running, you will see a progress meter with a short description of what is happening. In addition, you get a log window that displays the log output of the build. That is the same log output you get when running the Java build.

The amount of time it takes to run a build in the Dojo Toolbox is comparable to how long is spent on a build using the traditional Java-based build tool.

Speaking of the Java-based build tool, the mysterious-sounding “Command” button will give you the command line options to use with the Java build tool.

That means you can use the Builder as a graphical front end to the command line build tool, making it easy to run automated builds.

Build Options

Dojo’s build system can handle sophisticated needs. With so many options available, it can be difficult to know what each one is all about.

Luckily, help is built in to the Builder tool. You’ll notice that many of the field names are underlined. If you click those underlined headings, you’ll see a Tooltip that describes what that setting is for.

The text for these Tooltips is from the command line build tool help, so these will always stay in sync.

I want to mention a very important option: the ShrinkSafe option. ShrinkSafe is Dojo’s tool that compresses JavaScript files by eliminating excess whitespace and removing comments. ShrinkSafe is “safe”, unlike some other JavaScript compression tools, because it works off of the syntax tree produced by a customized version of Rhino, the JavaScript engine written in Java. Rhino is not available within the AIR environment.

As of this writing, the only ShrinkSafe optimization choice available is “none”. We left the option on the page, however, because we are actively working on providing two options for using ShrinkSafe with the AIR-based build. The first is “Remote ShrinkSafe”, which will use the ShrinkSafe web service to compress the files. We also recognize that many people might not want their custom JavaScript files being passed across the Internet. For this reason, we are also working on a “Local ShrinkSafe” option which will use a small Java-based service running on your computer for the compression.

The Resources Tool

The third tool in the Dojo Toolbox is called, simply, “Resources”.

Resources provides you with a consolidated, quick click-and-go list of some amazingly useful sources of knowledge and help for working with Dojo. We’ll be keeping this resource list up-to-date as new articles are published and new tools are created.

After 1.0

We’re very excited to be offering this new, simple way to help you get more out of Dojo. And 1.0 is really just the beginning. We have tons of ideas for new tools and features for the Dojo Toolbox, and I’m sure you do, too.

Download the Dojo Toolbox today to take advantage of the great features today. Then, join us on the Dojo Toolbox mailing list and tell us how we can make this open source application even better.

Adobe, the Adobe logo and Adobe AIR are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries.

Today SitePen, Inc. announced the release of a co-sponsored "demo" utilizing Adobe's AIR runtime and The Dojo Toolkit affectionately named "The Dojo Toolbox". Don't let the term "demo" fool you though, this thing is a fully functioning application providing a pluggable API built around the question "what can be done offline to better Dojo?" ... As you probably know, AIR provides a plethora of functionality not present in standard browser applications, and Dojo is the perfect toolkit to fully take advantage of the potential. From offline storage to native window interaction (which seems to fall perfectly in line with the idea of templated widgets, especially in "chromeless" mode) to the remote update capabilities of AIR, realizing powerful desktop-based cross-platform applications has never been easier. I can't begin to confess how excited I am about being to use the stuff I know (html/css/js/Dojo) in the realm of Desktop application, so I won't even try.

Enough jabbering ... on to the good stuff! You can skip my wordiness and view the screencast Kevin Dangoor made up, or read along with the quick-and-dirty rundown from the SitePen press release:

Offline API documentation

The entire Dojo API Documentation has been taken offline and converted into a searchable index. Every piece of the public (and private) API in Dojo is now available on your desktop for browsing. Doc updates come out? No problem,
the application can be remotely updated anytime a new version of Dojo is released.

Build utility

The power of the Dojo build system has been ported to AIR. You can target an existing build profile, define common options, and build your dojo.js and layers all from a simple UI. Upcoming (planned) features include: ShrinkSafe web service (you can't run Java from within AIR, so no ShrinkSafe is available just yet) to compress your code, as well as a custom Profile maker.

Quick Resources

Many vital resources are found in this simple Toolbox plugin giving you handy access to the most current and most important resources available for Dojo. One oversight in the 1.0 release the absence of a link to DojoCampus, though the automatic updating nature of the application means it will likely appear shortly.

Looking Forward

The application was released under a BSD license and is fully open source. SitePen has setup a dedicated mailing list to discuss any issues or enhancements about the Toolbox, so signup and throw some ideas out. What kind of cool mini tools can you imagine floating around on AIR to make your web-dev experience easier? I'm thinking of a set of pixel calculators/rulers to overlay and inspect layout nitpicking ... The potential is endless.

Thanks be to Adobe and SitePen for their support of Dojo and Open Source Software. I can't wait until other tool ideas start popping up ...

MUTO is animation using graffiti techniques from Italian artist Blu shot on location in Buenos Aires. Think of it as stop motion animation but using public spaces as your canvas. The scale and length of the video is breath taking. I’m probably missing the point, but the whole logistics of how you pull something like this off is what amazes me. Did they do it over a period of months, or all in a couple of days, was there a plan ahead of time or did they just wing it as they went along. It really is fascinating to watch.

MUTO a wall-painted animation by BLU from blu on Vimeo.

I’ve been spending the last few nights reading Michael Ruhlman’s The Making of a Chef. I’ve enjoyed it immensely; I’d always wondered what it was like inside that campus after driving past it so many times in our weekend adventures northward from Tarrytown. Mandy and I never got the chance to eat at any of their restaurants while we lived downstate, but now we’re hopefully planning a trip south to sample the cuisine. Ruhlman is a pleasure to read and does a fantastic job conveying the passion and pressure of going through the Culinary’s course load. If you’re into cooking at all or want to know more about what it’s like to be inside the Culinary Institute of America (our other CIA), I heartily recommend the book.

Last night, as I was nearing the end of the book, I came across a scene that I’ve been replaying in my head all day. When you’re cooking in a professional kitchen, things move very fast and you have to come into it prepared and once there you have to be incredibly efficient to stay on top of all the orders coming in. When you get behind or overwhelmed, it’s called being “in the weeds.” While working at American Bounty, the premier restaurant at the Culinary and the last stop for the students before graduation, Ruhlman is working the grill station and another student is lost in the weeds. He’s getting behind and his station is getting messier and messier, enough so that the head chef asks him repeatedly to clean up his station. After a few such reminders, the instructor finally stops the student and tells him how he likes to get out of the weeds.

He takes a moment. He wipes down his station, getting it perfectly clean. He arranges everything he needs back into order, and this little restoration of order helps him clean up his mind as well. When you’re in the weeds, it’s as much a mental problem as it is a physical one. To perform quickly and efficiently, you have to be focused. The mess clouds your focus and that lack of clarity shows up in the final result.

This reminded me a lot of programming under a tight deadline. In the rush to get everything done and out the door, you tend to get messy. You don’t write tests, you don’t verify that code changes work in all the browsers, you check code in without actually compiling it first, and eventually the whole thing disintegrates. In your effort to go faster, you get sloppy and you end up slowing down.

So, a reminder to myself. When things get hairy, take a moment and clean everything up. You’ll probably get done sooner as a result.

Since my last update, I've made the demo page more verbose and created a "shear" effect that, once again, splits the element into rows and/or columns and slides them in alternating directions, with an optional progressive or random delay between each piece's animation.

I also added a parameter (args.unhide) that returns the opposite animation, which is not necessarily the exact reverse. For example, the opposite of the disintegrate effect is the build effect, in which pieces fall from the top into place rather than down from their initial positions.

Since the fold effect was acting strangely, and because its concept was so trivial, I scrapped it. It was supposed to be a simple chain of two wipes, one vertical and the other horizontal. Users should be able to figure this one out on their own.

I'm planning more advanced effects, involving non-linear sliding. I also plan to perfect a simple _Animation.reverse() that either simply reverses the animation's curve or handles pausing, reversing, and playing an animation in progress. My mentor and I have already discussed a simple prototype that might work.

Chris in the office came across an interesting change that’s been made in Firefox 3 that I have to say although it’s probably going to be a nightmare for many users it’s a great thing and will only lead to a “better internet”.

Now if you go to a page online that has “suspicious” SSL certificates you are no longer exposed to a simple and easy to bypass popup window, you now get a full page warning that hopefully shows the user they are doing something above and beyond to bypass.

I found one of the devs on Mozilla had an awesome blog post about the original bug. Included in it was this priceless screen shot showing the old popup and what most people probably read, it’s so true.

I like the new warning. It’s getting more inline with how IE7 handles the same situation.

Hopefully it will make people who use bad SSL setups update their processes so they don’t get affected by this, that is only a good thing for end users.

My contribution to the meme:

blowery@hermes:~$ history 1000 | awk '{a[$2]++}END{for(i in a){print a[i] ” ” i}}’ | sort -rn | head
170 cd
78 ls
55 sudo
31 svn
18 scons
18 nm
12 less
9 grep
8 rm
8 make

As for why these, here are some rough guesses:

cd

obviously we use a lot of directories and I end up moving around quite a bit.

ls

implicitly tied to cd usage I think. And I have a lousy memory for what file names in what dirs.

sudo

This meme caught me while I was setting up a new working vm instance, hence all the sudo. Normally, I don’t think I use it quite so much.

svn

svn is our source control management tool of choice

scons

scons is our build tool of choice

nm

nm lists the exported symbols in a library. I was tracking down a problem with MySQL and a broken exported symbol during the aforementioned instance install.

less

less is my pager of choice

grep

handy for finding things

rm

handy for removing things. I think this was related to MySQL causing me grief

make

everyone else’s built tool of choice and I was installing a lot of everyone else’s stuff

Firefox 3

Point your browsers over to getfirefox.com and download the best version of the best cross-platform browser yet. I’ve been using the alphas and betas and release candidates for a while and I think this will be a great release. Between the performance and typographic rendering improvements, I just can’t stand using Firefox2 any more.

If you’re seeing this in a feed reader, come on by the site and check out the new look. I went for a simple, easy to maintain look with minimal graphics for a fairly speedy page load. I also pulled out a few things that were slowing down the site: a plugin that was inadvertently pulling in the YUI library, some supposedly fancy Amazon script that showed previews of products when you hovered over their links, and biggest of all, Google’s Adsense. I’m still pulling in Google Analytics, but it’s the last thing on the page and shouldn’t affect load times too much. I wanted something simple and clean and easy to read, and I think I’ve got that.

I also spent a fair bit of time trying to get the typography right. Fancy, no?. I really enjoy The Elements of Typographic Style Applied to the Web and I wanted to try my hand at working within their framework. For example, the asides follow the sidenotes section. Getting the vertical rhythm right was more challenging than I expected, especially with photos and other non-text elements that are inherently pixel-sized. I was trying to get everything working on a em-based grid at first, but eventually caved in and ended up with a 50 by 50 pixel grid on which to base the layout. There’s always more things to learn…

This was my first Wordpress theme from scratch and I was pleasantly surprised by how easy it was to develop. I’m tracking Wordpress’ SVN and the theme using Git. That too has been a fun learning experience; I’m getting much more comfortable with git, git-svn, and git-submodule as a result. If anyone is interested, I can write up a bit on how the whole development process fits together. In the meantime, here’s the code for the theme and my Wordpress mirror with that theme as a submodule.

Git really scratches an itch I’ve had for a while with SCM systems. I started out with zip files, then Visual Source Safe, then CVS and Perforce, then Subversion. I liked Perforce quite a bit, especially the branch and merge support, and Subversion works just fine, but the branching and merging support in Git is just phenomenal. I’ve built up a little library of reading material on Git if you’re interesting in learning more; I’d start with Git from the bottom up by John Wiegley.

Going forward, I’d like to extend the blog a bit and add some features using Dojo. It only seems appropriate. Maybe Ajaxy inline-comment loading? Real-time search? Fancy graphs? We’ll see.

As always, feedback is welcome and the comments are open.

We set up an isight and mac mini pointing out the front window of the office and using gawker scheduled a timelapse from 5pm ’til midnight July 4th. 1 frame a second, played back at 24 frames a second. It came out pretty well, especially considering we guessed which part of the horizon the fireworks would be on. Now you can see Red Banks Kaboom! in about 1:20. For a regular view of the fireworks we have here in town, check out Tom’s post over at Robotic Tom.

Red Bank July 4th Fireworks Timelapse from JP Sykes on Vimeo.

This weekend I finished up some code that I'd started a little while ago but hadn't had the chance to complete: a function, that can be used in the progressive enhancement style, for showing and hiding parts of a web page on demand.

dojo.addOnLoad(function(){ ondemand("ondemand1", "Show Details", "Hide Details"); }); document.write('#ondemand1 { display: none }'); Example

Tags:

Description:

Save

Source for example:

<script type="text/javascript" src="dojo/dojo.js"></script>
<script type="text/javascript" src="ondemand.js"></script>
<script type="text/javascript">
    dojo.addOnLoad(function(){
        ondemand("ondemand1", "Show Details", "Hide Details");
    });
</script>

<div id="ondemand1">
<form id="form1" action="#">
<p><label for="tags">Tags:</label><br>
<input id="tags" type="text"></p>
<p><label for="description">Description:</label><br>
<textarea id="description" rows="5" cols="30"></textarea></p>
<p><button type="submit">Save</button></p>
</form>
</div>

Usage

ondemand(elem, showLabel, hideLabel)

• elem: the element to make on demand (either an element object reference or an id)
• showLabel: the label for the button to show the element
• hideLabel: the label for the button to hide the element

The function hides the specified element and inserts a button into the document to show and hide the element again. To use in a progressive enhancement style, include the part of the web page that you'd like to be shown and hidden on demand as static content, and then call the ondemand function on it. If JavaScript is turned off, the content will always be shown and there will be no button to hide or show the content.

Source code

• ondemand.js

Progressive enhancement and flicker

Due to the page being reworked after loading you may see flicker as the content is initially shown and then quickly hidden. One approach for minimizing the flicker is to add a document.write statement that inserts a CSS rule to hide the content to be made on demand before it appears in the document. For example:

Content-Type: text/plain
document.write('<style type="text/css">#ondemand1 {
    display: none }</style>');

The document will still change after the page is loaded, as the button is inserted, but the change will be smaller than before and it will be additive rather than subtractive.

I continue working on Markdown parser and for now it already supports:

• span elements (bold, italic, inline images links and code)
• settext and atx headers
• code blocks
• blockquotes, partly supported for now (in some cases output differs from original Markdown output)
• horizontal rules
• backslash escaping for special chars (\*, \`, etc)

It took much more time than I planned to implement all this stuff. The process
of writing a good syntax definition to support all possible cases appeared to
be very tricky. However I'm moving on.

Things that are left:

• lists
• paragraphs
• reference-style links and images
• autolinks

Here is the latest test you can play with - languages test.
For more info on Markdown's syntax you can visit official Markdown syntax documentation.

I’m not sure how I missed it for so long, but I’m now reading every word of the Linux Hater’s Blog. It’s beautiful catharsis, and I say that as someone who used to serve as President of a university LUG and who writes open source software for a living.

Like the author of LHB, I’ve written my share of low-level Linux stuff and shudder in horror and how backward the linux desktop still is. X11 is an abomination and configuring sound or wifi or some new-ish device…well, I still have those scars. It wasn’t that long ago that I was hacking together bits of kernel patches to get an early firewire iPod (a gift from Jennifer) working on my SuSE desktop. And I was using SuSE because it usually required the least futzing of the then-available distros. Even when Linux was my desktop OS of choice – I had since climbed down from my brief flirtation with OpenBSD – it was blindingly clear to me that building my own packages was a fool’s game. My time is simply worth more than that. Perhaps the most cogent point I took away from reading the LHB archives is that building professional code for the “Linux Platform” is nearly impossible, not because it can’t be done, but because it costs too damned much to justify the costs. The Linux crowd seems to mis-value the immediate vs. long term costs of choice. By failing to provide a binary-friendly environment, the Linux world creates conditions only friendly to Open Source software, crippling their platform and robbing it of the capital investment that would allow it to truly compete. Many people who suffer through some Linux distro as their desktop environment no doubt see this as a good thing. I, however, need to get some work done. The LHB cogently lays out why everyone else on the planet whose time is worth more than what Amazon charges for a CPU-hour on EC2 similarly dismisses Linux for anything but servers.

The almost religious belief that choice is good ignores the inability of most people (myself included) to fully judge the long-run costs of any given technology decision. Oddly, the web browser world seems stuck in a similar position. Choice in browsers is promoted like some sort of panacea, when in fact our big problem isn’t choice, it’s that browsers simply can’t natively attempt the feats we need them to accomplish. Smart people don’t replace their browsers, they use what works until it doesn’t any more. No wonder it’s taken Firefox so long to gain market share. Like linux distros, browsers evolve in hodge-podge was, never quite tracing a straight line toward real progress. The refrain of “standards will save us” seems to ignore the reality that, like the LSB, the existing W3C standards are absolutely insufficient to address the problems at-hand. Both CSS3 and HTML5 are nice first-stabs, but they don’t get us “there”. For Linux, the LHB points out that there’s zero reason to not ship “the same bits”, and for the web, the issue is that content can’t tell the browser “no, really, use that renderer”. Interestingly, Microsoft tried to convince the world that we should version our content and the standards zealots just shot them down without really considering the consequences. Instead of making the world safe for a better web, the HTML standards geeks instead did the most powerful thing they could do to prevent it from materializing. In essence, they preserved “choice” at the expense of utility. What a waste. Seriously, if these are the deep thinkers on “our team”, why not go just use Flash to build everything?

Many people have gotten worked up about Microsoft’s role in killing Netscape (although they tend to minimize Netscape’s role in its own demise), but ISTM that the real long-term harm done here has been to remove the renderer as a profit center. Once Microsoft set the price of the browser at “free” they effectively killed browser evolution as part of anything but an OS-based platform play (in part, to preserve their existing OS-based platform play). Interestingly, then, web-based services have routed around the difficulties of the platform to date to deliver apps that seemed well out of reach of HTML 4.01 as implemented by IE 6, but well, we’re a plucky lot, aren’t we? The most progress being made right now seems to be coming from a large software vendor in Cupertino with an OS-based platform play that absolutely needs the web to sparkle in order to drive adoption of their OS and hardware.

Like Linux, the web will probably lurch forward this way for the forseeable future. The standards zealots smacked down the IE team so hard on content versioning that I don’t think anyone else will have the testicular fortitude to try again for a good while. It’s down to the whole “vision thing”, and the web standards crowd doesn’t seem to have any. It’s about time someone took the punch bowl away from them once and for all. The open web needs real progress too badly to stall any longer.