Neil's Place

February 28, 2003

9:58 AM True...

XUL and JS are the best development platform ever in a browser environment. - Daniel Glazman

Comments ( 6 )

February 27, 2003

4:45 PM How odd

Mysterious <blink> tag detected on W3C Style page (under the heading 'What are style sheets?')

Why not at least use text-decoration: blink, I wonder?

Detected while searching for proposed CSS3 specifications, which I can't seem to find links to any more.

Comments ( 36 )

February 24, 2003

8:11 PM Moby on software

... the software companies are making it so difficult for us to be ethical and do the right thing that in the future we should probably just use pirated copies. - Full Post

Comments ( 3 )

February 21, 2003

11:35 PM The many sides of browser undo

It seems that there is quite a difference in how the Undo command is handled in various browsers.

In Mozilla and in Opera 7, each textbox has a separate undo buffer. If you start typing into one field and then type into another field, you can undo each separately. Choosing Undo from the Edit menu or pressing the Control+Z shortcut undoes the last change made in the currently focused field. Switching to another field allows one to undo the changes made in that field instead. The address bar and fields in dialog boxes function in a similar manner.

Both Mozilla and Opera provide an Undo menu on the Edit menu, in the context menu for textboxes and Undo is performed when Control+Z is pressed. Both browsers also support the Redo command, which redoes a previous undo operation. Mozilla provides the Redo command on the Edit menu, the context menu, and supports the Control+Y shortcut. Opera doesn't have Redo on the menus but does support the Control+Y shortcut.

Both browsers support multiple steps of undo, which means that choosing to undo several times undoes each successive change before. You can redo multiple times also. This is supported on all fields.

The Windows version of Netscape Communicator supports Undo on textboxes, and supports it separately for each one. Making a change to one field doesn't affect the undo buffer for another. The Undo command is not on the Edit menu, but is available on the context menu and the Control+Z shortcut works. However, only one level of undo is available. Selecting to undo a second time just undoes the undo and goes back to the original state, which is the equivalent of what Redo does on Mozilla and Opera. There is no Redo command and the Control+Y shortcut does nothing in Communicator. I think that this is the normal behaviour of Windows textboxes.

The Linux version of Netscape Communicator is unusual. There is an Undo and a Redo command on the Edit menu, but they are always disabled. Editing a textbox doesn't seem to enable them, which makes me wonder why the commands are there. Netscape Mail 4.x has an Undo command that works in the message area, but no Redo command. There is also an Undo command in the Edit Bookmarks window which can be used to undo the deleting of a bookmark.

The Windows version of IE (5.5 and 6.0) doesn't have an Undo command on the Edit menu, but it is available on the context menu and the Control+Z shortcut works. The Redo command is found neither on the Edit menu nor the context menu, but the Control+Y shortcut can be used to redo.

Unlike the other browsers however, IE only supports one undo buffer per window. If there are two textboxes in a window and text is entered in the first and then in the second, the Undo command reverts the second textbox. Pressing Undo a second time, switches the focus to the first text box and reverts it. The Redo command is similar but in the opposite direction. Since this undo buffer is for the entire window, this will also apply across multiple frames. The behaviour is different from Mozilla and Opera as they handle undo separately for each field.

However, the IE address bar works differently. It has a separate undo buffer that does not support multiple levels of undo. Instead it works more like a Windows textbox (like in Netscape Communicator). Selecting to Undo a second time reverses the undo. There is no redo command for the address field.

Here comes the nasty bit which prompted me to write this piece. In IE, if you have a script which changes the document in any way, either using DOM functions, setting the innerHTML property of any element, or simply by changing the value of a form field (but not by making style changes), the Undo buffer is immediately cleared. Let me state that again: Changing any part of the document in IE using a script clears the undo state so that the user cannot undo any previous changes.. Thus, if you change the document in some way in a key event handler (onkeydown for example), the Undo command becomes pretty much useless. Watch out for this issue if using a textarea where the user might be entering a longer section of text (such as WebMail message or Forum post). Here is a test you can try yourself.

Well that's all the browsers I have available for checking right now. I'd be interested in knowing how various Mac browsers work since I don't have access to a Mac right now.

Comments ( 7 )

February 20, 2003

10:06 PM Fixed the layout

Who would have thought that the layout in IE was messed up because of a 2 pixel margin? It's fixed now.

Comments ( 29 )

2:53 PM Moved Down

Hmmm. It seems that the link to is no longer the first result returned when one does a Google search for 'Internet Explorer 7' as it used to be.

Comments ( 9 )

February 19, 2003

11:34 PM XUL tutorial

Minor updates to the XUL tutorial and reference made. Planning to write a couple of additional sections which I feel are missing still. Won't get to that for a bit until at least after a quick secret project I'm doing on the side is complete.

Comments ( 6 )

February 17, 2003

10:41 PM XUL and the performance thing

There are a number of people on various Mozilla forums that seem to be under the impression that any performance problems in Mozilla are caused by XUL. I'm not sure why they have this impression. I suspect that they see the various text files used and assume that they must take a long time to load and parse. I suspect, as with many people that complain about performance or resource issues, that they don't actually understand how other systems work. Here is a description of what happens when a window is opened in Mozilla:

XUL, scripts and other files are read from the JAR archive files in Mozilla's chrome directory. They are interpreted and compiled and a post-processed version is stored into a binary file (the fastload file) and saved to disk. This step is only done the first time you ever open the window -- the binary file is used from then on.

Since that step is not repeated again, the following is what happens every time afterwards:

What happens when a window is opened in Mozilla

When a window needs to be opened, the widget definitions and the layout of the window is loaded from the binary fastload file. The UI toolkit constructs objects for each item from the fastload file. Those objects, along with the toolkit, determine how to place themselves on the window. The UI toolkit calls drawing commands (line drawing, image drawing, etc...) to draw the elements to the screen.

Now let's look at what happens in other GUI systems, such as Windows 3.0 and every version after it, on all versions of the Macintosh, in Visual Basic, and Delphi, and in many other UI toolkits.

Click this button and note the differences in the paragraph above.

Note the similarities?

It should also be noted that Mac OS X applications also store their UI's in various external files, some of which are plain text files (or XML files), which get interpreted when needed. And how many people have you seen complaining about how slow Safari or Chimera are?

There are no "extra layers" as some are fond of mentioning. XUL widgets are read from a file as other systems do and are placed and drawn using low-level drawing functions. Where are these extra layers these XUL detractors often mention? I don't see them.

The truth is, there is no architectural flaw in the design of XUL that would make it slow, as it doesn't really operate any differently from other GUI toolkits or native UI systems. Thus, if it is the XUL component that causes any performance issues, they should be fixable over time, since the issue isn't a by-design issue, but an implementation specific one.

What I mean is that one could construct a different implementation of XUL that used all of the same file formats, but faster, since XUL's design is not fundamentally different from other UI toolkits in terms of how it loads content.

Here is a test to see if Mozilla takes too long to start:

  • Count the number of seconds Mozilla takes to start up. Multiply by the number of times you might start it in a month.
  • Count the number of seconds (or minutes) it took you to write lengthy rants about Mozilla's performance over a month long period on the newsgroups.

If the second value is greater, you obviously have lots of time. If the first value is greater than you have realized that 5 seconds of your life each day isn't worth getting stressed out about.

Comments ( 2 )