Neil's Place

December 22, 2004

12:11 AM Things people don't understand - Part One

One thing people don't seem to be able to understand is the difference between attributes and properties of a DOM element. An attribute is a value set in the HTML/XML source using the form: width="60". In script, you can retrieve the value of an attribute using the getAttribute function. A property can be retrieved using the dot syntax such as element.style to get the style property of an element.

For various architectural reasons, in IE both attributes and properties are the same thing. There, you can retrieve a attribute using either the getAttribute or dot syntax, as there is no distinction made between them.

In Mozilla, this is (correctly) not the case. An attribute and property are distinct entities and may have different values. Also, an element may have a specific attribute such as 'width', but not have a corresponding 'width' property. However, it is often the case that such a property will exist and will just return the corresponding attribute's value. For instance, the XUL width property just translates to a call to getAttribute("width") to retrieve the width.

When retrieving the value of an attribute, Mozilla just returns the string that is stored on the element. When retrieving the value of a property, its value is usually calculated dynamically. In many cases, properties don't use any memory for the storage of values. For example, since the XUL width property just retrieves the value from the attribute, it doesn't store any value of its own.

Moreover, it is possible for an attribute to have one value, and a property with the same name to have a different value. There are several reasons. First, is that attributes are always strings, as they need to be serialized into source form. Properties may have any type, and frequently do. For instance, if the XUL hidden attribute returned the string "true" the hidden property will return the boolean value true.

In some situations, the values will differ. For instance, given an anchor in an HTML document (an A tag), someanchor.getAttribute("href") might return "nmain.css", whereas someanchor.href would return the absolute path "http://www.xulplanet.com/ndeakin/nmain.css".

But many people seem to assume that both attributes and properties are one and the same. Perhaps they are used to IE. The most common confusion lies in the textbox value (<input value="xyz">). The value attribute only specifies the default value of the textbox. The value property can be used to retrieve the current value in the textbox. Even if the user enters text into the textbox, the value attribute will remain the same as it was before.

If the value attribute needed to be changed every time the user typed something, this would likely cause a performance hit, as the code would have to copy the current value onto the attribute each time. This doesn't necessarily cause a problem for all implementations, but some may have issues with this requirement.

Comments ( 32 )

November 29, 2004

2:01 PM Mozilla MySql Support

Jan and I just added MySQL support to Mozilla's database component. It isn't part of the default Mozilla build, but you can compile it yourself, or use one of the XPI's, although they haven't been updated yet and seem to be broken links anyway.

I plan on writing some documentation on the component, but basically, it allows you to connect directly to a database. The component also supports a datasource for displaying results in a template or tree. Currently, the sql component supports PostgreSQL, MySQL and SQLite.

Comments ( 44 )


12:51 PM XUL Tutorial in French

The people at xulfr.org have just completed the French translation of the XUL tutorial.

Comments ( 6 )

November 22, 2004

11:16 AM Firefox party

On Saturday I went to my local Firefox 1.0 party. There were some organizational issues, for instance, the party organizer never showed up, but we still managed to get about twelve people. Among them: one of the guys from the Firefox Visual Identity Team, someone who was trying to convince his company to switch to Firefox (he said that Mozilla's JavaScript debugging tools saved his life), and a few folks who had just come from Penguin Day. No pictures though, but a good time was had.

Comments ( 24 )

November 17, 2004

Firefox fortune hunters
CNET's take on MozDev Group and similar companies

November 13, 2004

2:28 PM Minor XULPlanet Updates

Some minor XULPlanet updates today. Here are the changes to the tutorial and the element reference.

Also, the element reference is now available as a set of XML files.

Comments ( 8 )

November 6, 2004

12:40 AM My first usage of Thunderbird

So today I decided to try Thunderbird 0.9 for Windows. I've never used Thunderbird before since it doesn't work on my Linux machine. Of course, Firefox doesn't work either except for version 0.7. Unfortunately, I've reached my limit of dealing with gtk dependencies.

The first thing I noticed after running Thunderbird is that it didn't migrate any Mozilla mail, although it did seem to be smart enough to retrieve some junk mail from my mail server. So I imported mail manually. The second thing I noticed is that I can now search the entire message right from the toolbar. To do this:

  • Select Find In Message from the search dropdown.
  • Type some search text and wonder why nothing is happening.
  • Relize that you should have selected the similarly named Entire Message instead.
  • Type some search text and smile that it actually worked.

The third thing I noticed was that the attachment pane has been moved to a spot along the bottom of the window. Nothing wrong with that.

The fourth thing I noticed was that I couldn't find any of Thunderbird's new features. No RSS support to be found. No message grouping to be found. I found them eventually by looking them up on some online help pages.

There's one feature that neither Mozilla Mail nor Thunderbird have which I need. After using a mail client all these years, I find that the biggest problem I have is trying to find a message I looked at recently. There are various search features, but unfortunately, they require that I know something about what I am looking for. For instance, I can find a message containing 'I have put the mockups of the UI on the web site.', by searching for 'mockups' or 'UI'. However, the way one searches in applications by using keywords and building expression-like syntax using a bunch of fields and dropdowns isn't how anybody's brain actually thinks. Instead of thinking 'search for the word mockups', I would think, 'that message that had the screenshots'.

How could this be improved? By making a view of the messages that Thunderbird thinks the user is most interested in. It can do this by knowing that 95% percent of messages that someone receives aren't very interesting. How would it know which messages are the 5% of the interesting ones? By watching the user read their mail.

Chances are that if I look at a message for three seconds, it isn't interesting. On the other hand, if I clicked a link in the message, it was probably an interesting message. A variety of factors can be used. Did I scroll the message in a manner that suggested I was reading it? Did I move the message to another folder? If I replied to it, it may have been interesting, but chances are that I have already finished with it. And so on.

Neither Thunderbird nor Mozilla Mail track how many times I viewed a message, or when. I'm not so interested in when I received a message, but when I looked at it, since I'm far more likely to remember that. If I've viewed a message several times, chances are it's interesting. Why not have a recently viewed list?

And what about a view which combines all messages into one? Trim out the less interesting messages, and trim out all the quoted text and signatures, and you've got a nice compact display of text that is easily searchable with type-ahead find. What about a summary of all links in all my messages? What about a page containing all images?

Ooo, I can see those extensions now...

Comments ( 23 )

November 3, 2004

5:15 PM Mozilla Inline Spellchecking

Recently, Linspire released an update to their Mozilla product, which includes an inline spellchecking feature, among many other features.

The inline spellchecking feature adds the red underlines under mispelled words. It works in plaintext and HTML Mail composition, Composer and in multi-line HTML textareas. It will also work in anything in Mozilla that has an associated nsIEditor, which is actually anywhere where text can be edited, although it isn't initialized by default in single line textboxes, XUL <editor> tags and HTML pages with a designmode set. Here is a screenshot:

Since this feature is a much requested feature (it currently has 82 votes in the Mozilla bug), we have ported the patch to Mozilla 1.8, and posted it in bug 58612. Try it out if you like.

Some answers to questions that will be asked:

  • Will it be available in Firefox 1.0? No.
  • Will it be available as an extension? No.

Comments ( 29 )

November 2, 2004

11:51 AM XUL Template Analysis

Seth examines an issue he was having with XUL templates. His analysis and conclusion are close, but not quite right. He determined:

All the rules in a multi-rule template must use the same variables, no matter what they're matching. You can't add new variables after the first rule.

Actually, only the container and member variables are required to be the same in all rules. The container variable is the one defined in <content uri="?blah"> and the member variable is the one used in the uri="?fred" in the action. They both need to be the same variables in all the rules due to the manner in which the template builder connects the rules for rebuilding. (when the rdf changes, the builder only examines the parts of the rules that might be affected.)

Other variables besides those two can be whatever you want and can be different in every rule.

Comments ( 32 )