Category: Uncategorized

Posted on

WHATWG and RSS

Dave Winer seems to have misheard my exchange with the Gillmor Gang about RSS and HTML: I was asked, at around 36 minutes into the show (not 20 minutes), whether the Web Hypertext Application Technology Working Group considered RSS to be “completely orthogonal” to HTML, and I said (paraphrasing slightly) “RSS is not on the WHATWG’s radar, we are extending HTML to better support web apps”.

Steve Gillmor then went on to aver that RSS and HTML were orthogonal, and asked about browser built-in HTML editing support for bloggers.

Based on this brief exchange, Dave blogged: “I agree with everything Brendan says up to the point where he says RSS and HTML are orthogonal. Take another look, RSS wraps chunks of HTML with useful metadata.”

Now, wrapping chunks of HTML in RSS sounds like a proof of orthogonality to me, especially if the HTML can be wrapped and unwrapped freely. But maybe I’m using too mathematical a definition of “orthogonal.”

WHATWG may yet be interested in RSS for HTML metadata, but no one involved has brought RSS up in connection with web apps. Dave, if you care to make a proposal, here’s the list info.

/be

Posted on

Mozilla 2.0 virtual machine goals

  1. Multiple languages supported, including JS, Java, and Python.
  2. Good cross-language integration: inheritance, type matching, etc.
  3. Cross-language debugging, ideally including C++.
  4. One GC to rule them all, preferably one shared GC, not a super-GC ruling a zoo of heterogenous GCs and reference-counting subsystems.
  5. Decent JITed performance, because performance matters when you can least afford to rewrite in C++.
  6. Sandboxed execution security model, type safety, defense in depth.
  7. Part of a larger open source platform . . .
  8. . . . that has momentum and excited developers hacking on it.
  9. A sufficiently open specification process for standardizing and evolving that platform.
  10. New XML language implementations easy to write, plug in, and demand-load (if we had this today, we would use it for non-web standards such as XForms).

The last item means some number of frozen APIs into the content code, e.g. XTF. SVG and existing XUL and HTML widgets may provide a rich enough rendering vocabulary. If we can mix them well using XBL, then we may not need to expose frozen APIs into layout, gfx, etc.

The goal should be minimal, supportable, and composable high-level APIs, where possible. XBL and XTF point the way.

Back to the more programming-language-specific points above: comments welcome on realistic candidates. Obvious and controversial possibilities include Mono, Java (if open source), and Parrot (last I looked, *way* too Perl6-focused, not very mature, not looking likely to mature quickly).

/be

Posted on

Mozilla 2.0 platform must-haves

  1. libxul.so/libxul.dll, a versioned shared library with minimal, frozen, documented API exports, and fast intra-library calling convention code (so small footprint compared to today’s “GRE” or “XRE”).
  2. xulrunner/xulrunner.exe, so you can write ‘#! /usr/bin/xulrunner’ at the top of a .xul file and get busy.
  3. XUL 2 and XBL 2 — standardized specifications, greater binding language power, more scripting languages, iTunes-like widgets, and working remote XUL/XBL.
  4. SVG support to a useful level, not necessarily the whole 1.1 spec.
  5. Web Forms 2.0.
  6. XForms Basic (or ultra-Basic, details TBD — the heavyweight item is Schema-based validation) support as an optional, downloadable extension.
  7. JavaScript 2.0 support, including ECMAScript for XML support.
  8. Python support, perhaps via Mono (if so, along with other programming languages).

That’s a good start. Comments?

/be

Posted on

The non-world non-wide non-web

I spent a day at the recent w3c workshop on web apps and compound documents. Due to vacation, that day was the second, so I missed the chance to hear JavaScript praised as the worst invention of all time.

The adolescent sniping and general irrelevance continued on the second day, however. The sad fact is that the w3c is not concerned with the world wide web, AKA the Internet. Rather, the focus for a while now seems to be on vertical tool/plugin and service/cellphone markets, where interoperation is not a requirement, content authors are few and paid by the vertical service provider, and new standards provide livelihoods and junkets for a relative handful of academics, standards body employees, and big company implementers.

Evidence of the vertical nature of the new standards? There are only a few hundred tests for the SVG w3c recommendation. That’s several decimal orders short of what is required just for surface coverage. Often recently, when Hixie hears of a claim about an interesting SVG standard feature, he writes a testcase. Adobe’s plugin too often fails that testcase, although I am sure Adobe SVG tooling produces content that works with the Adobe plugin. Interoperation is a joke.

Real browser vendors, who have to deal with the ugly web as it is, know better. The dream of a new web, based on XHTML + SVG + SMIL + XForms, is just that — a dream. It won’t come true no matter how many toy implementations (including Mozilla implementations — we’ve supported XHTML for years) there are. Long before the w3c gets compound documents working on paper (having missed the chance with SVG 1.0 and 1.1, which ambiguate and conflict with CSS), XAML etc. will leak onto the public web.

What matters to web content authors is user agent market share. The way to crack that nut is not to encourage a few government and big company “easy marks” to go off on a new de-jure standards bender. That will only add to the mix of formats hiding behind firewalls and threatening to leak onto the Internet.

The best way to help the Web is to incrementally improve the existing web standards, with compatibility shims provided for IE, so that web content authors can actually deploy new formats interoperably.

What has this to do with Mozilla’s roadmap? Not much, which is why apart from HTML, CSS, DOM, and SVG, which we support, you probably won’t hear much more about the w3c here. But Mozilla is joining with Opera and others to explore the sort of incremental improvements to HTML proposed by us at the workshop. I expect the resulting specs and implementations to play a significant part in the roadmap.

/be

Posted on

Action and Reaction

Miguel nails the key threats in XAML/Avalon/whatever: fancy graphics, widgets, and layout; easier XML-based authoring; better “managed code” model for when you have to hack; and a web-like deployment model with sandboxing for security.

The deployment model is a huge advantage over conventional app development. Web browsers and FlashPlayer have benefited from it, even as they’ve been held back by HTML and plugin stagnation. You can see Macromedia trying to escape the “plugin prison” now, and they’ve got a good chance of succeeding, thanks to FlashPlayer’s ubiquity.

The challenge for Mozilla and other open source projects is not to “react to Microsoft”, any more than it is to “react to Macromedia”. MS and MM are reacting to the same fields of force that govern everybody. The prize we seek is a better way to develop common kinds of networked, graphical applications.

People are using web standards to build web apps, and running into limitations in the deployed standards, and speedbumps in the standardization process. Other people are developing desktop apps using, e.g. Glade and GTK+, but wanting web-style deployment and even cross-platform portability. We should make it easy to do advanced, native-looking UI and fancy graphics in a web-like way, and portably.
This doesn’t require building an IDE, although who could object? The best case success story for any open source advanced layout/rendering/GUI-app platform would use the same network effects and low entry cost structure that helped the web explode to 5 billion or so public pages (but without the tag soup this time, please). People should be able to copy and mutate cool content. You should be able to edit by hand, even if the IDE generated the content, and have everything work (maybe your pretty formatting might even be preserved, what a concept!).

To make a difference on the web requires distribution, ideally in the form of support for new standards in all browsers including IE. That’s not going to happen with Mozilla code unless someone makes an Active X plugin out of Gecko, and distributes it widely. Fortunately, we have such a plugin. Distribution will be the hard part. But even without Mozilla, IE6’s behaviors (HTCs) allow a lot of extensibility. What if the minority browsers started incrementally improving HTML, DOM, etc. — and the emulation layer for modern IE were thin enough to download, if necessary?

Another requirement for web-like deployment of rich apps: a sandbox security model that allows trust to be delegated only to critical sections in the app. You shouldn’t trust a big pile of compiled C++ *or* compiled/interpreted JS/JScript/C#. Object signing is not enough — what’s need is a way to minimize the “trusted computing base” extensions, the critical sections in the app that actually need privilege. Also, those sections should automatically downgrade on exit (return from privilege-enabling method, e.g.).

I hope to blog more on these and related topics, as time allows.

Posted on

XUL box layout

I ran across an old posting from dbaron about how CSS’s 2nd generation still can’t do simple box layout needed for UI, which means that the web is full of hacky table tags. XUL box layout, which appears to be headed for standardization in the CSS working group, is a known solution that should be available to web app builders. Mozilla supports XUL, and Safari has XUL box layout support via CSS extensions.