All posts tagged ‘politics’

File Under: Browsers, Software

Firefox Without Add-ons? Say it Ain’t So

If you want to know what a chorus of angry Firefox users sounds like, just make them think you’re taking away their browser add-ons.

A blog post from Mozilla’s Mike Connor, one of the company’s key browser developers, made waves Saturday and Sunday in the Firefox world for suggesting that scenario. While Connor didn’t explicitly say it would happen, his words led many readers to assume the company was considering abandoning the current Firefox add-on ecosystem in favor of JetPack-based add-ons

We asked Mozilla about this possibility and the representative we spoke to insists it’s certainly not the case. Connor’s post has been updated and much of the hubbub has settled down, but the post did spark an important discussion about browser add-ons and the relationships users have with them.

Connor’s post outlined a few lines of thought that have been going on behind the scenes among Firefox developers, as they have been strategizing about the browser’s future.

Exactly what Connor intended to say is still a little unclear. The initial post used phrases like “deprecating the old systems” and suggested that Mozilla would be “discriminating against the old systems” — that is, the current Firefox add-on ecosystem we all know and love — as it moves forward with its software releases.It certainly sounded like somebody at Mozilla was talking about killing off add-ons as we know them and replacing them with the still-beta JetPack add-on system and the Personas theming system. JetPack is Mozilla’s platform for creating simple add-ons that manipulate web page elements and UI elements within the browser’s skin, much like Greasemonkey scripts or the type of DOM-futzing that Chrome’s extension system allows. Personas, Mozilla’s theme manager, allows users to alter the look of the browser by installing a visual theme with one click.

Once a rather vocal community began reacting to the post (read the comments) Conner added an update that backpedaled a bit, but still concluded that, while the plan might be not be “set in stone,” Mozilla does intend to move in that direction. When he said that Mozilla was “discriminating against the old systems,” and added “I am personally at peace with that,” Conner was essentially throwing down the geek gauntlet, whether he meant to or not.

To understand why those statements caused an uproar, you must first understand that, as it stands, JetPack is full-fledged Firefox add-ons what Mini Me is to Dr. Evil — a cute but much less powerful sidekick.

JetPack makes it simple to build simple things, but in its current incarnation it could hardly produce a NoScript, an AdBlock Plus or any of the other popular, powerful Firefox extensions.

Presumably, long before Mozilla makes an attempt to officially migrate from the current system to the JetPack system, the company isn’t likely to turn its back on the over 5,000 add-ons currently shipping for Firefox.

But Conner’s post had an element of immediacy to it and that quickly brought out the die-hard Firefox add-on fans writing “over my dead body” and threatening to abandon Firefox in favor of Google Chrome (ironically, when we recently critiqued Chrome’s current add-on plan, we did so because it fails to offer developers exactly the tools that Conner is suggesting Mozilla might eventually take away).

Why would Mozilla want to limit developers? Well, the truth is that’s not at all what JetPack is aiming to do.

In fact, the JetPack program is an attempt to make developers’ lives easier. JetPack offers niceties like stable APIs (so new versions of Firefox won’t break all your add-ons), automatic updates, sandboxed add-ons for a more secure browser and process isolation so add-ons won’t crash Firefox.

But of course simplicity comes with a price, and this is where Conner runs afoul of the nerds.

To many, the power of Firefox is precisely in its infinite extensibility. Does infinite power bring infinite possibilities for problems? Yes, but the tradeoff is worth it, so say Firefox’s die-hard add-on users.

It’s precisely the fact that users can do whatever they want within the browser that has elevated Firefox to where it is today. Outside developers have been able to push the envelope the web browser’s capabilities, extending it to do things that even the founders of Mozilla would likely never have imagined.

The real issue might simply be whether or not Mozilla recognizes this. Writing about the reasons why Mozilla wants to eventually switch to JetPack-based add-ons Conner talks about updates and problems with add-ons. “We already know from our users,” he writes, “that incompatible add-ons are a significant factor in opting out of updates.”

The message here is not that the add-on system needs to be changed so that people will have a cleaner upgrade path for their browser, but that the browser is irrelevant and the add-ons are what matter.

Firefox, Chrome and Safari routinely swap the top spot in speed tests, and the browsers match each other pretty closely in feature breakdowns, including Firefox’s once-unique core strength — support for the latest web standards.

But there is one huge difference that sets Firefox apart — the ability to infinitely extend it through add-ons. Take away the full power of add-ons and Firefox is just another browser. It might be easier to keep up-to-date since you wouldn’t have to worry about compatibility, but there wouldn’t be anything too special about it, functionality wise.

However, despite some perhaps poor wording in Conner’s post, Mozilla is not about to abandon traditional add-ons. Will many developers chose to port their add-ons to the JetPack system? We hope so. It makes it much easier to develop and maintain simple add-ons. But for the more powerful add-ons, Mozilla will likely leave existing frameworks in place for some time.

See Also:

File Under: APIs, Web Services

Craigslist Reverses Yahoo Pipes Ban, But Developers Have Already Moved On

Earlier this month, Craigslist blocked Yahoo Pipes from accessing any Craigslist page. As a result, mashups all over the web were suddenly without data.

After not responding to inquires, Craigslist CEO Jim Buckmaster eventually posted a terse message on the company’s blog saying that Yahoo Pipes mashups were using “a disproportionate amount of server/bandwidth resources.”Now it would seem that Craigslist has ended its ban of Yahoo Pipes, but for developers we imagine the damage has been done. For its part, the startup Flippity, which was the first to notice its Yahoo Pipe had been blocked, says it has moved on to friendlier sources, rewriting Flippity to use the eBay API.

It wasn’t the first time Craigslist has shutdown outsiders trying to improve on the site’s famously antiquated tools — the site previous blocked ListPic, a tool designed to help Craigslist users browse by images, and a tool to search all the Craigslist sites at once.

As we said in our initial report on this debacle, if you’re a developer looking for data to use in a mashup, think twice about Craigslist. The site has a wealth of data, but it guards it jealously and has no qualms about blocking even major players like Yahoo.

See Also:

File Under: Web Services

Craigslist to Developers: Look Elsewhere For Mashup Data

Thinking of building a mashup using Craigslist data? You might want to look elsewhere for classified listings.

Craigslist has a long history of being openly hostile to outside developers, but the site took its walled garden mentality to new levels with a recent decision to block Yahoo’s popular Pipes tool from accessing the site’s data.

According to developer Romy Maxwell, Craigslist has blocked Yahoo Pipes primarily to stop his mapping mashup, Flippity. The Flippity mashup was using Yahoo Pipes to gather Craigslist posts from its public RSS feeds and plot them on a map. This apparently rubbed Craiglist the wrong way, but rather than just block the offending Pipe, Craigslist decided to block the whole service — effectively killing thousands of Yahoo Pipes-based mashups.

This isn’t the first time Craigslist has shutdown outsiders trying to improve on the site’s famously antiquated tools — the site previous blocked ListPic, a tool designed to help Craigslist users browse by images and a tool to search all the Craigslist sites at once.

However, unlike ListPic, which Craigslist claimed was using resources excessively, the latest ban doesn’t seem to be about traffic.

In his blog post, Maxwell claims his application complies with Craigslist’s terms of service and doesn’t use excessive bandwidth. In fact, according his post, the Yahoo Pipe in question is private and only runs once every fifteen minutes. Couple that with the fact that Yahoo Pipes caches the data it scrapes, and one could conclude that bandwidth concerns should not be a factor in the shutdown.

As Wired magazine reported in its cover story about Craigslist earlier this year, the company has been quick to ban third-party search services which “[subvert] Craigslist’s mission to enable local, face-to-face transactions” or services which “increase the risk of scams and can be exploited to snatch up bargains, giving technically sophisticated users an advantage over casual browsers.” Flippity doesn’t appear to have been introducing any feature that would enable such behavior.

So, perhaps Flippty was in violation of the TOS? Maxwell asked founder Craig Newmark about the app and Newmark told him, “as a rule of thumb, [it's] okay to use RSS feeds for noncommercial purposes.”

If it’s unlikely to be about bandwidth and there’s no overt violation of the TOS, why ban Yahoo Pipes?

Frankly, we’re not sure. Craigslist isn’t talking — we’ve contacted the company and asked for an explanation, but as of this writing, nobody has gotten back to us, nor has any public statement been issued.

One thing that is clear though, if you’re thinking of adding Craigslist data to your application, think again.

For its part, Maxwell says Flippity will continue, but plans to use data from developer-friendly sites like eBay and Oodle.

See Also:

Microsoft Wants to Separate the Canvas 2D API from HTML5

In an e-mail sent to the public-html@w3.org mailing list on Wednesday, Microsoft’s Eliot Graf proposed removing the Canvas element, which is used to create complex vector animations in the browser without plug-ins, from the HTML5 specification. Graf also proposed launching a new, separate specification for the Canvas 2D API.

His e-mail:

In his mail describing why he created a separate Canvas 2D API specification, Doug Schepers wrote [1]:

> There is a chance that currently Canvas could be a blocker on progress

> for the HTML5 spec, and at this point, Canvas is so widely implemented

> that I don’t think it’s at risk, so I hope this isn’t disruptive. I am

> available to help with any editing that needs doing, but I hope that

> others will also work with this draft, and step into the editor role.

At Microsoft, we agree with the sentiments expressed by Doug, Maciej [2], and others about creating a separate Canvas 2D API specification. [3] We are prepared to offer editorial resources to aid in the completion of this separate specification. We have looked over Doug’s initial document, made some editorial enhancements, and are prepared to follow through in taking feedback and maintaining the specification.

We believe that some sort of accessibility API functionality is needed in the canvas element. However, the exact nature and depth of that functionality presents a dilemma that may block progress on the HTML5 spec. We also think that the Canvas 2D API may be a desirable feature used in other technologies such as SVG.

Starting with Doug Schepers’ initial draft, we made changes to get the document to adhere to the W3C PubRules [4], enhance readability, and improve logical flow of the document. In addition, we foresee adding sample code throughout the specification, where appropriate. No normative changes have been made. As with all drafts, the Canvas 2D API specification is still a work in progress. We would like to solicit feedback about the changes that were made (see below TODO) and about further changes that the working group would like to see.

Our updated version is published at http://dev.w3.org/html5/canvas-api/canvas-2d-api.html.

[1] http://lists.w3.org/Archives/Public/public-canvas-api/2009JulSep/0002.html

[2] http://lists.w3.org/Archives/Public/public-canvas-api/2009JulSep/0007.html

[3] http://lists.w3.org/Archives/Public/public-html/2009Aug/0628.html

[3] http://www.w3.org/2005/07/pubrules

[...]

Microsoft Internet Explorer is the only modern browser with no plans to support Canvas — Firefox, Chrome, Safari and Opera all do. Redmond’s opposition makes sense, as the animation capabilities Canvas provides would conflict with Microsoft’s plans to speed adoption of its Silverlight platform, which affords web authors many of the same capabilities using a proprietary plug-in and commercial development software.

Several list members pointed out that if Microsoft has the resources to author the spec independent of HTML5, those resources could be better spent building support for Canvas into the browser.

A follow-up response from Ian Hickson, a Google employee who is the primary editor of the HTML5 spec, points out a few clear problems with this strategy and stresses that it doesn’t seem list a good idea:

IF we’re going to split out the 2D API — and I’m not really sure if at this point that’s something we should do, frankly — then I would much rather we do it based on the text in the HTML5 spec now, and would much rather we have an editor who is able to give this the full-time attention that it needs.

However, I’m really not sure at this point that it even makes sense to extract the API anymore. The API intergrates pretty tightly with the rest of HTML, for example it refers to HTMLVideoElements, the HTML5 “structured clone” feature is defined in terms of canvas interfaces, and so on. There would have to be a two-way reference, which would be a maintenance nightmare, and which would just delay the progress of both documents.

What are the problems that we are trying to solve by splitting out the API at this point?

The whole thread, which is still growing, can be viewed here.

What do you think? What’s Microsoft up to?

Greasemonkey Shows Off Political Colors

Memeorandum colored by Greasemonkey script

Andy Baio, a prominent blogger and creator of Upcoming.org, has released a Greasemonkey script to visualize the perceived political bias of linked content on the political news aggregation site Memeorandum. If a site tends to link to more left-leaning stories, it’s colored blue. Right-leaning linkers are red.

With the help of Delicious founder Joshua Schachter, Baio used a recommendation algorithm to analyze the last three months of linking behavior for each news source. With that data stored in a Google Spreadsheet, Baio used the Ajax support in Greasemonkey to grab a JSON feed and colorize the links. Those with Firefox’s Greasemonkey extension and Baio’s script installed will see the colorized links when viewing Memeorandum. Baio also released a full-fledged extension that does not require Greasemonkey.

This is a great example of how Greasemonkey can be used to change the way you view a page. In Baio’s case, he wanted to see the perceived bias of a site at a glance so he could choose a balanced view. The code from this project is available under the free and open-source GPL license. You could use it to create other ways of visualizing data on the web.

GreasemonkeyIf you’re brand new to Greasemonkey, be sure to read my new Greasemonkey tutorial on the versatile Firefox extension. If you’ve ever written JavaScript before, you’ll quickly learn the ways of Greasemonkey, which essentially gives you the ability to insert your code anywhere in someone else’s site, but only for your own use on your local machine.

You don’t need to bite off as much as Baio, who admits this is his first Greasemonkey script. One of the biggest benefits I’ve found is that I can write code to pull out the important stuff already in the page. My tutorial shows a simple example of that, where I create a floating menu of all <h2> tags on the page. It turns out this is useful for long Wikipedia entries… and Webmonkey tutorials.

See also: