Phone/Fax 415.563.6563
With the addition of some interactive pages, I have changed my assessment of the site from "by no means ... technically innovative site" to "extremely mildly innovative". At any rate, I still expect virtually no traffic to this page. However, I have learned a lot by surfing to sites just like this one, so I figure it couldn't hurt to document some of the problems I've encountered and their solutions online.
Updates to this page (most recent first):The original home page was written with Microsoft Word. Although I now maintain it via a simple text editor rather than a WYSIWYG editor like Word, it got me started quicker than I might otherwise have been able to, and studying the generated html was a valuable exercise. There were, to be sure, a lot of things about it I didn't like. One of the biggest unpleasant surprises was that, although it was easy to place an image on the page and reduce its size, the resulting page actually referred to both the image in its original size as well as the reduced-size version - potentially a lot of wasted bandwidth there (I was unsure at the time how to tell if both were actually being used as the page displayed). You could mitigate this to a certain extent by creating a reduced-size version of the image in the first place, and just placing the reduced size version, but the resulting document still referred to two different image files. Another problem is the excessive amount of style information mixed in with the html tags.
The freeware text editor I use now is notepad2. It has some advantages over the Windows-supplied notepad; I find its line-numbering, syntax highlighting, and especially the ability to handle Windows/Mac/Unix variations of newline most helpful. I occasionally do some editing on a Mac, and I also use a freeware editor mi with similar features in that environment; it does not do syntax highlighting for javascript, however.
My host is a Linux server running Apache, using Cpanel as the interface to manage the site. A very good simulation of this environment on my PC is available - XAMPP. It allows me to test any PHP or htaccess changes before going live. It is also useful for testing some features that don't work properly from local files; such features are mentioned below. Another interesting problem arose when the mail format was changed so that each message now resides in its own file, rather than a single file for each mail folder. When the files were all zipped together, the file names for these confuse a lot of Windows extract programs, including the native facility supplied with Windows, and WinZip. They seem fine on Linux, and I did find a free product WinIMP which handles them correctly in Windows.
It turns out that Mac OSX comes with Apache as well. It has htaccess disabled, without good documentation on where to find httpd.conf. I eventually found it in /private/etc/httpd, and it was necessary to use sudo to edit it. After that, htaccess worked fine "globally", but had some problems with file redirection for the "local" users. This was corrected by making /Library/Webserver/Documents/Users a symbolic link to directory /Users (using the Unix command ln -s). After that, all worked nicely. I haven't tested its PHP support, which is also disabled by default.
For our gift registry pages, we typically use an ordered list so that customers can make reference by number. We usually have an image of the gift, and a very short text description. When I wanted to use a longer description, I found a surprising amount of difference in how the pages displayed in different browsers. I don't know that one is more "correct" than the others, but it's not a topic I've seen discussed elsewhere, so my findings are here.
While looking at Microsoft's Online Clip-art Gallery one day, I saw that they had some music. To my surprise, they had a midi arrangement of the song Dayenu, something we clearly needed for our site. But, in using it, I entered one of the least standardized areas of web support. There was an old, but non-standard, way of embedding objects - the <embed> tag. There was a new, standard way of embedding objects - the <object> tag. But Microsoft Internet Explorer for Windows (hereinafter MSIE) implemented that tag much differently than other browsers (and also without allowing proper nesting), and it seems that, because all current browsers support <embed>, most sites using embedded objects do so with a combination of <object> and <embed>. Even so, there were still differences among browsers in how they do this, which I will note separately when I discuss cross-browser issues.
One thing I was sure of was that I did not want to play the music without (a) an explicit action from the viewer to start playing; and (b) giving the viewer an easy way to stop playing. I also did not want to add much to the load time of the page, since I suspected (correctly as it turns out) that few viewers would actually choose to listen. I also did not want strange things happening if no suitable plugin was configured to play the file (I had no real interest in sending my viewers off to fetch software), and most browsers currently seem to have problems with that. So I wound up implementing it as a simple link to the midi file rather than an embedded object, even though this meant that, in many browsers, the user would be directed away from the home page, often to a page with nothing but the midi player.
Things stayed that way until Microsoft's changes due to the Eolas patent. Our site was, of course, entirely unaffected by the changes, because we didn't embed anything. But, as I studied the solutions being recommended for the problem, namely, to use external Javascript to embed the object, I saw that I could make use of those solutions. On further study, I found out how to determine if the appropriate plugin was available (navigator.mimeTypes for non-MSIE; MSIE will be discussed later separately). So the current version of the site just uses a link to the midi file, but also has a Javascript file executed at window.onload which replaces those links with a Javascript command to embed the object instead, and start playing.
On Windows systems only, I will first try audio/x-midi, but will also try application/x-mplayer2 if the former is unavailable, since WMP in Windows handles "standard" object types. This is not true for WMP on MAC, which handles only proprietary types (e.g. wmv). For mplayer2, Opera needs a param src tag, but Firefox does not.
I am left with one problem which I have been able to work around satisfactorily, but I understand neither the problem nor the workaround very well. In non-IE browsers, when I click on the link which brings in my embedded object, there is no problem. When I navigate to another link in the same window, the music stops if it's playing. Now, when I hit the back button, I expect to come back to the page with the link to the embedded object, rather than the object itself. (This is what happens with IE.) No, the page has all the embedded objects in place, and since they are all autoplay=true, they start playing, undesirable at the best of times, and especially so with multiple songs. So I added an onunload event which went around turning autoplay to off. This fixed the problem, but not in the way I expected - rather than the page still having the embedded objects but in autoplay=false status, it was back to having the links rather than the objects. Consistent with that result, when I changed the onunload event to do nothing at all, the problem remained fixed in the same manner. An inquiry to comp.lang.javascript elicited the opinion that the browsers which exhibit this behavior have a memory cache of the page which they invalidate when an unload event is handled. This makes a certain degree of sense, but doesn't seem entirely reliable - who knows whether they might change their reaction to unload some day? A safer approach might be to set a timeout to change the autoplay value to false. This preserves the quickness of the memory cache while avoiding the autoplay problem. Its biggest theoretical drawback is that it might operate too quickly over a slow connection, but limited testing over a phone line has always worked successfully.
Another approach to handling the embedded players was to use scripting of the objects rather than straight html. This seems too cumbersome for the moment, especially since the players all use different function names (e.g. Play() for QuickTime, play() for WMP, doPlay() for RealPlayer), and I am not currently determining which player is being used for non-IE (although in practice I believe it will almost always be QuickTime). The QuickTime methods work well in most Windows browsers, although there can be a timing issue if you try to "override" autostart=false by using the Play method; this is especially true if the object is added via Javascript. Mac browsers have the same problem, with the ironic difficulty that Safari didn't support QuickTime scripting till OS10.4.
WMP seems to have problems with relative uri's, with uri's with embedded spaces (so don't test out of My Documents), and with Opera's methods of identifying local uri's. XAMPP was particularly helpful in demonstrating that these problems on the local machine would not be problems on the internet.
Aside from audio and video objects, you can embed pictures with the object tag; indeed, XHTML2 has eliminated the img tag for this reason. Mozilla and Opera seem to handle this without problems, but support among other browsers is somewhat spotty. Safari handles the embedding okay when images are enabled, but, when they are not, it does not degrade properly to the alternate text. Netscape 4 actually does fairly well - it does not display the image, but does display the alternate text. The entire page is messed up with Web TV, and I have not figured out how to overcome it. Windows IE does not handle it particularly well, but it can be corrected through Javascript - such a solution is discussed here. That solution works for IE5+; it doesn't work for IE4. It also doesn't quite go far enough; if the image being embedded in this manner uses a transparent background, you probably need to add some code to get it to match the page on which it is embedded:
if (obj.currentStyle) { // W3C equivalent is window.getComputedStyle
var testcolor = "transparent";
var ob2 = obj;
while (ob2) {
testcolor = ob2.currentStyle.backgroundColor;
if (testcolor != "transparent") break;
if (ob2.nodeName == "HTML") break;
ob2 = ob2.parentNode;
}
if (testcolor != "transparent") obj.body.style.background = testcolor;
}
It is also worth noting that, when embedding html as an object, IE has the same problem with scrollbars as it does when embedding images as an object; but the Javascript which fixes the problem for images does not seem to be effective for html.
Someone asked why my blintz soufflé recipe didn't have an "email this" link. I don't normally like to duplicate "standard" browser functionality, and this is easily available with MSIE, Firefox, and Konqueror. But it wasn't so clear how to do it with Opera (right-click on page), and very obscure on Safari (I understant that Shift-Apple-I will work, but it doesn't with my version). So I looked into it. The Javascript to do it is pretty straightforward, but the accented character in my page title sometimes causes problems. This is likely due to a mismatch between the character set the browser is sending and what the mail client is expecting. As long as both are UTF-8, there are no problems, as is the case with 2 Linux combinations (Konqueror/Kmail and Firefox/Evolution) - these cases also handle non-Latin-1 character sets without problems, both through the native send function and the script.
In Safari using the Apple Mail client, if the document is ASCII-encoded (using a named entity for the accent), both the subject and message body are blank. This can be corrected by marking the document UTF8-encoded (even without any non-ASCII characters). Firefox Mac worked correctly regardless of the encoding. I have not tested non-Latin-1 data on the Mac.
On IE7 using the Yahoo Mail client (with a default browser of IE7), with the "use UTF8 for mailto links" option, my script works fine. But the "send link" IE7 function is slightly off - it sends the data to Yahoo mail as Latin-1 (ISO-8859-1), but the page opens with UTF8 encoding, making it appear as if the accented character is wrong. This is corrected by manually changing View Encoding to Western European. With the UTF8 mailto option off, IE7 send link fails in the same way, and my script now sends the data in UTF8 but the mail page displays in Latin-1. Sigh. Firefox communicating via Yahoo Mail on IE7 had similar problems, although the characters are different.
With IE6 using Outlook 2003 as a mail client, "send link" and my script worked. But now the encoding was wrong for Firefox. Presumably IE6 and OL2003 are both using Latin-1 (ISO-8859-1), and, indeed, this combination fails badly for non-Latin-1 data. Using the escape function on the document title caused the accented characters to work correctly, but without any relief for non-Latin-1 data; furthermore, using escape breaks other working scenarios (e.g. the working Linux examples).
Opera in Windows and Linux, with its own email client, was a strange case. Right-clicking on the page to send a link works (same for non-Latin-1). But sending it through Javascript, it appears that the data is sent as UTF8, but displayed as Latin-1. Unlike IE, View/Encoding does not fix this problem. The escape function fixes this for the accented character, but not for non-Latin-1.
There were no problems in any environment when there were no accented characters. So, because of the problems I did see, and my inability to exhaustively test all combinations of OS and mail client, I extended my script to allow for an alternate unaccented title. But I also reluctantly removed the accent from my page title. Not perfect, but with these results all over the map, it seems the prudent thing to do.
An interesting offshoot of this problem is that someone reported that cut and paste from the recipe page into email did not work. The problem is that the fractions (e.g. ½) were replaced with garbage characters. It appears that this problem is restricted to AOL mail on the Mac. It also happens with other Mac programs without Unicode support, e.g. AppleWorks. The explanation is that these programs use character set MacRoman - the fractions are not part of that character set, but the other unusual characters on the page (the degree symbol ° and accented é) are and they are pasted correctly. It is especially surprising to see a modern mail client without Unicode support.
Related to that problem, a paste on the Mac into Word 2004 also did not work perfectly. In this case, the bulleting for both ordered and unordered lists is garbled. Interestingly, AppleWorks handle this just fine, as do Word 2000 and 2003 on Windows. Back on the Mac, TextEdit handles both bulleting and fractions. Saving the pasted text in RTF format through TextEdit and opening it with Word did not eliminate the problem. Rather amusingly, opening up the RTF document using OpenOffice gave mixed results - the unordered list was formatted correctly, but the ordered list is garbled. The only "safe" way to handle this on a Mac appears to be to paste into TextEdit, then save the file in HTML format. This produces a consistent and correct Web page on the receiving machine.
One of my goals once I moved from Word was to produce pages conforming to Web standards. I first got to Transitional HTML 4, then it was pretty easy to get to Strict - about all that I had to give up was target="_blank", which I had been using to open up a new window for a map to the store. It was then very easy to get to XHTML 1.0, which was probably a step too far - MSIE supports it only when served as html, and you can find lots of discussion on the web on whether serving xhtml as html is a good idea, and I'm definitely not using anything which would require the use of xhtml. I will definitely not produce any XHTML 1.1 pages; the differences between it and 1.0, small though they are, seem to pointlessly make explicitly illegal constructions which could just as easily remain supported with instructions that they must explicitly be ignored. I don't understand the rationale in breaking existing code without offering any advantage in doing so. At any rate, since my pages were XHTML before I came to this decision, they remain so (and I have a script to test them as XHTML with browsers than can handle it); but newer pages (like this one) are back to HTML 4.01 Strict. All pages on the site are validated with W3C Validator and W3C CSS Validator.
I also get a second opinion from the
WDG Validator for the entire site.
Especially around holidays, I like to put very short Hebrew messages on the site. There is now excellent browser support for Hebrew in most modern browsers. If I were to use it extensively, I would have no problem using text characters. However, for the short phrases I use, it is sufficient to use images, and this also supports the less modern browsers. However, because I had such difficulty finding one particular item, I eventually added one page with Hebrew text - the Lieberman clause in Hebrew, and, with the addition of the FAQ pages including blessing texts, I have now added some vocalized Hebrew as well.
The process to convert the text to a picture is somewhat labor-intensive. Word 2003 has very good support for inserting Hebrew characters right-to-left into a Word document. That functionality was available in Word 2000, but is very buggy. On Mac OSX, TextEdit has excellent Hebrew support. In fact, I didn't have Word 2003 when I started this project, and couldn't figure out how to edit pictures on the Mac. But I did have a shareware non-Unicode font Hebreka and program Seekeys which I had uploaded from Compuserve when the Internet was young, and together they gave an easy interface to export to Word, from which I could cut and paste to MS Paint. Since the text was included as an image, the fact that it is non-Unicode is not really a problem.
Lately, I have used a somewhat more convoluted route. There is a nice Unicode Character Map which permits you to enter data, and copy it to a clipboard (or do a web search). I can then paste the clipboard data to Wordpad, adjust font name, size, and color, and then cut and paste again to Paint, where I can save everything as a GIF. (Note that a screen capture tool like Snagit can simplify this process quite a bit.) Paint in theory supports a transparent background in GIFs, but I haven't been able to figure out how. IrfanView does this quite nicely, and has also been helpful for a few other image-editing problems. I, of course, need to use a Unicode font with this approach. Mac OSX and Windows XP both come with at least one Unicode font which supports Hebrew as part of the native system; both also come with some free optional Hebrew-only Unicode fonts which you can install. I have used Narkisim for my most recent messages.
As seems usual with "standard" rendering, there is a lot of unexpected variation in how various browsers handle vocalized Hebrew, i.e. with vowels (a.k.a. nikud or niqqud).
My goal all along has been to have the page look reasonable in any browser. This was actually fairly easy when I used tables for layout, and, to a lesser extent, fixed font sizes. However, you'll find lots of articles on the web on why layout in tables isn't a good idea, so I took up the challenge of making my layout table-less. This was an excrutiating exercise, taking far longer than I imagined, as slight differences in CSS implementation across browsers made big differences in the layout. But I think I finally succeeded. I still have one table, but it's "legitimate" - the table of store hours by day. At any rate, here are my observations about features that I experimented with on the site in a number of different browsers.
if (!window.ActiveXObject) return;
try {var WMP7 = new ActiveXObject("WMPlayer.OCX.7");} catch(e) {return;}
This will work fine if WMP is not installed - whatever software the viewer has configured for playback
will just open in a separate window.
It will, however, not work ideally if the ActiveX control for WMP is disabled.
In that case, the viewer will just see a tiny icon at the bottom of the browser window.
Hopefully, any user savvy enough to disable the control will recognize the icon and know how to react appropriately.
I've had only a handful of visitors on mobile devices. As usual, they got to the site before I was prepared for them, and, as usual, it didn't look very good when I checked it on my cellphone. It was also very slow to load. In both cases, the main problem was the images included on the page. To investigate what was going on, I needed an emulator, and at least 2 good ones are available. Nokia's Series 40 SDK emulates that company's phones. Openwave's simulator provides a good generic device. Since my problems involved images, and since they weren't all that important on a cellphone, I created a media="handheld" CSS file to not display them. This corrected many of the display problems, but the load time didn't seem affected. As it happens, the browsers load the images even though they don't display them, certainly the worst of all worlds.
Some research led me to the wonderful mod_rewrite module of Apache. A site which I no longer recall had exactly what I wanted - a way to redirect mobile users to a slimmed-down site. Here is the code:
RewriteEngine on
# Our conditions are that the browser must accept XHTML and WML
# There is an implicit AND between the two conditions.
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml
RewriteCond %{HTTP_ACCEPT} text/vnd\.wap\.wml
RewriteRule index.html$ dayenu32.xhtml [L]
# This next block will catch browsers that only understand WML
RewriteCond %{HTTP_ACCEPT} text/vnd\.wap\.wml
RewriteRule index.html$ dayenu32.wml [L]
As you see from the code, I have two mobile sites - dayenu32.xhtml for most current devices,
which understand XHTML as well as WML;
dayenu32.wml for older devices which understand only WML.
There is no significant content difference between the sites, so I can certainly get away with wml only,
but I'll just leave it flexible for future developments.
The Openwave simulator can, with some difficulty, be configured as either an XHTML or WML-only device;
I have not found an equivalent facility for Nokia.
Alas, when I changed PC's, I found Openwave no longer available and the current version of Nokia
not working satisfatorily.
However, Opera allows you to resize the browser, view the page as if if were on a handheld device,
and change the http-accept header using opera:config, allowing an excellent emulation
of wml-only and wml+xhtml devices, so that's what I will use going forward.
Wapsilon offers a live WML emulation.
I recently had my first look at the site on a PDA. It was, not surprisingly, not designed to handle wml, so it goes to the main site, but honors the handheld css, so it has no images, and shows a link for making a phone call, something which it could not do. I had expected I'd find out about PDA traffic the same way I found out about phone traffic, through the site's statistics. But, since this device identified its browser as IE6 for Windows 98, there may have been some usage before which I did not notice. At any rate, I may soon just disable the handheld css for the main site, since the PDA would be able to handle it just fine, and the phones with which I was concerned are redirected.
Both simulators and my cellphone seem to have problems with the a:link and a:visited pseudo-classes under certain circumstances. Neither seems to honor color for links associated with a class or identifier, all the more surprising since Netscape 4 and Web TV handle it without problems. In addition, Nokia seems to use a default color for link items in a list.
I finally had my first brief look at the site on iPod Touch and iPhone recently. These send headers which do not identify them as wml devices, so the desktop web page is sent to them. They also do not identify themselves as handheld devices when dealing with CSS. The result doesn't seem too bad, though lots of zooming and scrolling is needed. The page seemed to load faster on an iPod, over a wireless network, compared to an iPhone over the cellular network. All in all, I don't know whether this is an approach I favor or not.
One nice thing is that the Safari on the iPhone recognized the phone number on the page and turned into a link which could be called (I think - I didn't get a chance to test); the iPod naturally left it alone. It is not clear whether browsers on other smart phones come with a similar capability. It would be nice to have a suitable link when the device supports it, but it would be a poor user experience to make a link that won't function in most environments, so this would have to be something that was added through scripting. Alas, it seems clear that there isn't any way to determine whether a browser supports the tel: protocol. In researching the topic, I came across WURFL as a possible method, but my tests with it were not satisfactory for this purpose - my desktop browsers showed as supporting the http/wtai protocol, which they do not; iPhone showed as supporting http/wtai, which it probably doesn't (did not get a chance to test); and iPod wasn't in the database at all.
The iPod Touch did not support midi files, at least not out of the box; I found this a bit odd since iTunes certainly supports them in desktop environments. I did not have a chance to test whether iPhone handled these.
I recently learned of the css white-space declaration, and figured that it would be useful for eliminating non-breaking spaces in my horizontal list items. NBSP is supported in all browsers, but its use does tend to make the page source less readable than I would like. As usual, this caused cross-browser problems, in part because I included a trailing space for each list item (which had seemed to help on the WebTV and Nokia emulators, neither of which I use any longer). So, when I used white-space: nowrap, it worked on all browsers except IE8, which refused to break the line at any position. So, I tried white-space: pre, which fixed the problem in IE8 ... and broke in Opera as well as IE5/6/7 (same problem - no line break at any position). Firefox and Safari, incidentally, had no problem with either setting. Ultimately, I just eliminated the trailing space and used white-space: nowrap, which works correctly in all browsers I care about (but see notes on printing below).
Before discovering htaccess (see Mobile Devices below), I experimented with php for redirection. This turned up an interesting "feature" - when I included an xhtml file, it balked when it saw the <?xml header. Changing the php.ini parameter short_open_tag from its strange default value on On to Off eliminated this problem.
I recently added yahrtzeit calendars, lists of Jewish holidays, and zmanim (times for required prayers) to the site. (I also added a Julian date calendar, useful for mainframes but not especially relevant to the site.) Since I wanted to make these features accessible to all users (in particular, I wanted them to work without javascript), I looked into PHP, and was very pleasantly surprised at how well features pertaining to the Jewish calendar were integrated into the built-in date-handling for PHP. There are built-in functions to convert Gregorian dates to (gregoriantojd) and from (jdtogregorian) astronomical Julian dates, and to likewise convert astronomical Julian dates to (jdtojewish) and from (jewishtojd) Jewish dates, making it very easy to convert between Jewish and Gregorian dates. Jdtojewish even allows the date to be returned as a string in Hebrew (ISO-8859-8-L) characters. The function cal_days_in_month allows you to specify the Jewish calendar, as does jdmonthname. It solves most of the problem of years with an extra Adar by treating the month as a value between 1 (Tishri) and 13 (Elul); 6 is Adar-I, 7 is Adar-II, and 8 is Nisan whether or not it is a leap year (with 2 Adars). This isn't quite perfect because, in a non-leap-year, 6 should be just Adar (without -I), but there are actually several different methods to work around this deficiency when you’re dealing with month 6. You can use the traditional method - if the remainder mod 19 is 0, 3, 6, 8, 11, 14, or 17, it’s a leap year, otherwise it isn’t; alternatively, you can also test jewishtojd(1,1,$year+1) minus jewishtojd(1,1,$year) – 383 or higher indicates a leap year; or you can compare jewishtojd(6,1,$year) to jewishtojd(7,1,$year) – not equal indicates a leap year; or you can test cal_days_in_month(CAL_JEWISH,6,$year) – that’s 30 in a leap year (and 0 in a non-leap-year which I think is a usable but wrong implementation – it should be 29 – cal_days_in_month(CAL_JEWISH,7,$year), which is always 29, is the value which I think should be 0 in a non-leap year).
PHP5 introduced new functions date_sunrise and date_sunset which are tremendously useful for calculating zmanim. Unfortunately, the initial implementation is a little buggy. See my first sunrise/set bug report, which received an astonishingly rapid response. The fix did indeed address my problem; unfortunately, it introduced a new sunrise/set bug; once again, this was addressed incredibly quickly. However, since it will take a little while for these fixes to percolate to my ISP, I was able to find existing code which I can use in lieu of the builtin functions until the fixes are generally available. I am very favorably impressed by the reaction of the PHP development team to these problems.
I hadn't given a whole lot of thought to printing until I introduced the calendars and FAQ section to the site, because those were the first pages which I thought might actually be useful to print. On my yahrtzeit calendar, I displayed alternate lines with and without shading to make things easy to read on the screen. Unfortunately, the shading is accomplished through the use of background colors, and browsers typically do not print background colors or images. This is reasonable to avoid a lot of wasted ink, and they all have an option to allow printing of background colors, but I did not want to have to instruct my visitors how to turn that option on, especially since it’s a global option which affects all printing from that point on, so should normally be turned off again once the page is printed. So I'm using special media print instructions in my css to differentiate the printed lines – alternate lines with italicized and normal text, and with top and bottom borders for each line. I don’t think it looks as good as the shading, but it’s good enough. It has occurred to me that this is an interesting application for alternate stylesheets – use the italics and borders as a print style on the preferred stylesheet, with an empty stylesheet (i.e. no separate print styles) as the alternate. I have tested this and it does work as desired. However, since this requires the visitor to both select the alternate and choose the correct print option for background colors, I haven’t actually implemented it – I think that a user who is sophisticated enough to do that probably has access to a screen capture tool, which will work just as effectively and more simply.
For some of my FAQ pages, it has been convenient to show a different logo image on the screen (which has a background color) than on the printed page (which will normally have a white background). I load both pictures and use css to decide which to display; it seems there should be a better way to do this, but so far I haven't come up with one. This works well in all browsers except Opera, where I have reported a bug.
And, having started to look at printing, I find several bugs. Most disappointingly, IE8 doesn't handle my white-space list correctly when printing (tries to put everything on one line). Firefox loses the left border of my hours table (I haven’ yet been able to reproduce this on a less busy page, which I would want to do before reporting it). IE7 loses the right border and the middle divider (even though IE6 doesn't). IE7- do a dreadful job with calendar tables, although I have a workaround – use conditional comments to avoid specifying border-collapse for IE7- and to include border=1 on the table tag for IE7-.
What a strange world. There is a lively market for illegitimate search engine and Ebay placement for misspellings, of which transliteration would be a subset. But any legitimate attempt to include hidden versions of alternate transliterations threaten to have you excluded from search engines. I guess what they want is something like the following. (No need to read on - I just wanted to end the page with this private joke.)
Dayenu Judaica is your source in Northern California Bay Area for items for the household - mezuzah (mezuzahs mezuzot), kosher scrolls, parchment scrolls, hamsa (hamsas) and tzedakah boxes (tsedakah tzedaka tsedaka). We carry a number of kosher snacks, including Bazooka bubblegum, bubble gum, Bissli, Halvah, chocolates, and Elite chocolate (including some sugar-free).