Month: January 2003

Basil writes some thoughts on acoustics in orthodox churches and mentions an excellent article by Reader David Nelson. I found this nice HTML version of the same article, Acoustical Guidelines for Orthodox Churches. Acoustical design can significantly impact Orthodox worship. Without proper care, the clarity of the speech and chanting will be lost and noise will be a distraction.

I’ve found it fascinating to read similar articles about the importance of acoustics in the Jewish Synagogue and find that most of the same design requirements apply.

Synagogue Acoustics: “Shema Yisrael (Hear, Israel) strongly implies that acoustics is fundamentally important to the design of Synagogues.… A pleasant sound and good speech intelligibility are blessings that will make the experience of the worship service more enjoyable, and create a precious opportunity to hear the human voice partaking in that most human activity, prayer.”

One thing I hadn’t realized is that electronically amplified sound is not permitted in the Orthodox Synagogue on the Sabbath. This has led to innovative solutions such as the Acousto-Fluidic Sound Augmentation that may produce better sound: “An interesting advantage of acoustic augmentation over electronic amplification is the fact that the entire process occurs at the speed of sound rather than at the speed of light. In our system the sound travels through the sound pipes at the same speed as the voice in air so that the sound coming out of a speaker arrives at the same time as the spoken voice or the outputs of nearer horns and, as a result, there is no bothersome echoing. Using an electronic system one has to specially design in time delays to prevent echoing. Consequently the acousto-fluidic system provides a very natural sound and rendition.”

Silence is Golden: “Some times we don’t want to hear everything. Imagine if you could hear and understand every conversation at your office. It would be terribly distracting. But when we do want to hear every little thing—at a religious service, in an important meeting, at a play, or at a concert—background noise is critical. During a lecture or sermon, any audible sound not made by the speaker is noise; during a performance, any audible sound not created by a performer is noise.” This general article about accoustics identifies many sources of noise. Ones that will most affect us at St. Athanasius are traffic noise, air conditioning, and buzz / hum from lights.

David Hyatt discussed in more detail why Apple would chose KHTML over Gecko as the engine for the Safari browser. Unfortunately it has been taken down now. John Gruber apparently saw it, too, and quotes the following snippet over on his Daring Fireball site:

Imagine that your number one priority for a browser is speed. You want a browser that launches almost instantly. You want a browser whose page load peformance can be improved dramatically. This is your number one goal, because you want to address what has been a fundamental problem on your platform (OS X) ever since it was launched: that no browser has accomplished the goal of fast startup and fast page load. Your job is to find an existing open source engine and improve it to the point where it does have fast startup and phenomenal page load times.

Hyatt also pointed to David Baron’s review of the Gecko layout engine for examples of the challenges facing a company seeking a layout engine. Hyatt essentially said that in order to use Gecko to accomplish Safari’s speed goals, Apple would have had to significantly rearchitect some parts, drastically trim or remove several libraries, such as the image and network libraries that were redundant with Mac OS X libraries, and learn Gecko’s unique terminology for everything. With KHTML they did not need to rearchitect because they found it already small and well-designed. But it cost them the unmatched standards support of Gecko. It will be interesting to see how these comparisons motivate improvements in both engines.

Update: jwz saw it too and points to the LiveJournal archive of Hyatt’s post. He says Hyatt says he is working on a more accurate version.

I got a chance to play with Safari and tested out a few different sites. I started to feel like I was flying blind. Where’s the JavaScript console? Where’s any notification of JavaScript errors for that matter? If Safari is going to claim to be “like Gecko” it needs to work like it. In one case the contents of a DHTML page that works fine in Mozilla just didn’t appear and I had no information about what was failing. Frustrating.

I was also bothered by it not recognizing the view-source: prefix to show the source of any URL until I found the Activity window. The Activity window shows all the URLs loaded with a particular page and you can double-click them to view them individually. Nice. Still, the View Source bookmarklet has worked in basically every browser for years so it would be nice to support.

I found a site describing a Safari Enhancer that “enables several hidden features of the Safari webbrowser beta.” The screenshots show a Debug menu with a View DOM tree item, the ability to change the browser identity of Safari, a minimum font size option, and ways to import bookmarks in various formats. Sounds helpful. Too bad I don’t have a mac to play with all the time.

I’ve been playing around with trying to implement a JavaScript version of SnapBack like in Safari. I thought I’d try it first as a bookmarklet since the JavaScript History object already provides some of what’s needed.

With JavaScript you can easily jump back to the previous Google page in history. Here’s a bookmarklet to do just that: BackToGoogle. This is limited, but may be a nice shortcut. The feature in Safari has the advantage that the SnapBack button only appears when it would be useful. Safari also resets the location of the SnapBack if you use a bookmark or type a URL. In the case of this bookmarklet, it always goes back to the previous Google entry in the history.

I believe I may have found a bug in Mozilla in writing this. According to the documentation, history.go(location) should load the nearest history entry whose URL contains location as a substring (the most recently visited). Mozilla appears to be loading the first history entry that has that substring (the first one visited). Or so it seemed.

I’ve done some more experimenting with this including working with the UniversalBrowserRead privilege so I can use the history array, but that has not helped. What I’d like to be able to do is traverse the history looking at the referrers. If an item has no referrer then it would likely be a nice location to jump back to. (Or potentially the page right after it if it has a query string; it would be more likely to be a search results page.) Unfortunately, I see no way to get the referrers from JavaScript other than for the current page. I wonder if the browser’s history mechanism actually keeps track of the referrer or if it just contains the list of URLs loaded in the window.

Really. “Ray L. Wallace was Bigfoot. The reality is, Bigfoot just died,” said Michael Wallace about his father, who died of heart failure Nov. 26, 2002.

Apple Gets It is an interesting commentary on Apple’s new Safari and Keynote products. I believe it was written by Brendan Donohoe, who was a former interface designer for Mozilla.

Aaron Swartz alludes to Safari having spell check in HTML form fields. If only Mozilla had implemented it back in 2000 when it was suggested. See Mozilla bug 23421 and bug 16409. This will be a killer feature for anyone that writes text in HTML forms, especially bloggers. Unfortunately, both bugs are still marked helpwanted.

Don Merton (formerly of Mozilla.org and now engineering manager of Safari at Apple) has sent a message to the KDE developers explaining why Apple picked KHTML as the engine for their new Safari browser. He writes:

The number one goal for developing Safari was to create the fastest web browser on Mac OS X. When we were evaluating technologies over a year ago, KHTML and KJS stood out. Not only were they the basis of an excellent modern and standards compliant web browser, they were also less than 140,000 lines of code. The size of your code and ease of development within that code made it a better choice for us than other open source projects. Your clean design was also a plus. And the small size of your code is a significant reason for our winning startup performance….

Update: jwz claims that “translated through a de-weaselizer, this says:”

“Even though some of us used to work on Mozilla, we have to admit that the Mozilla code is a gigantic, bloated mess, not to mention slow, and with an internal API so flamboyantly baroque that frankly we can’t even comprehend where to begin. Also did we mention big and slow and incomprehensible?”

Just caught the live feed from MacWorld 2003 where Steve Jobs demonstrated the new Apple web browser called Safari. Impressive. The SnapBack feature looks cool: You go to Google, search for something, go to one of the resulting sites and wander around a while, and then just click the SnapBack button to jump back in history to your original search results page. Seems a reasonable and frequently needed shortcut, although I’m unclear how it affects the back button and it might add some user confusion about which to use. He also demonstrated SnapBack with Amazon and said it worked for any site. I would have been really impressed if it worked for searches on any site, but I suspect it just goes to the root for non-known search engines. I liked the excellent mechanism for reporting bugs.

Jobs said it is based on the KHTML open source project when I expected it would be based on Gecko like Chimera. It really surprised me, especially after they hired David Hyatt. It remains to be seen how well Safari does with standards, but more standards-based browsers is a good thing. I hope it is solid. If Safari is really the fastest browser on the Mac, that’s cool.

I can’t wait to try it out.

Update: I added a link to the Safari information on the Apple website and to a KHTML page.