• Fixed the way that {attributes} are handled when not using a selector. They should now properly grab the attribute from element that fired the event.
• Made it so each time a declaration block is applied, all the event handlers bound by JSS to the elements returned by that selector are unbound.
• Fixed the semantics of the {@attr} syntax. It now means that the eventTarget should always be used, regardless of whether or not a selector is defined. In order to access the attributes of a selector use {@attr} now.
• Added two new commands: set-data and remove-data. These commands use the jQuery functions data() and removeData(). They are similar to set-attr and remove-attr except instead of storing the information in an attribute, they are stored in a table. Data is accessed by using [data] syntax, similar to the {attr} syntax.
• Added new event property: setup. This event is fired when the JSS stylesheet is loaded (setup). This is useful in certain cases where the user wants to setup some variables using set-data.
• Made it so you can now set scroll-top and scroll-left via the set-attr command.
• Added trigger command. It can be used to trigger event properties on elements.
• Fixed bug where you could put a string | in a binary command due to the
  simplistic implementation. The new version requires any | to be escaped with \|.
• Added fade-to command, based on the jQuery.fadeTo() command.
• Added show and hide commands.
• Fixed issue with data and attribute replacements not working correctly (i.e. the first event would replace them for all events).
• Callbacks may now take string parameters. For example, “fade-out (#target) normal !callback str1 str2″.

I’ve also started writing documentation for the JSS commands. It is only partially completed but can still be helpful. Check out the JSS homepage for other documentation.

Cascading Style Sheets (CSS) is a style sheet language used to describe the presentation (that is, the look and formatting) of a document written in a markup language.

If that blurb were written about JSS, it’d sound a little like this:

JavaScript Style Sheets (JSS) is a style sheet language used to describe the presentation (that is, the look and formatting) and functionality of a document written in HTML.

In this article, we will look at the syntactic structure of a JSS stylesheet. We will also talk briefly about including JSS stylesheets in your HTML documents.

At this point, some people may be wondering: aren’t we mucking up CSS by combining functionality and presentation in the same place? This is a valid concern. However, just because we can combine presentation and functionality in JSS, doesn’t necessarily mean we should. A good JSS site will have two or more JSS stylesheets: one for JSS styles (if they are needed) and one for JSS event properties. JSS event properties will be covered in a future article.

Syntactic Structure

Let’s get back to the CSS/JSS connection. What do people do with CSS? They write stylesheets. More specifically, they write rules. In JSS, we write rules too. In fact, we write them in a very similar format to CSS, although with some important differences owing to the fact that JSS stylesheets are actually JavaScript programs. Here’s the basic format of a CSS stylesheet:

rule-selector-a
{
  property-a: value-a;
  property-b: value-b;
  ...
}
 
rule-selector-b
{
  property-a: value-a;
  property-b: value-b;
  ...
}
 
...

In JSS, we use pretty much the same format, with the differences being the addition of boilerplate code (1), quoted selectors with colons (2), underscores instead of dashes in property names (3), quoted values with commas (4) and commas between rules (5). The JSS format is shown below:

$.jss.declare({ // (1)
 
"rule-selector-a": // (2)
{
  property_a: "value-a", // (3) and (4)
  property_b: "value-b",
  ...
}, // (5)
 
"rule-selector-b":
{
  property_a: "value-a",
  property_b: "value-b",
  ...
},
 
...
}); // (1)

Let’s talk a bit about each of these difference:

1. Boilerplate code. This is an unfortunate side effect of having to use JavaScript to extend CSS. Fortunately, it’s the same for each JSS stylesheet, so it’s not too much of a hassle to remember.
2. Quoted selectors with colons. Since the selector portion of a JSS rule is a string, it must be represented in JSS as a JavaScript string. All strings in JavaScript must be either single-quoted (as in ‘Hello!’) or double-quoted (as in “w00t w00t”). The colon following the selector is a necessity as internally, JSS selectors act as keys in a JavaScript object. A JSS selector may be any valid jQuery selector.
3. Underscores instead of dashes in property names. This is not strictly true, although using underscores instead of dashes is the recommended way of representing JSS properties. Consider, for example, the font-family property from CSS. This can be represented in 3 ways in JSS:
   1. font_family
   2. “font_family”
   3. “font-family”
4. Quoted values with commas. Unlike CSS, all values in JSS are quoted with either single or double quotes. Furthermore, between declarations, there must be a comma.
   
   

   // This is correct.
   "rule-selector-a":
   {
     property_a: "value-a",
     property_b: "value-b"
   },
    
   // This is incorrect.
   "rule-selector-b":
   {
     property_a: "value-a",
     property_b: "value-b", // This declaration should not 
                            // have a comma.
   }

5. Commas between rules. Like declarations, each rule must have a comma between it:

   "rule-selector-a":
   { ... },
    
   "rule-selector-b":
   { ... } // Make sure the last rule has no comma after it.

Loading JSS and JSS stylesheets

Now that we understand the syntactic structure of a JSS stylesheet, it’s time to take look at how we include them in an HTML file. Every page that makes use of JSS will have the following structure:

<html>
  <head>
    <title>Title</title>
    <script type="text/javascript" src="jquery.js"></script>
    <script type="text/javascript" src="jquery.jss.js"></script>
    <script type="text/javascript" src="sheet-1.jss.js"></script>
    <script type="text/javascript" src="sheet-2.jss.js"></script>
    ...
    <script type="text/javascript" src="sheet-n.jss.js"></script>
  </head>
  <body>
    <!-- Your website here. -->
  </body>
</html>

Let’s quickly go through the components here. The first script tag includes the jQuery library, which is required by JSS. The second script tag includes the JSS jQuery plugin, which is the brains of JSS, and is required for any JSS stylesheet to work. All the script tags after that are the JSS stylesheets that you wish to load.

As you can see, you can add an unlimited number of JSS stylesheets, and when the page loads, they’ll be applied in the same order they are included in the page. Keep in mind, however, that if you’re including many script tags on a single webpage, it is advisable to use some sort of JavaScript loader.

Consider these two images:

Imagine we wanted to make them “rollover”, i.e. the zebra should be shown when nothing is happening, and the shark should be showed when the mouse is “rolled over” (i.e. on top of) the zebra. Like this:

Before we start writing some JSS, let’s write some HTML for a page just showing the rollover at rest (i.e. just show a plain old static image):

<html>
  <head>
    <title>JSS Rollover</title>
  </head>
  <body>
    <img src="image_off.png" />
  </body>
</html>

If we copied this code into an HTML file and ran it on our browser, we would see a static image of a zebra. Not that exciting, right? Now let’s see how we can use JSS to make this zebra “rollover” to the shark when the mouse is on it. Here’s the JSS stylesheet:

$.jss.declare({
 
  "img[src-over]":
  {
    hover: "set-attr src {src-over} | set-attr src {src-out}"
  }
 
});

Let’s step through this syntax, because there’s a lot going on here, even though it’s a single line. First, let’s annotate the JSS source so we can refer to it easier:

$.jss.declare({ // 1. Boilerplate that starts any JSS stylesheet.
 
  // 2. Rule
  "img[src-over]": // 3. CSS Selector
  {
    // 4. JSS Declaration
    hover: "set-attr src {src-over} | set-attr src {src-out}"
  }
 
});

As you might have noticed, a JSS stylesheet looks very similar to a CSS stylesheet. Let’s walk through the anatomy of a JSS stylesheet.

At the top of any JSS stylesheet there is some boilerplate code (1). This is necessary because a JSS stylesheet is actually a JavaScript program. However, beyond the fact that this boilerplate needs to be in every JSS stylesheet, you don’t really need to know what it does.

A JSS stylesheet is made up of an unlimited number of rules (2). This is the same as in a CSS stylesheet. Inside a JSS rule, there are two components, a selector (3) and an unlimited number of declarations (inside a declaration block) (4). This is where we start to see some of the advantages of JSS over using plain CSS.

JSS selectors are powered by jQuery. As such, JSS supports any CSS3-compliant selector. In addition, JSS also allows you to use any of the jQuery CSS selector extensions as well.

For example, in CSS, this stylesheet should stripe all the tables on the page as alternating gray and white:

table tr:nth-child(odd)
{ background-color: #eee; }
 
table tr:nth-child(even)
{ background-color: #fff; }

However, if you tried to use that CSS stylesheet in the two most popular browsers available (IE7 and Firefox 3) you would discover that it didn’t work. On the other hand, if you use the following JSS stylesheet…

$.jss.declare({
 
  "table tr:nth-child(odd)":
  { background_color: "#eee" }
 
  "table tr:nth-child(even)":
  { background_color: "#fff" }
 
});

…you would discover that it worked in all major browsers. By using a JavaScript selector engine, JSS offers better cross-browser styling than regular CSS.

(Aside: Before all you web developers out there go crazy, I would like to note that I realize there are several drawbacks to using JavaScript to style your page. Stay tuned to the end of this article for a discussion of them).

Now let’s return to our task of making a rollover. How does the JSS stylesheet make it possible? Let’s take a look at that JSS stylesheet again:

$.jss.declare({ // 1. Boilerplate that starts any JSS stylesheet.
 
  // 2. Rule
  "img[src-over]": // 3. CSS Selector
  {
    // 4. JSS Declaration
    hover: "set-attr src {src-over} | set-attr src {src-out}"
  }
 
});

Let’s look closer at the rule. More specifically, take a look at the CSS selector. For anyone familiar CSS, it reads “select all img tags that have the attribute src-over”. Why would we want to do that? Well, as it happens, we need some way to describe which image to use when the user mouses over our image. In order to do that, we’re going to use something called a custom attribute.

Custom attributes are user-defined attributes on HTML tags. For example, the img tag has an attribute called src. That’s a proper attribute that is defined in a W3C recommendation. What we’re going to do is add two new attributes, src-over and src-out, that are not part of any W3C standard. We just made them up because they’re convenient for our purposes.

Now that we’ve decided that we’re adding these two attributes, we need to add them to our HTML file:

<html>
  <head>
    <title>JSS Rollover</title>
  </head>
  <body>
    <img src="image_off.png"
        src-out="image_off.png" src-over="image_on.png" />
  </body>
</html>

With that done, let’s take a look at the last part of the JSS stylesheet: the declaration. A JSS declaration has a property (hover) and a value (“set-attr src {src-over} | set-attr src {src-out}”). This is just like a CSS declaration, like “font-family: Arial, sans-serif”. In that case, “font-family” is the property and “Arial, sans-serif” is the value.

In the case of the rollover JSS stylesheet, the hover property must have a value with the following structure:

hover: "jss-expression | jss-expression"

The first JSS expression on the left is run when the mouse is over the image area, and the right JSS expression is run when the mouse leaves the image area.

Let’s look at what happens in the JSS rollover stylesheet when the mouse is brought over the image area:

set-attr src {src-over}

This JSS expression reads: “set the src attribute (of the selected element) to the contents of the src-over attribute (of the selected element)”. This is because “set-attr” is a JSS command. The “set-attr” command takes two arguments: the attribute to change, and the value to change it to. That leaves one more question. What’s the deal with the curly braces?

In JSS, curly braces are basically a “get-attr” command. They fetch the value of an attribute. In the context they are being used here, they fetch the value of the “src-over” attribute (which happens to be the name of the shark image “image_on.gif”).

With that information in hand, it can be deduced that the right hand side…

set-attr src {src-out}

…switches the src attribute back to src-out image URL when the mouse leaves the image area.

Thus, if we put it all together, and include the appropriate JavaScript files, we have the following. In the “index.html” file we have:

<html>
  <head>
    <title>JSS Rollover</title>
    <script type='text/javascript' src='jquery.js'></script>
    <script type='text/javascript' src='jquery.jss.js'></script>
    <script type='text/javascript' src='styles.jss.js'></script>
  </head>
  <body>
    <img src="image_off.png"
        src-off="image_off.png" src-over="image_on.png" />
  </body>
</html>

And in the “styles.jss.js” file we have this:

$.jss.declare({
 
  "img[src-over]":
  {
    hover: "set-attr src {src-over} | set-attr src {src-out}"
  }
 
});

These files together create a page that has a rollover that changes from zebra to shark when the mouse is hovered over it. Better yet, this JSS stylesheet can be used with any web page to enable rollover images. All the user has to do is set the “src-over” and “src-out” custom attributes.

Notes on JSS Availability & Performance

JSS applies its stylesheets using JavaScript. This has several implications to web designers using it. First of all, in order for a site to take advantage of JSS, JavaScript must be enabled. Fortunately, something like 95% of all web surfers have JavaScript enabled, so that’s not too big of deal. Secondly, JSS is a lot slower than CSS. For most websites, this difference will probably be imperceptible deal, but it’s still something to be aware of.

My recommendations would be this: if you can do it in CSS, and it works properly across all browsers, then use CSS. There’s no reason not to. However, if you need to use JSS features like event properties (like hover) or cross-browser selectors, then use JSS.

The String Concatenation Approach

Whatever your reason is for generating HTML, the best bet is your first prototype looked something like this:

(Aside: All this code is in VB.NET… the original VB.NET (i.e. not 2005 or later). It also assumes ASP.NET 1.1. This is because the client I work for still uses this technology, so all my experience is with it. The code should still be fine though, as all versions of .NET after 1.1 are more or less backwards compatible.)

' Run some query on the database.
Dim dataTable As DataTable = Query()
 
' Dump it into an HTML document.
Response.Write("<html>" + Environment.NewLine)
Response.Write("<head><title>Database Table</title></head>")
Response.Write(Environment.NewLine)
Response.Write("<body>" + Environment.NewLine)
Response.Write("<table>" + Environment.NewLine)
 
' Print the rows.
For Each row As DataRow In dataTable
  Response.Write("<tr>")
  ' Print the cells.
  For Each item As Object In row
    If IsDBNull(item) = False Then
      Response.Write("<td>" + CStr(item) + "</td>")
    Else
      Response.Write("<td>&nbsp;</td>")
    End If
  End For
  Response.Write("</tr>")
End For
 
Response.Write("</table>" + Environment.NewLine)
Response.Write("</body>" + Environment.NewLine)
Response.Write("</html>" + Environment.NewLine)

Now don’t get me wrong, this code will do the trick. But as you write it, you start to feel a bit dirty. HTML is a language for representing hierarchies, yet you’re concatenating strings. You start to feel like there’s a more elegant way to do it, a way that takes advantage of the structure of HTML.

And there is.

The Programmatic Approach

Ok, so we want to take an approach that has some knowledge of the HTML we’re writing. Enter XML. .NET uses XML for, among other things, it’s Javadoc-like documentation generator and it’s ASP.NET config files. With XML so prevalent in .NET, it’s not surprising to discover that it’s part of the standard library, in the namespace System.Xml.

So you’re thinking “Cameron, who cares about XML, I want to make an HTML document!” Gear down, sugar plum, XML can still help! As you may or may not know, HTML (at least the XHTML dialects) is a reformulation of XML. That is, an XHTML document is an XML document. As a result, we can use .NET’s built-in XML support to generate an HTML document.

Thus, if we want to write the same code in previous example in .NET XML, we would do the following. First, we would need to make a new XML document. That’s easy enough:

Imports System.Xml
 
' Create a new XML document.
Dim xmlDoc As XmlDocument = New XmlDocument

Now we want to start writing some HTML. So let’s create our html tag and add some headers.

' Create the html tag.
Dim xmlRoot As XmlElement = xmlDoc.CreateElement("html")
xmlDoc.AppendChild(xmlRoot)
 
' Create the head tag and append it under the html element.
Dim xmlHead As XmlElement = xmlDoc.CreateElement("head")
xmlRoot.AppendChild(xmlHead)
 
' Create the title tag, set it's text to "Database Table"
' and append it under the head element.
Dim xmlTitle As XmlElement = xmlDoc.CreateElement("title")
xmlTitle.AppendChild(xmlDoc.CreateTextNode("Database Table"))
xmlHead.AppendChild(xmlTitle)

Wow, that’s a lot of code. What’s going on there? First, let’s look at the XmlDocument class. This is important when we’re generating XML documents. It’s what we use to create new elements. However, even though it creates new elements, it doesn’t add them to the document. Thus, we need to use the AppendChild method of the appropriate element to add it to the document. As you can see above, we created a root element (html) and added that to the XML document (xmlDoc) first. Then we created a head element, and added that to the root element, not the xmlDoc. This was done in order to form a hierarchy, which is, in essence, what a XML (and by extension HTML) document is.

Here is what the resulting XML/XHTML document would look like so far:

<html>
  <head>
    <title>Database Table</title>
  </head>
</html>

So far so good, let’s finish it off. Here’s the rest of the code we’d need to make our simple HTML document:

' Create the body element and append it to the root.
Dim xmlBody As XmlElement = xmlDoc.CreateElement("body")
xmlRoot.AppendChild(xmlBody)
 
' Create the table and append it.
Dim xmlTable As XmlElement = xmlDoc.CreateElement("table")
xmlBody.AppendChild(xmlTable)
 
' Create the rows.
For Each row As DataRow In dataTable
  Dim xmlRow As XmlElement = xmlDoc.CreateElement("tr")
  xmlTable.AppendChild(xmlRow)
 
  ' Create the cells.
  For Each item As Object In row
    Dim content As String = ""
    If IsDBNull(item) = False Then content = CStr(item)
    Dim xmlCell As XmlElement = xmlDoc.createElement("td")
    xmlCell.AppendChild(xmlDoc.createTextNode(content))
    xmlRow.AppendChild(xmlCell)
  End For
End For
 
' Write the XML/HTML document.
Response.Write(xmlDoc.OuterXml)

And there you have it: a programmatic way to generate an HTML document. So why bother? Here’s a few reasons:

Safety. If you generate your HTML document by concatenating strings, there’s a chance you might forget to close a tag. If you generate the document programmatically, you can ensure that all your tags will always be closed.

Maintainability and readability. I’ve had to deal with code where the HTML is generated by concatenation. It’s confusing and frustrating. If you generate your HTML documents programmatically, it’s a lot easier for a future programmer to follow what’s going on (especially if you, y’know, document it).

Reusability and modifiability. If you create your HTML document as a flat string, it makes it really hard to modify and reuse elsewhere in your code. For example, if you wanted to add a tag in the middle of your HTML document using the string concatenation method, you will have to do a lot of painful string manipulations. With the programmatic approach, it’s as simple as just calling AppendChild on the appropriate XmlElement.

Using an XmlDocument to represent an XML document just makes sense. It’s less crude and more versatile.

(Disclaimer: This method has been found to break if the a cell has a line break in it or is wrapped to a second line).

First, let’s start with an example table:

<table id="example-table">
  <thead>
    <tr><th>First Name</th><th>Last Name</th><th>Client #</th></tr>
  </thead>
  <tbody>
    <tr><td>Joe</td><td>Shmoe</td><td>123451</td></tr>
    <tr><td>Joe</td><td>Shmoe</td><td>123451</td></tr>
    <tr><td>Joe</td><td>Shmoe</td><td>123451</td></tr>
    <tr><td>Joe</td><td>Shmoe</td><td>123451</td></tr>
    <!-- Repeat these many times to make it go to a second page. -->
  </tbody>
</table>

Add a stylesheet like this:

#example-table
{
  border: 1px black solid;
  border-collapse: collapse;
}
 
#example-table th, #example-table td
{
  border: 1px black solid;
}

If you repeat those rows enough times you can get the graphical glitch mentioned above. Now, to fix it, what we’ll do is add a <div> tag to every cell and then make it provide the side borders.

So first, we’ll modify the table as follows:

<table id="example-table">
  <thead>
    <tr><th>First Name</th><th>Last Name</th><th>Client #</th></tr>
  </thead>
  <tbody>
    <tr>
      <td><div class="cell">Joe</div></td>
      <td><div class="cell">Shmoe</div></td>
      <td class="last-col"><div class="cell">123451</div></td>
    </tr>    
    <!-- Repeat this many times to make it go to a second page. -->
  </tbody>
</table>

What we’ve done here is added a <div> to each cell and given these <div>‘s a class called cell. This is so we can do stuff to them in our CSS stylesheet. We’ve also given the last cell in each row the class last-col. This is so we can identify the last column of each row. The reasoning for this will be explained shortly.

Now, as I’ve said, our goal here is to replace the table-provided vertical borders (the | ones) with the div-provided ones. So we need to modify the stylesheet to reflect that:

#example-table
{
  border-top: 1px black solid;
  border-bottom: 1px black solid;
  border-collapse: collapse;
}
 
#example-table th, #example-table td
{
  border-top: 1px black solid;
  border-bottom: 1px black solid;
}

There’s also an issue of padding. By default, tables are slightly padded, which is fine for most circumstances. However, in this case, padding would be counterproductive, it would prevent the div‘s border from matching up with the table‘s border. So that’ll have to be changed:

#example-table
{
  border-top: 1px black solid;
  border-bottom: 1px black solid;
  border-collapse: collapse;
}
 
#example-table th, #example-table td
{
  border-top: 1px black solid;
  border-bottom: 1px black solid;
  padding: 0;
}

Time for some div styling. Since the div is our new cell, we need to style it as such. First thing, let’s make the div provide us with sides. Now, we could do something like border-left: 1px black solid; border-right: 1px black solid;. This would look fine, except that all the vertical borders in the middle of the table would 2 pixels wide (think about it). So, instead, we’ll make all the div cells provide borders on the left side, except for the last column, which’ll provide borders on both sides (hence the purpose of the last-col class).

div.cell
{
  border-left: 1px black solid;
}
 
#example-table .last-col div.cell
{
  border-right: 1px black solid;
}

We also need to add back the padding we stripped out from the table td tags:

div.cell
{
  border-left: 1px black solid;
  padding: 4px;
}
 
#example-table .last-col div.cell
{
  border-right: 1px black solid;
}

And there you have it. Now when you load up print preview, your tables should look pretty. Here’s the final stylesheet in case you got lost:

/* So the headers will display on every page. */
thead { display: table-header-group; }
 
/* Make table only provides vertical border. */
#example-table
{
  border-top: 1px black solid;
  border-bottom: 1px black solid;
  border-collapse: collapse;
}
 
/* 
 * Make header and normal cells only show top and bottom border,
 * and remove all padding so the div lines will match up with the table.
 */
#example-table th, #example-table td
{
  border-top: 1px black solid;
  border-bottom: 1px black solid;
  padding: 0;
}
 
/* Make the div cell only provide the left border, and simulate table padding. */
div.cell
{
  border-left: 1px black solid;
  padding: 4px;
}
 
/* Provide the right border in the last column. */
#example-table .last-col div.cell
{
  border-right: 1px black solid;
}

Basically, I’m making a system that displays tables grabbed from an Oracle database using elaborate queries.  That’s the easy part.  These tables need to be printed out.  That’s the hard part. We’ll talk about that here, specifically in relation to IE7 (the hacks here might not work for Firefox or Chrome).

(Disclaimer: This method has been found to break if the a cell has a line break in it or is wrapped to a second line).

CSS has a mechanism for handling printing.  When we link in a stylesheet with the <link> tag, we have the option to set an attribute for its media type.

For example, here’s an HTML snippet that would define two stylesheets:

<link media="screen" href="styles/style.css" type="text/css" rel="stylesheet" />
<link media="print" href="styles/style.print.css" type="text/css" rel="stylesheet" />

The main thing to notice here is that media='screen' is the stylesheet for the browser, and media='print' is the stylesheet for the printer.

Why is this useful? Well, typically there are many things we want to show in a browser window but we don’t want to print on a page. If we’re going to print a table (and only a table) we’ll need to hide our navigation bar, buttons, and rotating skull .gifs. To do that, we need to go through our print stylesheet and add in display='none' for all the elements that we don’t want shown.

Once we’ve hidden all the non-table elements, it’s time to see how our page would look printed. So we load up print preview and take a look.  Ugh, the table headers show only on the first page, but not on the ensuing pages (example ), even though we’re using the <thead> tag.  Fortunately for us, this is easily corrected with the following CSS:

thead { display: table-header-group; }

With the heading problem fixed, we look again at the print preview. Everything looks a lot nicer, except for  this really ugly looking graphical problem with multi-page tables.  One solution, suggested by Xefteri, is to do away with the vertical lines in your table.

I don’t think that’s good enough.  So I came up with a better (albeit slower) solution using <div> tags within each of the cells and using them to put the vertical lines into the table.  This will be explained in further detail in a future post.