Neil's Place

October 28, 2004

10:39 PM The Complete Guide to Spelling my Name

About half of the people who contact me don't know how to spell my name. This is a guide to how to spell my name properly.

The following is the correct way to spell my name: Neil. Here are some incorrect ways: Neal, Niel, Neel, Niels, Niall

I know of about fifteen other people who are called Neil. I don't know anybody named Neal. Nor anybody named Niel. Due to some unscientific evidence I have seen, I think that the Neils outnumber the Neals fifteen to one. No one is spelled Niel. If you are, you're probably wrong. Or your parents were wrong.

My first name is pronounced the same as the word kneel. My last name (Deakin) is often pronounced wrong. Some incorrect pronounciations are: Dee-con, De-ay-con, Die-con, De-ay-kin, Die-kin, Rash-brook. The correct pronounciation is: Dee-kin ['di:kIn]

Comments ( 28 )

October 27, 2004

11:42 AM Mozdev Group is hiring!

Mozdev group is looking for a Mozilla developer to join us. Maybe it's due to the excitement over the upcoming Firefox release, but we're going to be really busy for the next little while with a variety of exciting new projects.

We've just finished up some projects, and soon, the results of this will be made available for general use, or will be provided as Mozilla patches and extensions.

Comments ( 11 )

October 7, 2004

12:38 PM More Slider Fun

I mentioned earlier that I was working on a slider widget. I wrote a spec for what I planned to implement, although I've only implemented part of it. I've been focusing on getting the slider to render using the native theme APIs. On GTK, this wasn't too hard. You can see an image of that in the previous post. On Windows, this turned out to be very difficult, and I haven't managed to succeed. I can get it to draw something that is slider-like but the size and position is all wrong.

I managed to create something that at least looks like a slider for the Classic (non-native theme) and Modern themes. However, it really is just a scrollbar with a small thumb, instead of a stretchy one.

So there's lots I would need help on:

  • Classic and Modern look which only needs a CSS or theme person.
  • Windows native slider
  • Mac native slider. The Mac native theme code looks to be the simplest of the platforms.)

Comments ( 29 )

September 27, 2004

Getting Started with XUL
Kurt provides a brief introduction to XUL

September 20, 2004

9:33 AM XUL Slider

There are a couple of XUL widgets which aren't finished yet, so they aren't documented on XULPlanet. One such widget is the <spinbuttons> tag, which is a textbox with two arrow buttons for adjusting the value. While there is some code for it, it is missing both images and code to do something when the arrow buttons are pressed. That said, finishing it is something that anyone with a bit of XUL knowledge can do, perhaps with a bit of help. (meaning, no C++ knowledge is needed.) If you'd like to help, let me know.

The other widget is the <slider> tag which allows one to select a value by sliding a thumb, much like a scrollbar. There is such a tag in XUL, however, it is really just a piece of a scrollbar, rather than a completed widget. The first step is getting it to look like a slider. I spent a bit of time with this, both with the slider code and the underlying GTK theme code. Here's an image, and I'd say it looks pretty good, and it works too.

I'll probably try a Windows version soon. The other problem is that the slider needs a few extra features to make it more useful as a slider, rather than a scrollbar with a different appearance. Most importantly is to display the current value in a label nearby. Not too hard, but the shared slider/scrollbar code assumes that the valid range always starts at 0 and ends at the value of the maxpos attribute. A minpos attribute could be added easily enough, but there are also cases where the slider might be used to choose a percentage, a decimal, or some other fixed set of strings.

Another common slider feature supported by other toolkits is showing tick marks along one edge. Unfortunately, GTK doesn't seem to support tick marks in its slider, so I don't think it's possible to make ticks theme-indepependant.

Comments ( 55 )

September 12, 2004

12:10 PM Examining innerHTML and custom attribute implementations

Someone asked a while ago if Mozilla supported 'expando' properties, which are an IE feature. I had some idea of what they were but I wasn't completely sure, so I went and looked at the MSDN documentation. Naturally, I left more confused than I was before. So I did some investigation of my own to see if I could determine what expando properties were. It turns out that an expando property is just a silly term for a custom property or attribute on an HTML tag. And Mozilla does support custom attributes and properties. It doesn't support the automatic mapping between attributes and properties as IE does, but that is done for all attributes, recognized or otherwise, so I don't think that's as relevant. Why was this extra 'expando' term created? It turns out to be due to an implementation detail in IE that makes such a term necessary. In Mozilla, such as term isn't necessary as we'll see below.

I decided to write up some examples of bits of HTML to see what happens in various browsers. In each case, I grab the innerHTML property of a form and display it, in an attempt to see what is being stored and generated. I start with this example:

<form id="simpleform">
  <input id="textbox" type="text" value="hello" accesskey="h" size="25" maxlength=40
         sun="20" rain=25 snow="yes">

Here is the result from various browsers:

Mozilla 1.7.1:

  <input id="textbox" value="hello" accesskey="h" size="25" maxlength="40"
         sun="20" rain="25" snow="yes" type="text">
IE 6:

  <INPUT id=textbox accessKey=h maxLength=40 size=25 value=hello snow="yes" rain="25" sun="20">
Opera 7.54:

  <INPUT ID="textbox" TYPE="TEXT" VALUE="hello" ACCESSKEY="h" SIZE="25" MAXLENGTH="40"/>

As you can see, there are very different results in each browser. Of course, since innerHTML isn't defined by any public specification, none are more correct than others, although some later examples will show various bugs that would seem wrong. Mozilla returns something similar to the original HTML except that the type attribute is moved to the end of the attributes. It shows the custom attributes in the same order as they were specified. Opera also returns the attributes in the order that they were specified, although they have been returned in uppercase. Opera drops all of the attributes that it does not recognize as valid for the input tag. Finally, Opera adds a slash at the end of tag as if it thought the element was XHTML, despite that the document is not. It's not even valid backwards compatible XHTML since there is no space before the slash. But anyway.

IE seems to return the id attribute first, followed by the valid recognized attributes in alphabetical order, followed by the unrecognized attributes in a random order. The attributes are mixed case, and the quotes have been left off of the recognized attributes, but added to the unrecognized attributes. Also, the type attribute isn't output.

What does this tell us? It tells us that Mozilla and Opera probably store the attributes of an element in an array, as they are returned in the same order as they were specified. During parsing of the HTML, each attribute is appended to end of the array. From the way that the attributes are displayed in IE, we can assume that the attributes are stored in an object, presumably of the interface IHTMLInputElement. The innerHTML implementation goes though the interfaces supported by the element, takes the value of each property and outputs it. This is supported by the mixed case of the accessKey and maxLength attributes, as if they were the property names in the interface.

Here's where the 'expando' feature comes in. Since interfaces like IHTMLInputElement can't support anything but the properties that the interface has been defined to have, custom properties need to be done in a special way in IE. Judging from the random order in which they are returned, I'd imagine the expando properties are stored in a hashtable in a private property somewhere.

Since Mozilla just stores all attributes in an array, it doesn't need to distinguish between known and unknown attributes, and thus, doesn't have a special term for it. Which is why I had trouble understanding them, since I didn't think that they were any different from normal attributes. That explains expandos, but while investigating I found a number of interesting things about the innerHTML implementations of the browsers.

Note above that IE doesn't return the type attribute. Why is this? This is because the value is set to the default value. If you changed the type to 'password', it would be displayed in the innerHTML. This also applies to all other recognized attributes. The following example shows this:

<input size="20">

This example will display '<INPUT>' in IE, since 20 is the default value of the size attribute. The innerHTML implementation assumes that any attribute set to the default value means the same as an attribute that was not specified. This is probably because the size is stored in an integer field in the class, and there is no way to store a null or unspecified value in an integer field. Mozilla and Opera can handle this case as an unspecified attribute will not be in the attributes list, whereas one set to the default value will be in the list. The last example will be returned with the size attribute included. (The default size in Mozilla and Opera is 25 however). I don't know why the type attribute is returned last in Mozilla, nor why the value is converted to uppercase in Opera. Possibly an optimization for some purpose, as only the type attribute works this way.

Another example:

<input value="hello" value="goodbye">

The above example will show that Opera, while disallowing unrecognized attributes, doesn't remove duplicate attributes. Both value attributes will be returned in the innerHTML, which suggests that Opera doesn't check for duplicates when parsing attributes. Mozilla does check for duplicates however, and only the first value attribute (with the value 'hello') will exist. However, getAttribute will always return the first value in all three browsers.

Note from earlier that IE doesn't put quotes around the known attributes. It suggests different code is used for recognized and unrecognized attributes. Let's see what happens here:

<form id="simpleform">
  <input value="hello and goodbye">
  <input size="25 and 30">

In this case IE does put quotes around the attribute when there are spaces in it. Also, all three browsers parse the size attribute as 25 and ignore the 'and 30' part. Also, I note that IE doesn't add linebreaks between the tags, whereas Mozilla and Opera do. Let's see if we can break the attribute serialization.

<input value="hello " and goodbye">

Mozilla 1.7.1:

  <input value="hello " and goodbye">
IE 6:

  <INPUT value='hello " and goodbye'>
Opera 7.54:

  <INPUT VALUE="hello

Mozilla leaves the entity intact, or escapes it again on serialization. IE notices the quote and switches to using single quotes around the attribute. Opera notices the quote and appears to just give up. In fact, Opera will give up completely and return immediately, even if there are other tags to serialize.

Comments ( 17 )

August 27, 2004

8:04 PM Template Languages

There's been some discussion lately about how to improve XUL templates. I just added some comments about this.

Some proposals include using an SQL-like language which generates results. This is suitable for database-backed data, and a query language for RDF is being developed. Others talk about using XSLT since it's already an established template language, although it would only work using XML. Another option is to simply improve upon the existing template system by adding support for conditions, better scripting, and so forth.

For my purposes, I had created ReoPath, which is more closely related to XAML or Flex databinding than any other possibilities. Currently, its design is fairly simple and lacks some features such as recursion, although the eventual goal is to have a number of additional features to do rules, updates based on events, as well as use a better binding syntax.

Despite some progress, I think that everybody has very different ideas about what direction templates and databinding in XUL should be headed towards, so it may be difficult to create something that is easy to use, easy to learn, allows lots of features and is efficient.

Comments ( 31 )

August 17, 2004

7:07 PM Netscape Toolbar

Looks like the Windows version of Netscape 7.2 includes the new Netscape Toolbar. I hear it was developed by some brilliant programmer. I wonder what other exciting things will be available soon?

Comments ( 34 )

August 16, 2004

6:56 PM XUL Tutorial Translations

There are a couple of translations of the XUL tutorial that I know of. There's a French version and a Russian version. If you are translating the tutorial, you might be interested in recent changes. Also, there are changes to the element reference. Let me know if you'd like to be notified of changes in the future.

Comments ( 36 )