To make multiple borders appear around an element, the traditional approach has been to nest multiple elements and apply a different border to each. For example, to put a rainbow border on an element:

This approach uses seven div elements. However, there is an alternative that avoids the need for so many superfluous elements: the new CSS3 box-shadow property. A key feature of this property is that it allows for multiple shadows to be supplied at once:

box-shadow: none | <shadow> [ , <shadow> ]*

When multiple shadows are supplied, they can be positioned on top of each other to create a multiple-border effect. Using the box-shadow property in this way requires support for the "spread radius" value, and this is not currently supported by WebKit (includes Safari and Chrome). However, Firefox 3.5 (now available as a preview release) does support the box-shadow spread radius, and if using that browser, the following example should look identical to the example above:

Using box-shadow for multiple borders not only eliminates the need for extra markup, it also allows the multiple borders to be easily rounded on corners simply by adding the border-radius property (see screenshot from Firefox 3.5):

To accomplish the above with multiple nested elements, you would have to tediously increase the border-radius for each wrapped element in order to get the corner arcs to fit together properly.

I suppose using box-shadow to implement borders is a kind of hack (the technique requires setting margins because the shadows don't effect page flow), but we're celebrating the compeltion of Firefox 3.5 by showcasing hacks like these! It would be great if multiple borders could simply be specified on a border property just as is possible with box-shadow. Each subsequent border defined could wrap around the previously defined borders. The property could be defined:

border: none | <border> [ , <border> ]*

In any case, the box-shadow property still has a benefit of allowing the borders to blend together by specifying the box-shadow's blur radius (see screenshot from Firefox 3.5):

It's exciting to see how Mozilla is implementing bleeding-edge CSS features in Firefox as we have become accustomed to from the WebKit team. Great work everyone!

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.

In spite of the closed nature of Flash, many things are currently impossible without Flash, of course. However, now with stepped up efforts by browser developers (including Gears) and the development of the HTML5 specification, the things which are impossible without Flash are dwindling. Browser vendors are rapidly implementing cutting-edge technologies such as SVG, CSS transitions and animation, HTML5’s audio, video, and canvas elements, and custom fonts with @font-face; at the same time browser developers are competing for the fastest performance with blazing new JavaScript engines such as Mozilla’s TraceMonkey, WebKit’s SquirrelFish Extreme, and Google’s V8. The JavaScript language itself is being furthered now by a new harmonious momentum on ECMAScript 3.1, some features of which the IE team has been quick to include in the upcoming IE8.

In short, the technological foundation of the Open Web has been quickly growing to provide the compelling features which Flash now makes available. Nevertheless, while the things which have depended on Flash are dwindling, it is still currently a lot harder to do these things without Flash because Adobe’s IDE makes designing and developing Flash apps relatively easy for people not intimately familiar with the technical details. What the Open Web needs, therefore, is an IDE which can provide the same level of abstraction as Adobe Flash. We need an IDE which is able to intuitively generate and manipulate the technologies of the Open Web. Mozilla’s new effort on Open Web development tools, led by Dion and Ben of Ajaxian, seems like a great start. In fact, I think it would be great if the Firebug Working Group joined this new effort, and if the Firebug extension itself would be the development tool which would be the focus of the new developer tool set.

For some inspiration, check out the Antisocial demo and its accompanying demotool.

• Tables in the schema are placed equidistantly around a circle.
• Clicking the image causes the graph to rotate.
• Foreign key constraints are represented by bézier curves connecting table labels.
• Hovering over a table or a constraint causes the table’s label to highlight along with all of its constraint paths (both incoming and outgoing).
• The paths representing incoming foreign key constraints are highlighted in a different color than outgoing constraints.
• Multiple constraints between the same two tables are prevented from overlapping by giving a unique curve to each of the lines.
• Hovering over a constraint produces a tooltip which shows the names of the fields that are linked by the constraint.

This is an open source project I developed while working at Shepherd Interactive. Find out more on the project page.