Tavs Dokkedahl sent in a great email about work that he and Allan Jacobs have done on bringing DOM event implementations to IE. Here it is in full:
About a year ago or so I put out the Uniform Event Model (UEM) script which
was an implementation of the W3C DOM 2 Event Interface for IE. As it turned
out that release was very premature - the script was simply incomplete and
definitely not ready for production use.
The design ideas however were good enough. Since then Allan Jacobs has
joined the JSLab team and together we have written a new version of UEM
which is much more stable and modular.
This first release includes support for:
DOM 2 Event Interface in IE
DOM 2 UIEvent Interface in IE
DOM 2 MouseEvent Interface in IE
DOM 2 Legacy keyboard handling in IE (fancy way of saying “handle it like
Firefox”)
The code is unobtrusive - no special syntax or semantics are needed. A lot
of documentation is available
There still exists issues with some types of events but at large the code is
stable and is performing well enough to be released to the public. Hopefully
we can get some feedback on how to improve it and catch some early errors.
The size of the script is about 32Kb (when minified) it its basic form but
additional modules are available for inclusion. The download page can be
found at http://www.jslab.dk/jdc.download.php
We are currently working on finishing the DOM 3 KeyboardEvent and DOM 3
textInput interfaces (for IE, Firefox, Opera and Safari) besides various DOM
corrections for other browsers than IE.
Sam Allen has done something that I was actually going to try to do… use browsers for a period and try to measure what happens to performance and such over that time period. Real usage. Normal usage.
These profiles are meant to provide a picture of what the memory behavior of popular browsers is over a period of time, not to provide absolute benchmark times. Firefox 3.0 shows memory usage that is significantly lower than Firefox 2, which also does very well. Here is a summary of my results.
Safari 3.1
Safari on Windows shows extremely poor memory management, and I do not know whether
it ever reaches a high water mark. If this is by design, it is certainly a design
that looks inefficient and seems to contradict Apple’s marketing.
Firefox 3.0
This browser exhibits memory usage that is by far lower than the others. It releases
memory to the system and the trend line is nearly flat.
(This is likely due to the
efforts outlined here.)
Flock (based on Firefox 2.0)
Flock did very well and this browser and Firefox 2.0 could likely be run for long
periods without causing many problems. The extensions probably reduced the efficiency
somewhat.
Opera 9.5
Opera’s performance was about as good as Firefox 2.0 (Flock), and it could likely
be used for very lengthy sessions. However, Kestrel is certainly not a revolutionary
or even notable technology in this arena.
Internet Explorer 8 Beta 1
IE did well in the profile, although a worrying trend in the data could indicate
that it would keep escalating. However, this browser could likely sustain many hours
of moderate usage.
Todd Ditchendorf keeps on pushing with Fluid, the Single Site Browser system that does so much more by giving you rich integration points. Ben and I demonstrated how we use Campfire as a Fluid application that ties us into Growl and more.
Single Window Browsing Mode (General Preferences). Actually this is more correctly called “TargetedLinksCreateTabs†and means that any website which attempts to spawn a new browser window will create a new tab in the current window instead. The user may still create new windows with cmd-N.
True Full Screen Browsing Mode. cmd-opt-F. (Window menu -> Toggle Full Screen Mode)
Change to Embedded SSBs. Now they can be made to obey your “Spaces Behavior†preference (appear in all or not). This is cool cuz you can set a different Embedded SSB in each Space for a different background in each. Unfortunately, this means that by default Embedded SSBs don’t work with Expose quite the way I have demonstrated. However, you can reclaim that Expose behavior by changing the Spaces Behavior setting to “Windows Appear in All Spacesâ€
Thumbnail Plug-in: Significantly improved load time/UI response time performance, when refreshing the current page to reload the thumbnails, the selected index is preserved, and adding built-in URL Pattern for Microsoft’s live.com search engine.
Also, I noticed a screencast that Todd did, showing TinyURL integration that gives you a context-menu to do what I just did with Endpoint, it resolves the URL for you. Very nice indeed. I was going to do a bookmarklet for it myself.
It has been a busy week for Mozilla. We have seen news across the board of their technology.
First we have the news that Firefox 3 should be available to download on June 17th. They are having a download party to kick things off.
Stuart Parmenter had a proxy post that delves into the world of fonts and text:
When Mozilla developers decided to incorporate the Cairo subsystem and build a new graphics layer from scratch, they also decided to completely rework the system that renders text in the browser.
Text is an incredibly important part of the Web. While graphics, audio, and video are increasingly common, we still spend the majority of our time on the Web just reading stuff. All the words you read in a web browser are rendered using a font which contains a set of glyphs used to form individual letters. For more simple written languages there may be a straightforward one-to-one mapping of characters to glyphs, but for more complex languages, one glyph may represent multiple characters.
Ben is a huge fan (a.k.a. anal) of this type of thing. Fonts and rendering can make a big difference, and the post goes into detail on what is going on in the new Firefox 3 engine. It discusses kerning, ligatures, hinting, font smoothing, anti-aliasing, and more. After reading this post you may want to watch Helvetica the movie!
Then we go to the mobile side, where Aza Raskin has posted concept video on the new touch screen interface that they will be building for Fennec. There is a ton of detail in Aza’s writeup including design principles:
Touch. This concept prototype for Firefox mobile (code name Fennec) is being designed for a touch screen. Why not multitouch? Because Firefox should be able to run on the least common denominator of touch devices. Especially for touch-enabled interfaces direct manipulation is key. Along that line of thought, the interface should be operable with a finger. Switching between input methods is time-consuming and annoying, so the user shouldn’t have to switch to a stylus or other secondary form of input. Firefox will work on non-touchscreen devices, but that’s out of scope for this demo.
Large targets are good. The same fingertip that controls the interface takes up between 1/5th to 1/10th of the vertical/horizontal height/width of the mobile touch-screen. In other words, fingers are fat: hitting small targets is like trying to touch-type with your elbow. All actions should be represented by targets that are large enough to be fast, easy, and (at the very least) not aggravating to hit.
Visual Momentum and Physics are compelling. Nothing shouts “sexy!†like pretty animations and a physics engine. Beyond marketing appeal, there is a strong argument that such physicality helps the user build a mental model of the interface, and that interface physics yields consistency. We are wired to track the movement of things and to be able to remember where they’ve gone, as long as they don’t appear and disappear, which doesn’t happen in the real world. Of course, copying every physical metaphors blindly gets you interfaces like the multi-million dollar blunder that was Microsoft Bob, so we need to select our metaphors carefully.
Typing is difficult. This means we want to minimize the amount of keystrokes required to get anywhere or do anything.
Content is king. With restricted screen size, every pixel counts. As much of the screen as possible should always be dedicated to content, not controls or cruft.
Then we move to the server side with a Weave status update that should be shipping with Firefox 3. It includes new features around data types, bookmark sharing, and a Web client view. Check out the Wiki for more details.
Bill Gates gave his last talk, appropriately, to developers at TechEd. No matter what you think of the guy, he is an icon that helped create the software industry. Without him and Steve Jobs, who do we have? :)
In his speach he talked about Internet Explorer, and how IE 8 will have an update in a couple of months:
Gates also highlighted Microsoft’s flagship Web technology, the Internet Explorer (IE) browser, which has been an asset and a curse for the company over the years. While it allowed Microsoft to secure its dominant position in Web-browsing technology, it also triggered Microsoft’s U.S. antitrust woes, something that haunts the company to this day. IE also has taken a hit in the past several years as Mozilla Firefox, an open-source browser, has gained a loyal following, forcing Microsoft to step up development and make its own product more innovative.
Gates revealed that beta 2 of the next version of IE, IE 8, will be available in August. He also stumped for what has been his pet interest during his years at Microsoft — natural human-interface technology that allows people to interact with computers in ways similar to how they interact with each other. Last week, Microsoft revealed that the next version of Windows, Windows 7, will include touchscreen technology, a fact he mentioned in his talked.
I have a funny feeling that we are going to see some really cool things to come out of IE 8. A few surprises.
Kevin Yank has zoomed into the features in the new Firefox 3 RC 1, and explained two subtle ones that can help us as Web developers:
Soft Hyphens
Tucked away in the list of CSS improvements in Firefox 3 is this innocuous-looking feature: “HTML soft hyphens () are now supported.â€
Soft hyphens are one of those obscure gems that HTML has always supported on paper, but that no one has taken any notice of because browser support has been spotty. With the imminent release of Firefox 3, however, soft hyphens will be supported by all major browsers including Internet Explorer, Safari, and Opera.
So, what is a soft hyphen, anyway?
A soft hyphen is a character of text that is usually invisible. It signals a spot in the text (usually in the middle of a long word) where it would be acceptable to break the line with a hyphen.
Here you see it at work:
Inline Blocks
Another obscure-but-useful new feature making its way into Firefox 3 after all the other major browsers support it (mostly) is the inline block. When assigned to an element, a display type of inline-block causes the element to be positioned inline (like a span), but the element’s contents are laid out as if the element were a block.
This feature will come in handy in a number of situations in which the float property is currently being used for lack of a better option.
Nicholas C. Zakas was doing some prep work for his new book when he delved into browser cookie restrictions for the big four browsers:
The most interesting fact I discovered is that Safari places no limit
on the number of cookies that can be set per domain. In fact, you can
set enough cookies on the client to cause a server error as the cookie
header can be too long to parse.
He also found out that:
Microsoft indicated that Internet Explorer 8 increased the cookie limit per domain to 50 cookies but I've found that IE7 also allows 50 cookies per domain. Granted, this may have been increased with a system patch rather than having the browser's first version ship like this, but it's still more than the 20 that was commonly understood to be the limit.
Firefox has a per-domain cookie limit of 50 cookies.
Opera has a per-domain cookie limit of 30 cookies.
Safari/WebKit is the most interesting of all as it appears to have no perceivable limit through Safari 3.1. I tested setting up to 10,000 cookies and all of them were set and sent along in the Cookie header. The problem is that the header size exceeded the limit that the server could process, so an error occurred.
So the prevailing knowledge that browsers limit per-domain cookies to 20 is no longer valid. Another interesting inconsistency is how browsers react when too many cookies are set. With the exception of Safari, which sets all cookies regardless of the number, there are two approaches:
The least recently used (LRU) approach automatically kicks out the oldest cookie when the cookie limit has been reached in order to allow the newest cookie some space. Internet Explorer and Opera use this approach.
Firefox does something strange: it seems to randomly decide which cookies to keep although the last cookie set is always kept. There doesn't seem to be any scheme it's following at all. The takeaway? Don't go above the cookie limit in Firefox.
The total size of cookies also varies from browser to browser. This is another one that is a little hard to comprehend, but here's what my tests show:
Firefox and Safari allow cookies with up to 4097 characters, that's 4096 for the name and value and one for the equals sign.
Opera allows cookies with up to 4096 characters, which is for the name, value, and equals sign.
Internet Explorer allows cookies with up to 4095 characters, which is for the name, value and, equals sign.
IEBlog has posted about the IE 8 support of postMessage, which is great news.
They link to a MSDN article that discusses the support, and a use case.
Jeff Walden noted that "the interface implemented by the current IE8 beta lags the HTML5 specification by several revisions in backwards-incompatible ways, so if you're going to experiment with this, be aware that what you're doing will break in a future revision of IE8." and detailed the differences.
It appears that only Firefox 3 RC 1 and Webkit Nightly have implemented the current spec.
Are child selectors slower than more simple brethren? This is a question that Jon Sykes sought out data for after he read the work of Jim Barraud.
His conclusion?
The skinny is that child selectors are a major performance issue.
This seemed to make sense, but to me I needed some sort of proof rather than just being told it's that way by someone, so over the last two days I've tried two approaches to see if I can replicate the issue.
The first one was rather a half-assed idea that afterwards seems fundamentally flawed as a benchmark.
The tests show that there is slow down using child selectors over direct class name declarations in IE6, IE7 and Safari 3. Safari 3 being the most impacted by child selectors. Firefox 2 has some impact, and Firefox 3 doesn’t seem to be impacted at all.
That said, this is a very extreme test, it is not often you’d have 20,000 class definitions in a single page or that all of them would use 4 levels of child selector.
If you 'aint got a URL scheme, you are a nobody. That is what I thought when I saw fx:// on the first day of JavaOne.
The newest one of these that I have seen is mountpoint:// which is part of an Opera proposal for a File I/O API in the browser. You know me, extending the browser is a bit of a passion, so I was excited to see what they had come up with:
Traditionally, web applications have had little to no access to resources residing on the local filesystem. The ECMAScript interfaces for file I/O specifies a sandboxed file system, where a widget or other trusted component can gain access to the local file system.
The File I/O interfaces in this specification represent an abstract filesystem, without knowledge of the underlying filesystem's path separators, conventions for setting file properties such as read/write permissions.
The interfaces provide methods for opening files, writing to them, creating files and directories, moving or deleting them, and so forth.
In order to work with files, an application first has to acquire a mountpoint. A mountpoint is either a reference to a file or folder on a disk, or an abstract reference to a set of files which might not necessarily be within the same folder.
If your application wants to use the File I/O API, the browser user will be asked to select a location for the virtual file system, and then you will have access to play in the sandbox.
The core interfaces are:
The FileSystem interface
In a context where the FileSystem interface is made available to applications, the interface is instantiated as opera.io.filesystem. When present, this object provides attributes and methods for acquiring access to files and folders on the local filesystem.
The File interface
The File interface represents objects in a virtual filesystem, and can represent either a file or a folder. A file object consists of a number of properties, and methods for working on these objects
File objects that are marked as persistent must persist across restarts of the application.
The FileStream interface
The FileStream interface represents a File object opened for reading and/or writing, and defines methods and attributes for doing this work.
After building a slide deck with Ben, you learn the art of a perfectionist. He would love Chris Hester's posting on button padding that shows you how your buttons look on various browsers and operating systems. Even been frustrated when you try to style things on the Mac?
Here are a few of his findings:
IE 6 and 7 apply extra padding to buttons with < 2px, but IE 8 doesn't
IE 8 and Opera add borders to all standard buttons if you zoom large enough
Padding on the standard buttons has no effect on Mac Firefox, and Safari on both Mac and Windows
Whenever I see a post on the IE Blog that has a title like IE and XP SP 3 I hope to see "oh, and IE 6 users will be upgraded". How much pain would be relieved when IE 6 usage is minimal?
Unfortunately, I was disappointed again:
XPSP3 will continue to ship with IE6 and contains a roll-up of the latest security updates for IE6. If you are still running Internet Explorer 6, then XPSP3 will be offered to you via Windows Update as a high priority update. You can safely install XPSP3 and will have an updated version of IE6 with all your personal preferences, such as home pages and favorites, still intact.
John Resig "doesn't think there's a single JavaScript developer who isn't excited about the new Selectors API specification (and the upcoming implementations)."
DOMElement.querySelectorAll returning incorrect elements
This is the most critical issue. As it stands DOM Element-rooted queries are borderline useless to libraries - and users. Their default behavior is unexpected and confusing. Demonstrated with an example, using Dojo:
He then asked other library authors if they agreed:
Andrew Dupont (creator of Prototype's selector engine):
My issue with this is that it violates principle of least surprise and bears no resemblance to the APIs in the wild.
Alex Russell (creator of Dojo's selector engine):
This is a spec bug.
Combinator-rooted Queries
I read about some prior discussion concerning this (especially in relation to DOMElement.querySelectorAll-style queries). This is an important part of most libraries, as it stands. Maciej's proposed solution of using :root to allow for front-leading combinators is perfectly acceptable to me (where :root is made equivalent to the element, not the document element).
This is something that a library can easily detect and inject.
Error-handling
I'm perfectly fine with the proposed try/catch solution however there must be a way of easily determining what the invalid portion of the selector was. Currently the following occurs in Safari:
alert(e); // "Error: SYNTAX_ERR: DOM Exception 12"
}
If there were extra properties to point to what the inappropriate selector was, that'd be fundamentally important. Probably the best solution (for both implementors and JavaScript library authors) would be to simply provide a character index, working something like the following:
