Slashdot Mirror

JNLP, a.k.a. Java WebStart, was supposed to solve some of these problems to create easy-install desktop applications. I think the reason that JNLP hasn't become commonly used can be summed up by looking at https://aerith.dev.java.net/, a page for one of the flagship "Cool JavaOne Demos." If you click on the JNLP version link on that page, it will appear to start up, downloading a bunch of stuff and asking you questions. And then it does nothing. No error messages or any information to tell you what happened. Repeated attempts yield the same results, only faster because the requisite files have already been downloaded. At least, that was my experience. If it worked for you, I'd say that's even worse--it randomly works on some platforms and not others. How do you debug such a thing?

Firefox 2 includes the new WHATWG-specified client-side persistent storage. However, some argue it is critically flawed. Learn the arguments now and we can discuss this further on Slashdot in 2010!

No, no, you do NOT want yet another scheme for letting "content owners" run stuff on your machine. We have enough of those now: Java applets, Active-X controls, Macromedia Director programs, Microsoft's latest downloading DRM controls, etc.

Executable content has many downsides. First, all you can do is run it. It's really tough to do anything else with the content. Even resizing it for a device the content owner didn't intend can be tough. Try to reformat a PostScript file (PostScript is an executable language) for a small screen. Originally, repurposing HTML content was easy. With the mess we have today, it's tough to even archive it usefully.

Then there's the hostile code problem. This has essentially killed Active-X (which is hopeless), it's hurt Java applets (which were supposed to be secure, but weren't quite), and we're still having trouble keeping JavaScript in its cage. There are even Flash exploits.

Then there's the "Now everybody can do things their own way" problem. Every piece of content has its very own user interface, and usually not a very good one.

More fundamentally, executable content puts the content, not the user, in control. With declarative content, the user has control. With executable content, the content owner is in control, and can restrict the user as much as they want to. Which, as we know by now, will be as restrictive as they can get away with. You WILL watch the ad for twenty seconds before you get to the real page.

What we need is more descriptive power in HTML, so you don't need so much executable content. There are about ten things people do all the time with Javascript, and those should be supported with declarative code in HTML. We need more stuff like WebForms.

If you want the Web of the Future, try Second Life. Now that's a real "feature rich interactive networked application". It's a great toy, but a terrible way to deal with large quantities of information.

The W3C was very resistant to further work on HTML. The group pushing for advances in HTML is the WHATWG.

BTW, I love Atom, but there's really not much support for it compared to the various RSS "standards". Your example seems to go against your point.

I believe that this is a response to the actions of the WHATWG (Web Hypertext Application Technology Working Group) (X)HTML 5 and to Bjoern Hoehrmann leaving the W3C QA.

So it's not a new pie-in-the-sky idea like XForms or XHTML2, but something much more likely to be useful to web developers that need to work in a world where IE is (still) the biggest fish.

I believe that this is a response to the actions of the WHATWG (Web Hypertext Application Technology Working Group) (X)HTML 5 and to Bjoern Hoehrmann leaving the W3C QA.

So it's not a new pie-in-the-sky idea like XForms or XHTML2, but something much more likely to be useful to web developers that need to work in a world where IE is (still) the biggest fish.

What about the client-side session and persistent storage (like in Firefox 2) ? See http://www.whatwg.org/specs/web-apps/current-work/ #scs-client-side

The 1.x branch of Firefox used Gecko 1.7
Fx 1.5 uses Gecko 1.8
Fx 2 uses Gecko 1.8.1, so a much smaller change (as in no new feature in HTML/CSS, just bug fixes I think). The new features are in SVG (textPath support), JavaScript (1.7) and Client-side session and persistent storage
Fx 3 will be the next big jump to Gecko 1.9, with the reflow that will fix Acid 2 and incremental layout bugs, plus more CSS 2.1 and CSS 3 support.

The changes are nicely summarized in this page.

I find "Client-side session and persistent storage" to be quite interesting, and wonder if any major web apps will make use of it in the near future. There are also JavaScript 1.7 which makes JavaScript more Pythonic, SVG support, and several other features.

The spec states:

In non-visual media, and in visual media with scripting disabled, the canvas element should be treated as an ordinary block-level element and the fallback content should therefore be used instead.

which sounds like what you want. Unfortunately Mozilla hasn't implemented that behaviour, which is a bug (https://bugzilla.mozilla.org/show_bug.cgi?id=3025 66) that ought to be fixed. (I guess you could get the right behaviour by creating the canvas element in script and adding it to the DOM, but that would be kind of nasty.)

The spec also says that authors should provide alternate content that "conveys essentially the same function or purpose as the bitmap canvas" and also "should not use the canvas element in a document when a more suitable element is available. For example, it is inappropriate to use a canvas element to render a page heading". I can't think how else they'd encourage the use of alternate content, but it'd be interesting to see any ideas of how to help overcome the laziness of authors. Chrome-spoofing (assuming you mean making canvas content that looks like part of the web browser) is usually no different to the issues caused by normal images, except that the drawWindow method (a Mozilla extension (not added through the proper extension mechanism, which isn't terribly polite of them – Opera has done it more properly)) would let scripts read the pixels from e.g. form buttons and work out what theme you're using – so that's currently limited to being run by JS code in extensions and it can't be used by web content, to avoid the security issues.

And SVG does seem a generally better way of doing vector graphics than canvas+JS; but it's worse at dynamic bitmap graphics, which is why both exist :-)

Instead of ftp.mozilla.org, try the mirror page – currently it seems to list beta 1, but you should be able to modify the download URL to get the en-US beta 2.

One small area that has had a reasonable amount of improvement in Firefox 2 is canvas support – I've been working on a canvas-based FPS engine and get about 50% better performance in FF2 than in FF1.5, as well as lots of fixed bugs and memory leaks.

Most major changes (like the new graphics infrastructure that'll help provide hardware accelerated rendering, full-page zooming, HTML inside SVG, better printing, etc) are being left for Firefox 3, but FF2 seems like a solid improvement over the previous version.

The canvas is actually a nice example of progress on the web. After too many years with very little going on, the major modern browsers developers (Mozilla, Opera, Apple) are working in the WHATWG to add new features – it's a balance between proprietary extensions and W3C-style specifications, with browsers implementing features at the same time as the spec is being written and guiding its development. There's room for competition between browsers in terms of feature support, and we don't have to wait years for the standards to be completed first – but it's hopefully without the old problems of those features being proprietary and poorly designed. For example, Opera 9 supports much of Web Forms 2.0 and the Mozilla developers are just starting work on it too; and it's also designed to be backward-compatible, so the new forms are still usable in all browsers and can be emulated in some (e.g. IE) with JavaScript. Firefox 2 seems to be the first browser with client-side session and persistent storage, but web sites written to benefit from that feature will be able to immediately work with future versions of e.g. Opera that support it too.

With the popularity of trends like AJAX encouraging people to think about new ways to interact with users over the web, and browsers adding features to expand the possibilities open to web developers, it'll be interesting to see what happens in the next few years.

Instead of ftp.mozilla.org, try the mirror page – currently it seems to list beta 1, but you should be able to modify the download URL to get the en-US beta 2.

One small area that has had a reasonable amount of improvement in Firefox 2 is canvas support – I've been working on a canvas-based FPS engine and get about 50% better performance in FF2 than in FF1.5, as well as lots of fixed bugs and memory leaks.

Most major changes (like the new graphics infrastructure that'll help provide hardware accelerated rendering, full-page zooming, HTML inside SVG, better printing, etc) are being left for Firefox 3, but FF2 seems like a solid improvement over the previous version.

The canvas is actually a nice example of progress on the web. After too many years with very little going on, the major modern browsers developers (Mozilla, Opera, Apple) are working in the WHATWG to add new features – it's a balance between proprietary extensions and W3C-style specifications, with browsers implementing features at the same time as the spec is being written and guiding its development. There's room for competition between browsers in terms of feature support, and we don't have to wait years for the standards to be completed first – but it's hopefully without the old problems of those features being proprietary and poorly designed. For example, Opera 9 supports much of Web Forms 2.0 and the Mozilla developers are just starting work on it too; and it's also designed to be backward-compatible, so the new forms are still usable in all browsers and can be emulated in some (e.g. IE) with JavaScript. Firefox 2 seems to be the first browser with client-side session and persistent storage, but web sites written to benefit from that feature will be able to immediately work with future versions of e.g. Opera that support it too.

With the popularity of trends like AJAX encouraging people to think about new ways to interact with users over the web, and browsers adding features to expand the possibilities open to web developers, it'll be interesting to see what happens in the next few years.

Instead of ftp.mozilla.org, try the mirror page – currently it seems to list beta 1, but you should be able to modify the download URL to get the en-US beta 2.

One small area that has had a reasonable amount of improvement in Firefox 2 is canvas support – I've been working on a canvas-based FPS engine and get about 50% better performance in FF2 than in FF1.5, as well as lots of fixed bugs and memory leaks.

Most major changes (like the new graphics infrastructure that'll help provide hardware accelerated rendering, full-page zooming, HTML inside SVG, better printing, etc) are being left for Firefox 3, but FF2 seems like a solid improvement over the previous version.

The canvas is actually a nice example of progress on the web. After too many years with very little going on, the major modern browsers developers (Mozilla, Opera, Apple) are working in the WHATWG to add new features – it's a balance between proprietary extensions and W3C-style specifications, with browsers implementing features at the same time as the spec is being written and guiding its development. There's room for competition between browsers in terms of feature support, and we don't have to wait years for the standards to be completed first – but it's hopefully without the old problems of those features being proprietary and poorly designed. For example, Opera 9 supports much of Web Forms 2.0 and the Mozilla developers are just starting work on it too; and it's also designed to be backward-compatible, so the new forms are still usable in all browsers and can be emulated in some (e.g. IE) with JavaScript. Firefox 2 seems to be the first browser with client-side session and persistent storage, but web sites written to benefit from that feature will be able to immediately work with future versions of e.g. Opera that support it too.

With the popularity of trends like AJAX encouraging people to think about new ways to interact with users over the web, and browsers adding features to expand the possibilities open to web developers, it'll be interesting to see what happens in the next few years.

Instead of ftp.mozilla.org, try the mirror page – currently it seems to list beta 1, but you should be able to modify the download URL to get the en-US beta 2.

One small area that has had a reasonable amount of improvement in Firefox 2 is canvas support – I've been working on a canvas-based FPS engine and get about 50% better performance in FF2 than in FF1.5, as well as lots of fixed bugs and memory leaks.

Most major changes (like the new graphics infrastructure that'll help provide hardware accelerated rendering, full-page zooming, HTML inside SVG, better printing, etc) are being left for Firefox 3, but FF2 seems like a solid improvement over the previous version.

The canvas is actually a nice example of progress on the web. After too many years with very little going on, the major modern browsers developers (Mozilla, Opera, Apple) are working in the WHATWG to add new features – it's a balance between proprietary extensions and W3C-style specifications, with browsers implementing features at the same time as the spec is being written and guiding its development. There's room for competition between browsers in terms of feature support, and we don't have to wait years for the standards to be completed first – but it's hopefully without the old problems of those features being proprietary and poorly designed. For example, Opera 9 supports much of Web Forms 2.0 and the Mozilla developers are just starting work on it too; and it's also designed to be backward-compatible, so the new forms are still usable in all browsers and can be emulated in some (e.g. IE) with JavaScript. Firefox 2 seems to be the first browser with client-side session and persistent storage, but web sites written to benefit from that feature will be able to immediately work with future versions of e.g. Opera that support it too.

With the popularity of trends like AJAX encouraging people to think about new ways to interact with users over the web, and browsers adding features to expand the possibilities open to web developers, it'll be interesting to see what happens in the next few years.

XmlHttpRequest - you could do much the same thing with IFRAME elements, at least on your own site.

As far as I'm aware, XMLHttpRequest has the same restrictions as iframes and most other ways of accessing documents in different domains, so there's no difference in the "on your own site" aspect - in Mozilla it's the same origin policy and is applied to XMLHttpRequest too. That's actually quite annoying when you really want to load things from other domains; cross-document messaging is a handy solution (allowing one document to open itself to messages coming from anywhere, as long as it takes the responsibility to provide its own security to make sure nothing bad happens), though currently it's only implemented in Opera.

I think the more limiting issue is that it is so hard to do AJAX across domains. XMLHttpRequest doesn't work, nor do hidden iframes.

Not true - there's a trick to get around iframe cross-domain security. You can still see the URIs of the frame. This means that the domain you are attempting to access can supply a special page that calls XMLHttpRequest on your behalf and streams the data to you by updating the fragment identifier.

It's an awful hack, but it's been wrapped up in an XMLHttpRequest emulation by Dojo.

Looking further ahead, there's already a proper model for cross-domain communication, and Opera already supports it.

I never understood why web standards aren't maintained by the folks that actually are writing the browsers. Membership would require a browser with, say, x% market share.

This would seem to be a slam dunk to me. I figure you get Microsoft, Mozilla and Opera to the table, you'd have some pretty interesting standards developed that the browsers might stick to.

Might. Anyway, it'd be better than having some extra organization making up rules that none of them really pay more than a passing look at.

Yes, efforts exist, and bless the WaSP and the WSG and all the children of Jeffrey.

But the problems outlined in TFA are not addressed by your link. It's fine to say "Standards are Good, Here's How to Use Them" as WaSP does (and as I do, on a small scale). But if the standards themselves are bit-rotting, and the tools for measuring compliance are broken, and no one is minding the store, then good intentions and bootstrap education are only going to get you so far.

Having said that, I am aware of one genuine potential alternative out there, and if there are others, please launch the URIs.

(PS: Reading between the lines of the last paragraph at that link makes me think that you, me and Björn might not be the only ones concerned here...)

Isn't that what Web Hypertext Application Technology Working Group is?

Well, just as an outside observer, it seems like the W3C is not very interested in "the web as application platform" -- instead pushing new document models like XHTML2 that don't really solve any realworld app dev problems.

At least from my POV, the stuff going on at WHATWG -- such as a vastly improved FORM model and standardized AJAX support -- will have much more relevance to the web in the manner that I and probably most other slashdotters build it.

Actually, there already exists such an organization: the WHATWG. It was created by browser developers including Opera, Mozilla and the makers of Safari. They have released several specifications, some of which have already been implemented into the browsers. For instance, the canvas element, and SessionStorage, which is included in the upcoming Firefox 2.

Quite frankly I prefer the idea of a single standards organization, in this case the W3C. It's more sensible to find ways to make this organization more flexible and open than to start having competing standards and the unavoidable incompatibilities. But sometimes there is no alternative than radical change. I hope it doesn't come down to this.

Maybe i'm completely wrong, but aren't Java applets just Java programs thrown into a browser window in a secure context? I agree with you, in my opinion it *is* rather disturbing that people are trying to make Javascript do just that, as AJAX, without any standard mechanism for doing so in place (Hence all these AJAX frameworks popping up).

The problem with Java applets (as far as I'm aware) is they don't integrate smoothly into the DOM, play nicely with stylesheets and can't be extended as easily to access all that juicy browser functionality. What people want from AJAX is the best of both worlds. Java can't do that (yet?) but, although it's distusting and ugly, Javascript can to a degree at the moment

This is why standards like XSLT, 'Web Applications 1.0' and new versions of Javascript are coming into existance, there is now an apparent need for smoother and more standardised integration between a user's interaction with a client side document, client side data or state, and the server side (database backend).

Of course the side effect of doing more work on the client side is you have less and less data hitting the server you cannot trust and XSS, SQL injection attacks and God knows what other vulnerabilities are going to play and larger and larger role in 'Web 2.0'

And just why is IE finally improving matters? Because Firefox has shown itself to be a threat.

The way I see it, a bunch of viably competing browsers will keep IE on its toes. If Firefox, IE, Opera and Safari -- in other words, the Gecko, Trident, Presto and KHTML rendering engines -- each have significant marketshare, then they put pressure on each other to offer complete coverage of the specs and to innovate further. As long as they don't sacrifice stability like IE and Nestcape seemed to during the first round of browser wars, having them all fall over each other trying to add more capabilities. And with any luck, having 3 or 4 major players instead of just two would encourage WHATWG-style innovation over unilateral <blink> or <marquee>-style garbage.

So that's the goal: keep Firefox growing, keep Opera growing, and let them all keep each other honest.

The canvas extension in question is the opera-2dgame context. Some of what it features is:

• setPixel and getPixel
• point in path-detection, using checkCollision
• canvas update locking

There is work underway to get a similar API for the canvas into the specification.

Disclaimer: I am the author of the mentioned blog post detailing the opera-2dgame context.

> While the Writely and Google Spreadsheets combo are not "killer apps" in terms of features

Actually, Writely and Google Spreadsheet are Labs toys right now. However fast forward one year, with Firefox sporting an embedded database, and Writely and Spreadsheets will look far less toy-like. Add support for rich controls from the WHAT-WG and in a couple of ears you have an office suite you can download on demand and run inside your browser. And you can work with it offline.

And if you think Microsoft hasn't read the writing on the wall, you haven't been looking at XAML and IE7 very closely.

HTML 5 is currently the spec. being worked on by WHATWG. You can read more about it courtesy of Anne van Kesteren.

That's generally considered a bug in the spec, and HTML 5 being developed by the WHATWG will undeprecate it.

No, I don't care. The validator is a mechanical tool. It's inherently flawed, understanding nothing of semantics, easily tricked into validating things which never should validate, and in a number of cases throwing incorrect warnings and errors. Having your website validate is a first step. A guideline to doing things the right way. It's not completely necessary. The <canvas> element (as specified by the WHATWG, and implemented by Opera, Mozilla/Firefox/SeaMonkey and Safari (I'm reasonably certain)) will cause errors to be thrown, yet one can imagine cases where its use is already perfectly acceptable. (Just as long as you don't use it on a client website, or at least not without full understanding of the implications by the people there of using something which can change out from under them at any moment, and their responsibility to track those changes.)

Yes, I care. I'm a professional web developer. Of course my website validates, besides also being completely accessible and being as semantically meaningful as it can possibly be. It's just a little showcase of my technical expertise. And yes, I care, as in: if you as a fledging web developer come to me on IRC or on some mailinglist for help with your website, you'd better be damned certain that your website validates before bothering with me, as I'm not going to spend any time on what would otherwise almost certainly turn out to be a problem caused by your invalid code.

Those two points made: wow, what's with the harping on ACID 2? Yes, it's a nice test to spur browser makers on to come closer to being perfectly interoperable, but it tests a pretty arbitrary range of rendering bugs, and all browsers save for IE are pretty much interoperale on it at this point. (Firefox only on the reflow branch, to be sure, but that's set to land Real Soon Now, and as has been explained often, ACID 2 came at the worst possible time in the Mozilla development cycle.

Regarding HTML, you may want to take a look at WhatWG.

Regarding JavaScript, the what's new in JavaScript 1.6 at Mozilla Developer Center might help, too (By the way, Mozilla CTO, Brendan Eich, created JavaScript while working at Netscape).

I never said code for a specific browser -- I said don't use XHTML. I'm a supporter of valid code, and the Any Browser Campaign, but I don't currently support XHTML, because there is better cross platform support for HTML4 than there is for XHTML 1, because XHTML is not directly compatable with HTML

You can write pages that will degrade gracefully under both XHTML and HTML -- but you can't write a valid XHTML page that will parse cleanly in IE, XHTML is not backwards compatable with HTML, due to the need of an XML declaration before the HTML doctype.

To get XHTML to work in browsers that don't directly support XHTML, you'll have to serve it as text/html, which can then cause problems which correctly support XHTML. more details at wikipedia.

You get better overall support in browsers by coding to HTML4.01 -- there are few advantages to the user to using XHTML 1.0 (it's easier on the browser code, that's about it). That's not true with XHTML 2, which offers better alternative text for images and objects, as well as more easily arranged sections and dramatically updated Web Forms, but I have no idea when we'll get browser support for it. (hell, we don't even have good support for CSS2, much less CSS3 in most browsers)

Use standards compliant XHTML and CSS.

I agree about the use of standards, but "the nice thing about standards is that there are so many to choose from" (Andrew S. Tanenbaum). What is the advantage of XHTML 1.0 over HTML 4.01 or HTML 5.0 if you have customers who use Microsoft Internet Explorer 6.0 SP2 or earlier? XHTML 1.0 served as text/html is treated as tag soup, and XHTML 1.0 served as application/xhtml+xml to IE is a parse tree.

The idea of people who actually write markup language specifications and know a heck of a lot more about the internet than you do.

See also A blog post by someone who actually makes browsers and also knows a heck of a lot more about the internet than you do.

You are making the erronous assumption that the only thing that the CSS specifcation specifices is the behavior of a CSS engine when it encounters valid CSS. In fact, unlike the HTML specifcation but like the HTML5 working draft - which, coincidentially, is breing edited by the member of the CSS WG who wrote the ACID2 test - is specified the behavior of a conformant engine in the face of invalid input. Obviously care has to be taken to make this forward compatible enough that future extensions are not hampered and useful enough that CSS does not die the slow death of XML-on-the-web. Done right, however it is critical in preventing the fragmentation of error handling implementations that drove the browser wars and continue to make it very difficult to write a useful HTML parser.

Which is the standards-compliant, non-crazy-scripty way of doing it.

Actually, that's not true. The load() method was part of early DOM3LS drafts, but was taken out before the specification reached Recommendation status. As far as I'm aware, there's no non-draft specification describing load(), nor plans to write one.

XMLHttpRequest, on the other hand, is part of the draft "HTML 5" specification published by the WHATWG, and I expect it will remain there permanently.

HTML Application. It allows the Webapp to run even when you're not connected. Currently this is Microsoft specific (though the same thing can be achieved with most other browsers through downloadable HTML files), but there is a rough standard that's being worked on to make it available across all browsers and platforms.

An HTA application can continue to allow someone to work (caching the necessary files on disk, and saving updates to disk) until the next time a network connection is made. Then it can shunt the data to the server as if nothing happened.

Web Forms 2.0 <> Web 2.0

Simultaneously both a question and a statement!

The WHAT working draft Web Applications 1.0 certainly looks like Ajax with its XMLHttpRequest, drag and drop and other Ajaxish stuff.

Canvas is a WHATWG (Web Hypertext Application Technology Working Group) recommendation for a "resolution-dependent bitmap canvas, which can be used for rendering graphs, game graphics, or other visual images on the fly". In other words, it's some of that web 2.0 stuff. More info here.

ought to focus on beefing up existing features rather than adding new cross domain holes

Just wanted to point this out:

XHTML2 -- with navigation lists, links on any element, sections and headings -- is optimized for web documents.

HTML5, officially Web Applications 1.0 -- with canvas, a drag and drop API, and XMLHTTPRequest standardization -- is optimized for web applications.

CSS3 is going to be extremely cool.

Read those first. It seemed at the time of the publication that the XHTML 2.0 team were making all the mistakes of the designers of HTML 3.0 - creating teh perfekt markup language, instead of contributing called-for improvements, even if the two overlap a lot to our benefit. And I don't think that's changed. (I don't mean to disparage the many good changes in XHTML 2.0, but I ultimately think that their goal (stripping down and semantically cleansing XHTML 1.1?) is a different one than mine, and that that means we're not getting the improvements we want.)

My money's with, and my faith's in, HTML5.

I thought HTML 5, a.k.a "Web Applications 1.0" was the future?

(from the my-future-is-better-than-your-future dept.)

It's HTML 5.
XHTML looks nice in theory, but HTML 5 is being designed for real world use. It can be sent with an xhtml mime-type too.

Why isn't there a hue-and-cry about Firefox "extending" things unilaterally?

at which point Microsoft will be demonized for adding non-standardized features.

You mean the non-standardized feature that the /. summary has a link to the specification of? Do you not think it's important to follow the links in the summary before commenting?

Here, I'll copy the link from the summary, but use the URL as the link text and even make it bold for you:
http://whatwg.org/specs/web-apps/current-work/#pin g

At the same time, I *DO* think that unless this is to be submitted for standardization, it's just yet another wart

The /. summary links right to the specification. Are you blind? Here, I'll put it in bold for you:

http://whatwg.org/specs/web-apps/current-work/#pin g

The way it got into Firefox?

You might want to start reading the original proposal to WHATWG (by someone who currently works for Opera, incidentally) and the ensuing discussion. You might find it enlightening.

On the subject of current methods of tracking via redirects, he says:

The problem at the moment is that the redirect mechanism obscures the eventual target URI. It would be good to have the target URI separate from the tracking URIs, so that the UA can show each of them separately in the UI, indicating the user who is getting told what.

Doing this would also allow the UA to easily turn off the pinging thing for users who are worried about point 4 above.

Ever heard of WHATWG? Mozilla, Opera, and Safari are all actives members of it and will all support WHATWG specification features, including this ping attribute.

Firefox devs didn't make it up on their own. This comes from work by the WHATWG, a group that's working on continuing HTML instead of XHTML. They've got reps from Mozilla, KHTML/WebKit, and Opera, and they're doing public specs so that anyone can implement the standards they develop. Look no further than <canvas> for an example. Apple developed it for Dashboard, built it into Safari, and suggested it to WHATWG. WHATWG hashed it out, and now Firefox supports <canvas>, and Opera will support it as soon as version 9 is released.

Really, the summary should have read "WHATWG's Ping Attribute: Useful or Spyware?" -- but Firefox is the first browser maker to experiment with this particular feature (and yes, it's still at the experimental stage), and we all know that "Firefox...Spyware" is more attention-grabbing than "WHATWG," which would simply inspire a bunch of "WTF is WHATWG?" posts.

My question is where did this idea come from? Is it in an HTML standard somewhere? If not, they shouldn't have bothered putting it in IMHO. How can I tell my friends that Firefox aims to be more standards compliant if the Mozilla team is putting in proprietary HTML features?

It's being debated for standardization by the Web Hypertext Application Technology Working Group, a collaboration of developers and browser makers who think the W3C has basically stagnated and stopped paying attention to real-world problems, and so are working on building consensus for the standardized, interoperable implementation of new features and technologies. And keep in mind that even at the W3C a new feature in a spec can't be officially standardized until there are implementations in the wild, and in the past new features have often been standardized after being implemented independently by browser makers.