There has been a lot of griping on the localization groups about the lack of locale-switching UI, but I never saw a working extension for Firefox PR (coupled with the fact that my chrome registry bug means it wouldn’t work anyway). So I whipped one up. Check it out.

RDF has been touted as the data model to model all others; the way to represent all metadata on the web. For those of us who are “architects” at heart, this is an extremely attractive proposition. The problem is that it is destined to fail, for technical and human reasons.

Let us examine the technical issues first. What are the chief advantages claimed by RDF?

• Extensibility: RDF graphs can represent any data concept if there is an appropriate schema, and anyone can create a schema without conflicting with other schemas
• Aggregation: RDF can combine information from multiple sources, to combine and enhance knowledge

The technical problem is that you cannot achieve both of these goals at the same time. Any RDF aggregator must understand the data schemas being used, or the aggregation is worse than useless. For example, imagine two RDF graphs, both containing a sequence:

r:foo rdf:_1 r:obj1
r:foo rdf:_2 r:obj2
r:foo rdf:_3 r:obj3
r:foo rdf:type rdf:Bag

r:foo rdf:_1 r:obj1
r:foo rdf:_2 r:obj4
r:foo rdf:_3 r:obj5
r:foo rdf:type rdf:Bag

The logical aggregation of these graphs is:

r:foo rdf:_1 r:obj1
r:foo rdf:_2 r:obj2
r:foo rdf:_3 r:obj3
r:foo rdf:_4 r:obj4
r:foo rdf:_5 r:obj5
r:foo rdf:type rdf:Bag

However, let us imagine the same graphs, except that r:foo is now a Sequence instead of a Bag:

r:foo rdf:_1 r:obj1
r:foo rdf:_2 r:obj2
r:foo rdf:_3 r:obj3
r:foo rdf:type rdf:Seq

r:foo rdf:_1 r:obj1
r:foo rdf:_2 r:obj4
r:foo rdf:_3 r:obj5
r:foo rdf:type rdf:Seq

The logical aggregation of this graphs keeps a “r:obj1” in the graph twice, because a Sequence is order-sensitive:

r:foo rdf:_1 r:obj1
r:foo rdf:_2 r:obj2
r:foo rdf:_3 r:obj3
r:foo rdf:_4 r:obj1
r:foo rdf:_5 r:obj4
r:foo rdf:_6 r:obj5
r:foo rdf:type rdf:Seq

There are, of course, much more complicated examples, and there is frequently room for multiple interpretations of how to aggregate the same data. The basic point is that given a set of graphs, an automated tool cannot make an intelligent aggregation if them without understanding the schemas involved. This means that RDF is really either extensible or aggregatable, but not both.

Secondly, and much more important, is the human factor involved in metadata. It is a basic fact of life that what is not seen, is not updated. Web authoring tools like NVU know this, and so they prompt you to enter the <title> of a page when saving it. This makes the invisible visible. RDF has no visual representation, by design. It is intended to be processed by automated tools (of unkown type) for an infinite variety of purposes. This means that humans never see the metadata, and will therefore never maintain the metadata.

The obvious solution to this problem is to make the metadata visible. So what we really need, say the RDF aficianados, is a data-browser. This browser will allow you to “surf” the metadata of the web, just like the web browser of yester-year allows you to surf HTML. This is a fine idea, except that nobody has apparently tried to integrate this “metadata browser” with an actual browser. Unless you do that, you are doomed to niche or non-existent adoption, and all the fancy theories in the world are useless.

So what’s the solution? My solution is simple: extend the HTML <link> and <a> tags with additional profiles (a la XFN), so that metadata is attached to visible entities if possible. Define a standard so that RDF can be embedded in the HTML head element, and brainstorm some extensible rendering framework so that browsers can actually display RDF metadata.

This was, I believe, one of the original inspirations of the RDF/Aurora code in Netscape 6, which was quickly swallowed by extreme and bizarre demands that RDF define the UI of the Netscape browser. Since we are now agreed that RDF was generally a mistake as a general-purpose data-binding language, and we are revamping the XUL templates to work with simpler XML/JS/SQL data, we can actually work on a real intertwingular metadata browser tightly integrated and extending the basic functions of the HTML browser that have been so universally successful.

I have created a spec that extends CSS a little bit, allowing for more advanced backwards compatibility by surrounding new/perhaps-unsupported CSS rules with an at-rule. Read it here, let me know what you think (this was also announced on www-style).

Here are a few more screenshots, after discussion with mconnor and a few other devs. They are in my opinion, and others I’ve heard, the most pleasing to the eye, and integrate fairly well with the browser chrome:

A web application with minimal chrome would look like this (for example, when launched with the -chrome flag of xulrunner, or window.open()ed with all the features disabled:

After I prepared these screenshots, Firefox went back to forcing the status bar instead of the location bar. So maybe the site information/context menu could be under the content, instead of over it. The border is still necessary, to delineate where the untrusted content actually is.

In addition, it would be good to allow untrusted web apps to do more with UI, but users should always have the option of disabling these:

open modal windows
hide context menus
perhaps even block leaving a page

See bug 248207 for some more history/discussion.

I think the essence of my last post was lost in the screenshots. In particular, I am painfully aware of doron’s point that users don’t care about security. That’s not the point of this exercize. Instead, the point is to make sure that web content cannot be mistaken for browser chrome. This must involve (IMO at least) some sort of border around unsecure content. You can’t possible put a trustable border around all the browser chrome, but you can put a trustable border around untrusted content. Whether or not users actually read the security info is unimportant. You no longer have the opportunity to spoof the master password dialog.

There has been a long and wide-ranging discussion about UI spoofing in browsers (and of course Mozilla/Firefox in particular). Basically, bad-boy web content can pretend to be the location bar, the status bar, or other browser UI, and attempt to steal privacy information. The basic problem is covered in bug 22183. This is a problem that affects all browsers, since UI can be spoofed with simple images; however, it is easier in browsers that support XUL, since remote XUL tends to look the same as trusted browser XUL.

Gerv originally proposed a solution that always shows the status bar. This was deemed insufficient. The solution in place for Firefox 1.0 is to forbid untrusted websites from hiding the location bar (the URL bar). Here are the good reasons:

• Keeping the status bar open isn’t enough, because it is easy to push the status bar off the bottom of the screen (and hard to prevent).
• If you can see the location bar, it is pretty obvious what website you are visiting, and we make it even more obvious for secure sites by singling out the domain name from the certificate and displaying it prominently.
• The UI is discoverable. People use the URLbar all the time, they actually do get into the habit of looking at it. They know how to use it.

The disadvantages are not quite as obvious, and mainly have to do with enterprise applications: the location bar is large and can destroy the appearance of enterprise apps that open “dialog” windows and other small-UI windows. This is very important if Firefox is going to make inroads in corporate environments maintained by dedicated system engineers, and in many academic settings such as computer labs.

I have been thinking about this for a while, and read a lot of proposals, most of which were damn-ugly. But the core concept was good. Basically, the browser must delineate, obviously and discoverably on screen, between content from different security levels. It is not simply enough to say “the content below this line is untrusted” because you don’t know where the line ends. Instead, you need to wrap the untrusted content in a box, so that you know where it ends. Secondly, the UI has to be consistent. You can’t show one UI when it’s a chromeless window and a different UI when you add the chrome, or else users don’t know where to look for security information, and will not get accustomed to any solution. To this end, I have produced the following mockup images for your consideration:

The third example shows the problem with this approach. When you start adding back the browser chrome, it gets ugly quickly. The transition between the yellow and grey in the tab browser is harsh.

The status bar solution has all the problems listed above, but looks a lot better. Note that all of the status bar widgetry isn’t there, because this is a mockup. Use your imagination.

In combination with a tab browser, none of these solution are especially beautiful, at least yet. I’ll keep playing.

While googling using site-specific searches (trying to find out what glazou meant about “rainbow”) I quite by accident found http://directory.mozilla.org/, which redirects to http://www.dmoz.org/. What is it? Why is it there?

Somebody needs to explain why we’re getting rid of the JS console and View Source from default Firefox builds (they will be available in the “Custom” install option). Comeon, even Internet Explorer has view source!

If a mouse fails to operate or performs erratically, it may need a ball replacement. Mouse balls are now available as FRU (Field Replacement Units). Because of the delicate nature of this procedure, replacement of mouse balls should only be attempted by properly trained personnel. Before proceeding, determine the type of mouse balls by examining the underside of the mouse. Domestic balls will be larger and harder than foreign balls. Ball removal procedures differ depending upon the manufacturer of the mouse. Foreign balls can be replaced using the pop off method. Domestic balls are replaced by using the twist off method. Mouse balls are not usually static sensitive. However, excessive handling can
result in sudden discharge.

Upon completion of ball replacement, the mouse may be used immediately. It is recommended that each technician have a pair of spare balls for maintaining optimum customer satisfaction. Any customer missing his balls should contact the local personnel in charge of removing and replacing these necessary items. Please keep in mind that a customer without properly working balls is an unhappy customer.

Open standards cannot effectively compete with Microsoft XAML and other closed technologies for large market share without a good set of developer tools that make authoring and developing easy (or at least easier). Visual Basic 5-6 were limited and inefficient programming platforms, but were wildly popular simply because developers could drag/drop/insert UI and it would just work. Microsoft Access data applications have much the same appeal. If XUL is to compete with these closed technologies, it needs to have a good GUI editor. The mozilla2.0 team is acutely aware of the problem, but nobody has yet stepped forward to lead the charge.

I spoke briefly with Daniel Glazman about possible UI ideas for a GUI XUL editor, and how it might relate to the fantastic work that he is doing on NVU, the next-generation HTML editor. After a little bit of playing, it is obvious that the editing model for XUL would have to be very different from HTML.

One of the primary factors involves the selection model. In HTML, you select text in a mostly-linear fashion to edit it. Even floats and other out-of-line objects have their own little “flow”. This is simply not the case for XUL, where you must think in terms of boxes and flex, fitting to the available/desired space. In XUL editing, your “cursor” may be vertical or horizontal, and has a limited scope in the current containing box. Once you escape the immediate containing box, your cursor switches orientation from horizontal to vertical (and vice-versa).

I did a basic playground stylesheet with a simple XUL file, and created a special element <edit:cursor> which would act as a “heavy” cursor. What I want to do is steal large parts of DOM inspector code, so that there is a tree sidebar which matches the GUI view.

I found a few places where I need/would really love additions to core gecko… somebody please tell me how hard these are:

1) parse entity names with a special DOM element, instead of expanding them to text. This is pretty much a requirement to do large-scale apps that localize appropriately using the chrome registry

2) a :-top-hover selector. I need a selector that only matches the topmost hovered element, not every hovered element.

3) a -moz-min-margin rule… I can work around this if necessary, but in order to give space between boxes for drag-n-drop and other activities, I would like a -moz-min-margin: 4px rule applied to *.

Did I just volunteer for something? I hope not ;)