CSS Gradients via Canvas provides a subset of WebKit's CSS Gradients proposal for browsers that implement the HTML5 canvas element. To use, just include css-gradients-via-canvas.js (12KB) anywhere on the page (see examples below). Unlike WebKit, this implementation does not currently allow gradients to be used for border images, list bullets, or generated content. The script employs document.querySelectorAll()—it has no external dependencies if this function is implemented; otherwise, it looks for the presence of jQuery, Prototype, or Sizzle to provide selector-querying functionality.

The implementation works in Firefox 2/3+ and Opera 9.64 (at least). Safari and Chrome have native support for CSS Gradients since they use WebKit, as already mentioned. Beginning with version 3.6, CSS Gradients are also natively supported by Firefox and this implementation will defer in such case; note that you will need to specify two separate background CSS properties, one with -webkit-gradient and another with -moz-linear/radial-gradient which has a different syntax). This implementation does not work in Internet Explorer since IE does not support Canvas, although IE8 does support the data: URI scheme, which is a prerequisite (see support detection method). When/if Gears's Canvas API fully implements the HTML5 canvas specification, then this implementation should be tweakable to work in IE8. In the mean time, rudimentary gradients may be achieved in IE by means of its non-standard gradient filter.

CSS Gradients via Canvas works by parsing all stylesheets upon page load (DOMContentLoaded), and searches for all instances of CSS gradients being used as background images. The source code for the external stylesheets is loaded via XMLHttpRequest—ensure that they are cached by serving them with a far-future Expires header to avoid extra HTTP traffic. The CSS selector associated with the gradient background image property is used to query all elements on the page; for each of the selected elements, a canvas is created of the same size as the element's dimensions, and the specified gradients are drawn onto that canvas. Thereafter, the gradient image is retrieved via canvas.toDataURL() and this data is supplied as the background-image for the element.

A few notes regarding interactivity with this implementation: CSS gradients will not be applied to elements dynamically added after DOMContentLoaded. Additionally, each element that has a CSS gradient applied to it gets assigned a method called refreshCSSGradient(); at any time, this method may be invoked to redraw the gradient on a given element. This is especially useful (and necessary) when an element's size dynamically changes, for example as the result of some user interaction. Likewise, it is important to note that it will not work to rely on event handlers to invoke refreshCSSGradient() on elements whose style is changed by CSS rules with pseudo-selectors like :hover and :active; this is because event handlers are fired before the rule's style changes are applied to the element. Toggling an element's class name by scripting is how you can assure that its style will be changed before calling refreshCSSGradient(). The last example below demonstrates this.

Changelog

1.2 (2009-09-30):

Phong Nguyen raised an excellent point in that stylesheets which don't contain any CSS Gradients should be ignored in order to improve performance (in his case, for example, the jQuery UI stylesheets are large and don't need to be parsed). Now you can add class="no-css-gradients" to any style or link element and that will prevent this script from looking for CSS Gradients to apply with canvas.

1.1 (2009-08-12):

Now if cssGradientsViaCanvas.useCache is set to true, the CSS rules containing gradients are cached in sessionStorage instead of having to be re-parsed out of the stylesheets each time a page loads. For this to work, there must be implementations of JSON.stringify() and JSON.parse() available (e.g. json2.js).

Ability to use data: URIs for images is not explicitly detected since testing for the presence of canvas.toDataURI() is sufficient.

1.0.3 (2009-08-10):

Detecting support for native support for CSS Gradients in Firefox 3.6

1.0.2 (2009-08-05):

Now requiring that gradient(…) only be used with the background-image property instead of with the background shorthand properties since the additional background-* properties are not parsed out.

For my birthday this year, my dad gave me one of the best presents ever: John McWhorter’s audio course “The Story of Human Language“; LaVonne and I couldn’t get enough of his lectures. I’m sad to say I’ve finished them, but listening to them re-peaked my interest in the academic study of Linguistics; so I meandered over to UW’s Computational Linguistics website and, to my shock, I found that the entire program can now be completed via online correspondence! I was so excited! I was already a couple months past the admission application deadline, but I contacted the department and got approval to apply. Now, a few weeks later, I have just received news that I have been accepted into the program! This is one of my dreams come true!

For some more background and the reasons why I’m excited about this program, I’ve included below the statement of purpose I wrote for the application. If everything works out, I will begin studying part-time this Fall while still being employed full-time at Shepherd Interactive. (Note: when talking about Open Scriptures below, I don’t mention the others who are working so hard alongside me—it’s true I started it, but now it’s “my project” only in the sense that I am but a part of it.)

Statement of Purpose for Application to UW Computational Linguistics Program

Using the computer to solve linguistic problems has been a core interest of mine for the past decade. As I studied and entered the workforce as a web application developer, I have studied linguistics and languages on the side. When I started my undergraduate studies at Seattle Pacific University, I was intending to create a self-designed major in computational linguistics, but I was disappointed to find that the faculty weren’t experienced enough in this area to advise me. So I made do by majoring in computer science and minoring in both linguistics and Spanish. I thoroughly enjoyed taking CS and linguistics courses in parallel, taking concepts in one and applying them in another, for example studying the Chomsky hierarchy in my syntax course for linguistics but then applying his concepts in my compiler design CS course. Furthermore, I used my web application development skills to create relevant applications along the way, like a syntax tree drawer and a popular IPA chart keyboard tool, and I also completed various linguistics assignments by publishing them on the Web.

Although I learned much from taking computer science and linguistics in parallel, I have missed out on the focused intersection of the two in the sub-field of natural language processing. It is my desire to satisfy my initial undergraduate computational linguistic aspirations in the Master’s program at the University of Washington.

With regard to applying what I would learn in the program, I am the founder of the Open Scriptures project, an initiative which seeks to interlink the various scriptural corpora and derivative datasets to create a Linked Data infrastructure for scripture, and on top of this foundation provide a platform that allows developers to build innovative applications on top of the data available. One of the key problem areas in this endeavor is the alignment of translated texts with their source manuscripts. I had been thinking to utilize collective intelligence to power the semantic interlinking of the texts, but I have come to realize that NLP will be necessary to achieve the desired results. The concepts and techniques I learn in the Master’s program would be directly applicable to my project.

I am an advanced Spanish speaker, and I have also taken one term each of French and Koiné Greek, and two terms of Biblical Hebrew. I am especially interested in Semitic languages and corpus linguistics of the Hebrew Tanakh and the Arabic Qur’an. I am studying Arabic on my own, and have attained a novice familiarity with the language. I desire that this Master’s program in computational linguistics would be a stepping stone to further graduate studies in the field.

The data: URI scheme is now supported by the most current version of every major browser, including Internet Explorer. Because of this I wanted to use CSS background images encoded with data: URIs in a current project at Shepherd Interactive. Why? The first rule of High Performance Websites is to Minimize HTTP Requests. By storing background images directly in the stylesheet only one HTTP request is then necessary to fetch the stylesheet and the images all at once. Furthermore, by giving that stylesheet a far-future cache expiration date the browser will never need to request it again.

However, while every browser vendor’s current version supports data: URIs, older browsers like MSIE 7 do not. Therefore it is necessary to also have fallback CSS rules to serve externally-referenced background images. I came up a way of doing this by utilizing the following script which I place as an inline script in the document head:

var data = new Image();
data.onload = data.onerror = function(){
	if(this.width != 1 || this.height != 1)
		document.documentElement.className += " no-data-uri";
}
data.src = "data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///ywAAAAAAQABAAACAUwAOw==";

This script attempts to load a 1×1 pixel via a data: URI. If the onload callback fires and it detects that the image’s width and height are each a single pixel, then the browser supports data: URIs. Otherwise the browser does not support such URIs and a class name is added to the document root so that fallback CSS rules can be written, for example:

#foo {
    background-image:url("data:image/png;base64,<...>");
}
html.no-data-uri #foo {
    background-image:url("images/foo.png"); /* fallback */
}

In this way, CSS rules can define background images that utilize data: URIs only for browsers that support them, while at the same time older browsers still render the content properly due to the fallback rules. Note that for browsers that support data: URIs, the fallback CSS rule above will never be applied and thus its externally-referenced background image will never be downloaded. However, if the browser does not support data: URIs, then the resources will essentially be downloaded twice, but that’s the price you pay for using an old browser. In any case, when the images are tiny (<1KB) then the overhead is minimal for non-supporting browsers, and your development process is greatly eased since you don’t have to hassle with creating image sprites (which are sometimes impossible anyway); those who use current browser versions will be rewarded as will the generations of Internet users to come.

Please also follow Open Scriptures on Twitter.

Join in on the discussion on the Google Group.

• Phonological Analysis of a Second Language
• Arabic Phonemes Represented by the Spanish Letter “J”
• Indo-European Cognates in Psalm 23 and the Beatitudes
• El alfabeto árabe
• Hamlet Word Origin Study
• Indo-European Word History of plek

And then I found an old chart I made of my racial makup.

And then there is a little web app for SPU’s Nickerson Signal which attempts to model a traffic signal so that upcoming crossing times can be predicted. (Didn’t end up accurately modeling reality.)

And finally there is the Semantic Linking tool (mentioned in my last post) which is a prototype for an upcoming tool which enables contributors to link the semantic units between manuscripts and translations.

For the past several years, I’ve been dreaming about an open source community-driven Web application for Scripture. In the past few months, things have really been kicking into high gear. At BibleTech:2009 I’m presenting the project in the talk Open Scriptures: Picking Up the Mantle of the Re:Greek – Open Source Initiative:

Open Scriptures seeks to be a comprehensive open-source Web repository for integrated scriptural data and a general application framework for building internationalized social applications of scripture. An abundance of scriptural resources are now available online—manuscripts, translations, and annotations are all being made available by students and scholars alike at an ever-increasing rate. These diverse scriptural resources, however, are isolated from each other and fragmented across the Internet. Thus mashing up the available data into new scriptural applications is not currently possible for the community at large because the resources’ interrelationships are not systematically documented. Open Scriptures aims to establish a scriptural database for interlinked textual resources such as merged manuscripts, the differences among them, and the links between their semantic units and the semantic units of their translations. With such a foundation in place, derived scriptural data like cross-references may be stored in a translation-neutral and internationalized manner so as to be accessible to the community no matter what language they speak or version they prefer.

Think of it as a Wikipedia for scriptural data. Just as Wikipedia has become the go-to place to find open encyclopedia information, Open Scriptures seeks to be the go-to place for open scriptural data. (Non-free data could also be stored, but it would be restricted to non-commercial personal use, as Wikipedia does with fair use or by obtaining special permission.)

Interested? The project needs you! I’d love for a core group of scholars and developers to come together with the shared vision of open access to scriptural data employing open standards and best practices of the Web.