Repository navigation
Requirements
We think that multiple-file download capability should be built into every browser. With the introduction of the download attribute, browsers and web authors have a simple, standard way to agree on what content is downloadable. We will support the extensions in this project for each browser until the browser provides built-in functionality to replace it.
Each browser presents technical and UX challenges to implementations. We aim to fit into the conventional UX expectations for each browser while giving the page user a intuitive and capable UI. The goals for each browser are:
- remain hidden or inconspicuous when there is no downloadable content on a page
- present an obvious but unobtrusive control when there is downloadable content on a page
- respond to dynamic changes in the page contents
- when clicked, present a compact, tidy interaction surface for choosing files
- use the platform's conventional means to choose a destination folder
- rename incoming files to resolve destination file name conflict
We chose Chrome initially because it has a simple extension programming model and an extension API that can meet most of the goals using only HTML and Javascript. This allows us to quickly publish a working version to be a model for the remaining browser add-ons.
Chrome does not let an extension activate the platform's directory chooser so that requirement is not expected to be met in the Chrome version. Instead, the Chrome version lets a user enter a name for the download folder. That folder is created within the user's default download folder if necessary and the selected files are downloaded into it.
The beta release of the Chrome extension is available now.
We are treating FF a little differently. It has the most capable extension API and we think that some of the work that goes into the extension might form the basis for a modification to Firefox itself. We were able to meet all of the stated goals in the first release of the extension.
Next, we want to take what was learned form the extension development and see how much of can be re-used in a proposed patch to Firefox itself. We welcome any community expertise in doing this. If Firefox adds this as a feature, other browser developers might start to include this functionality in their own products.
The alpha release of the Firefox extension is available from the Mozilla Add-ons website.
A safari solution will require a native component. We are exploring developing an NPAPI-based content handler that can be embedded via the content script.
The IE work will follow the Safari work at MSI. Our initial investigation suggests that developing the add-on for IE will take significantly more effort than the Chrome or Firefox extensions.
MSI has no plans to work on other browser add-ons now but we hope that interested developers might scratch their own itches and contribute add-ons for their favorite browsers.