Hacking at 0300

For the search on the Young Israel site, I use Google with a form that creates links like http://www.google.com/search?q=foo&sitesearch=http://youngisrael-stl.org to limit the search to the one site. It works fine in normal browsers, but on my iPhone it detects the browser and changes it to a mobile-optimized site that ignores the sitesearch=http://youngisrael-stl.org and returns results for the whole web. http://www.google.com/search?q=foo+site:youngisrael-stl.org works fine, but I can't make an HTML form add the site: term automatically. A workaround would be to make my own page on the server that mangles the query string and changes Location, but I'm not sure it's worth the effort. I'll see how many complaints I get.

Addendum, later the same day: It looks as though Google isn't supporting the sitesearch query at all; it was deprecated a few months ago. The fact that it still sometimes works is just a lucky coincidence. They use "Custom Searches" now, and this wise person figured out how to use it with forms rather than javascript. So that's what I'm using now. It serves ads at the top of the page, but I'm too cheap to pay for the ad-free version.

The documentation for the query parameters is pretty complete, and it looks as though you could create a "generic" all-web custom search then use the parameters to limit it programmatically. Unfortunately, it looks as though the XML/JSON data is only available to paying customers.

I decided to make the Young Israel site iPhone-friendly, and there are lots of good sites for tips on creating custom CSS for the small screen. The best I found was on CSS wizardry. It doesn't focus on the how so much (using media queries or checking the User-Agent string (evil!)) as the what—making sure the elements are linear vertically, not using floats, shortening headers, etc. The major problem is that his CSS sample has the "wrong" syntax for the media query, so it won't work.

The big gotcha from the official CSS3 documentation: @media (max-device-width: 480px) doesn't work (in either Safari or Firefox), even though the documentation says it's legal. You have to have a media type in there: @media screen and (max-device-width: 480px). Took me forever to find that bug.

I would also use max-device-width rather than max-width; the user on a big screen may shrink the window and it would be confusing for the layout of the site to suddenly change. I would also not use the only screen hack that Apple suggests; there doesn't seem to be any reason to use CSS hacks (shades of the 1990's!) to target only iPhones.

The other gotcha is with my CSS parser: the javascript is run in the order that it is seen, so if you want to remove a widget for the small screen you have to explicitly destroy it:

#q {
  -jquery-googleSearch: /* default */;
}
@media screen and (max-device-width: 480px){
  #q {
    -jquery-googleSearch: destroy;
  }
}

Hope this helps somebody avoid a miserable morning.

Well, jQuery 1.5 is out and there's yet another incompatibility: they changed the way attribute selectors work. You used to be able to use them without quotes, as [attr=value] but that now throws an exception. Now you have to use [attr="value"]. Not sure why they changed it; The CSS level 3 definition is ambiguous about when you need quotes, and it may be that jQuery is OK with leaving the quotes off for simple (letters/numbers) values. I don't have time to experiment; I just changed things to use the quotes. It affects parsecss and flexcal; I haven't found any other places I used this.

Now that sendkeys is fixed to work with contenteditable and I've analyzed Lebedev's VirtualKeyboard to allow typing on the physical keyboard, updating the hebrewKeyboard plugin was straightforward. I had to learn a fair amount about the difference between keyup, keydown, and keypress events, but I think everything works. Check it out!

Update: I no longer (2012-08-05) use Chili, I've switched to Prism.

I wanted to try different syntax highlighters so I wrote a little WordPress plugin that let me switch between different highlighters (email me if you would like that code). I wanted syntax highlighters that were javascript-based (ruling out GeSHi), and that allowed me to highlight inline code elements as well as code elements within block-level pre elements, using the HTML5 <code class="language-whatever"> notation for determining language. I also wanted something that didn't do any fancy javascript or Flash for selection and copying, and either supported Lisp and Basic or was easy enough to extend.

Everyone seems to use Alex Gorbatchev's syntaxhighlighter but it uses nonstandard name attributes and only works on pre and textarea elements, so I haven't tried that. I tried Benjamin Lupton's jQuery syntaxhighlighter based on Google's prettify. It insisted on making all elements display: block but a little CSS manipulation fixed that.

Then I tried snippet, which only works on pre elements but was easily modifiable to get around that, then also needed some stylesheet changes to keep the results from being display: block. Adding new languages however looks far too complicated; it uses shjs which uses language definitions from GNU Source-highlight, which is a whole different language.

jush does things right (working on code elements and not forcing them to be block) but it's hardwired for a limited number of languages and the CSS is pretty ugly. That could be fixed, though, and it does a cool trick of turning keywords into links to the documentation. Too limited a language selection, though, but it would be a nice base for working on.

In the end, I'm going to stick with chili. It's simple enough for me to modify to suit my needs, it's easy to add new languages and it works. Creating new "themes" is impossible; the styles are hard-coded into the javascript files, but I can live with that. I may sometime write my own highlighter, but for now, I'll stick with what works.

The $.fn.sendkeys Plugin

This is now obsolete. sendkeys is at version 4, and is documented at "Rethinking $.fn.sendkeys".

I wanted to make a general-purpose onscreen keypad, and wasted a huge amount of time trying to find a way to simulate a keypress. $(element).trigger("keypress",...) won't work. Neither will keyup or keydown. For security reasons, I guess, you can't tell an element to pretend a key was pressed. The browser is too worried that you will access menus or something.

So I wrote my own plugin and named it after Microsoft's sendkeys which does similar things. For any editable element elem, $(elem).sendkeys(string) inserts string at the insertion point or selection. It's the insertion point sensitivity that makes it more sophisticated than elem.value += string.

It depends on my bililiteRange routines to manage the selections in a cross-browser way.

Downloads

See $.fn.sendkeys on github.

See bililiteRange on github.

See the demo.

Continue reading ‘Improved sendkeys’ »

Updated to version 2.3 on 2014-02-26 for data routines.

I was trying to update my sendkeys plugin to use contentEditable, and realized that it was getting harder and harder to do without some selection/text replacement library. Each browser is different and even different elements are treated differently. There are a few libraries out there, but none handled both input and textarea elements and regular elements, and would constrain the selections to a given element (critical if I want to edit only part of a document) and none made it easy to simulate arrow keys, moving the selection left or right. So I figured I would make my own.

See the code on Github.

See the demo (try it in different browsers!).

Continue reading ‘Cross-Browser Text Ranges and Selections’ »

I like Andrea Ercolino's chili syntax highlighter. I like it because it works well with jQuery, it allows me to use the HTML5 <code class="language-whatever"> notation for determining language, and I can highlight inline elements, not just pre elements. And Andrea has been very responsive to my questions.

But it has an annoying habit of being too clever about cutting and pasting: selecting text in marked-up pre elements evidently used to cause problems in Firefox, so chili detects the mousedown when you try to select and creates a pop-up box with plain text instead. Unfortunately, it just gets in the way and the text is no longer formatted correctly. And the problem only exists for code with line numbers, which I never use.

So I modified the code in file jquery.chili.js: I turned the function fixTextSelection (line 1097 in my copy) into a no-op by adding a return; at the beginning. Now select and copy/paste work correctly in Firefox. It may be broken in Internet Explorer, but that doesn't bother me: my whole blog theme breaks in Internet Explorer. That's a feature, not a bug :) .

There still are some problems; it loads styles and scripts dynamically and if there's a lot happening on a page the syntax highlighter tends to lose race conditions and nothing happens. I may look at Benjamin Lupton's jQuery syntaxhighlighter or JUSH or make my own (in my copious free time).

A depressing but absolutely correct editorial from Dimitri Christakis of the University of Washington in this month's Archives of Pediatrics and Adolescent Medicine (behind a pay wall, unfortunately, but the full reference is there).

[H]undreds of decision tools in a variety of forms—guidelines, practice parameters, prediction rules—have been generated. Some have been good, some bad; some have been validated, others not. But what they all have in common is that their overall use remains poor at best. In the meantime, those of us in academia continue to create them and those of us on editorial boards continue to vet them for methodological rigor. The cottage industry of decision tools has at least the appearance of an academic jobs program since, to clinicians in the real world, their utilities remain largely unproven [emphasis added]. For example, there are no fewer than 10 clinical prediction rules for something as common as streptococcal pharyngitis, and I would be surprised if most clinicians even use one.

The big problem is the difference between significance and importance. Significance in statistical jargon is an estimate of how likely the results are to be true (see David Sackett's article on randomized controlled trials) but it says nothing about whether the results mean anything to me in real life. A test that tells me a patient has a 50% chance of having strep throat, when before I would have guessed at 20%, may have a p = 0.0001 (the test is consistently better than chance!). But who cares? For actual clinical practice, things that affect my decision-making need to be orders of magnitude apart, not a few percent. Similarly, a new fever-reducing medicine may have reduced the temperature by 0.1 degree with a really high ?², but isn't going to make me prescribe it.

But real life is rarely so cooperative as to give you high odds ratios, so guidelines based on actual data tend to be less than useful, and guidelines with advice that can actually be implemented tend to be based on "expert opinion," which is a polite way of saying "faith." ("Experience is the ability to make the same mistakes with greater and greater confidence").

So what do we do? The academics would have us analyze every article ever published and determine our own statistics, but that's impossible. All we can do is read the reviews and guidelines and make sure we know which conclusions are solid, and treat them with respect, and which are strongly-held opinions by experts in the field, and listen politely and decide if we think we know enough to overrule them. If the guideline won't tell you the difference, throw it out.

There's still some room out there for the art of medicine.

Update: A perfect example in this month's Pediatrics (Taisan and Copp (2011) Pediatrics 127:119-128). A review of ultrasound to look for undescended testes showed that it would change the probability of an intra-abdominal testis (requiring surgery) from 49% to 64%. It doesn't matter how significant that difference is, it isn't clinically important and therefore the ultrasound is not indicated.

As Douglas Crockford has said, javascript is Lisp is C's clothing. That is part of what make javascript fun to program, but I never realized how literally true that statement is until I found this fascinating article by Thomas Lord about GNU and Scheme, that claims:

I've read, since then, that up to around that point Brendan Eich had been working on a Scheme-based extension language for Netscape Navigator. Such was the power of the hegemony of the high level folks at Sun that the word came down on Mr. Eich: "Get it done. And make it look like Java." Staying true to his sense of Self, he quickly knocked out the first implementation of Mocha, later renamed Javascript.

Explains a lot. And shows what an under-appreciated genius Brendan Eich is.