March 21st, 2008
There was an interesting post the other day which criticized Safari's choice to completely overhaul their event system and, in the process, seemingly cripple the keypress event for non-character keys.
At first glance to me, and to many others, it appeared as if a dramatic flaw had been introduced into Safari's event system - completely castrating its practical use. It was at this point that I contacted Yehuda Katz (Merb and jQuery contributor) - he knows more about the inanity of cross-browser keyboard events than anyone I know. Here's his responses to a few questions that I bounced off him:
John: At first glance through WebKit's changes it appears as if they've significantly crippled the keypress event, is this the case?
Yehuda: People should not have been using the keypress event to get the character that was pressed. That's because the keydown event only provides information about the actual key that was pressed (the A key, the right arrow, etc.), but does not tell the user what character will get added to (for instance) an input box.
Since arrow keys do not get added as text, keydown provides all the information that is needed. There were a couple of quirks with using keydown in certain cases previously which are resolved by their changes that prevent keypress from getting called if keydown's default handling is blocked.
What this means is that if people were using keypress before (and relying on Safari's native results for arrow keys, such as 63232), their code will break. However, this was a bad idea all along; people should use keydown to detect and block non-character keys. My mantra has always been: keydown/keyup if you want to know the key that was pressed; keypress if you want to know what text was detected.
John: Being able to access non-character keys must be useful - granted Safari gave strange results previously - but at least some value is better than none, right?
Yehuda: The keypress event does not provide any additional benefits over keydown for these non-character keys. Keep in mind that IE does not fire the keypress event for some non-character keys (e.g. delete, end, enter, escape, fkeys, etc.).
Because Safari appears to have fully resolved issues with suppressing default events from keydown, there should be no problem with using keydown for non-character keys.
John: So we have charCode, keyIdentifier, and keyCode along with keyup, keydown, and keypress - is there a solution that we can safely use in a cross-browser manner?
Yehuda: There's a reasonably good writeup at: http://unixpapa.com/js/key.html.
Effectively, you can use e.keyCode for all modern browsers in keydown/keyup (although you'll need to consult the chart at the bottom of that page to determine whether the keyCodes returned by the browsers are consistent).
For keypress, e.charCode || e.keyCode should work (Mozilla and Safari define e.charCode, while IE defines e.keyCode which returns the ASCII value). What that means is that you have a close-to-cross-browser keyCode for keyup/keydown and a pretty reasonable charCode for keypress.
As a result, keypress can be used for key events that produce text for which you need to know its ASCII value (A vs. a). keyup/keydown can be used for events for which you care about the physical key that was pressed. Again, there are some quirks, which can be summed up in the tables at http://unixpapa.com/js/key.html.
I'd like to thank Yehuda for taking the time to clear these points up. Effectively if you were doing key-related development, previously, in a non-cross-browser manner then you hit a wall with this recent change. If nothing else this should encourage you to keep a good separation, as Yehuda notes: "keydown/keyup if you want to know the key that was pressed; keypress if you want to know what text was detected."
Tags: safari, javascript, dom, events, webkit
9 Comments on 'Keypress in Safari 3.1'
May 4th, 2005
One of the on-going jokes amoungst my friends is that the 'has to be' at least one festival every weekend here in Rochester, NY. So, the other day I sat down and tried to find every one that, at least, mentioned 'fest' or 'festival' in its name. Now, this is good, however kind of useless only providing links to them from my web site. I re-visited one of my favorite web sites Upcoming.org and proceeded to add all the festivals (that I found) into there. Links to those pages can be found here:
Rochester Summer Festivals
More Rochester Events
While I was doing this, however, I realized that the whole process of adding events was really slow and annoying. This gave me a chance to explore a tool that I had been meaning to use: Webscrape. It's an easy-to-use Perl/XPath web page scraper that really speeds up the whole process. This led me to create two scraping applications for people to use:
Rochester Event Scrapers
I will probably do a separate post dedicated to Webscrape here soon, as I really enjoyed using it.
Tags: newyork, events, ny, rochester, festivals
1 Comment on 'Making Rochester Events Usable'
March 30th, 2005
I just signed up for the brand-new evdb to see what it's like (there's been quite some hype surrounding it. However, I was sorely disappointed. Below is a copy of the email that I sent to their 'bugs' email address, notifying them of the problems.
And now that I think about it - there's no way to make a friend's only event - or even add a friend! What's the point of this, seriously... At this point, Upcoming.org is much better off.
P.S. Plus they use tables! And there's barely any dynamic content... very, very poor show!
Hello,
After a quick run through, a few things;
- There is no way to make a strictly private event.
- There is no way to delete an event, once created.
- There is no way to edit an event, once created.
- There is no mechanism for having re-occurring events.
- When creating a new event, there seems to be some tag left un-closed causing all the items to shift right (in Firefox 1.0 on OS X 10.3). (See bug1)
- There are a lot of problems with selecting a time for an event, just some:
- The 'Ends' checkbox starts unchecked, but the 'ends' field items are enabled.
- When the 'Ends' checkbox is checked, the background turns green. (and the end time stays enabled?) (See bug2)
- When the 'Ends' checkbox is unchecked, the background turns red. (See bug3)
- When the 'Ends' checkbox is checked again, some of the form items are left disabled. (See bug4)
I hope this can help to lead you guys in the right direction, thanks!
Update: And here's their reply - very fast! I'm pleased that they're working on everything. My hopes for this application have risen.
John,
Thanks for the feedback. We're working hard to get all of these issues addressed as soon as possible.
Here are some specific comments:
- There is no way to make a strictly private event.
For the immediate future, we are working strictly on public events. But we definitely see the urgent need for private events/calendars, etc. Stay tuned for further developments. This is my wife's top wish-list item, by the way.
- There is no way to delete an event, once created.
Yes - we'll have this soon. It's implemented on the back-end - it's just waiting on the UI side.
- There is no way to edit an event, once created.
Yes - this is a major one - we're going to have full editing capabilities. Also, if you wish, you can open it up entirely, wiki-style to allow the world to edit as well.
- There is no mechanism for having re-occurring events.
Yes. Doing recurring events completely right is pretty hard. You need to handle the "every thursday except Thanksgiving and Christmas weeks" case, for instance. But we're all over it and should have good tools for handling that pretty soon.
- When creating a new event, there seems to be some tag left un-closed causing all the items to shift right (in Firefox 1.0 on OS X 10.3). (See bug1, attached)
We'll have a look at this. You're the first to report it - thanks.
- There are a lot of problems with selecting a time for an event, just some:
Time handling is currently pretty lame in my opinion. I'm personally working on this one. My goal is to have this as fluid and straightforward as programs like iCal do, within the limits of a web browser.
We'll be updating things regularly, and these are all on our to-do list. I can't promise any specific timetable, but we're working on them.
Chuck
Update: Most of the afformentioned problems have been resolved now - they certainly moved quickly!
Tags: social, events, evdb
4 Comments on 'EVDB, First Impressions'
