ScriptSharp, like asp.net AJAX, has the notion of behaviors, javascript code that can attach itself to DOM elements and change their, well, behavior.
As part of my spike on ScriptSharp (and I’ll have to admit having spent way too much time on it to still be called a spike), I’ve built a simple container that automatically resolves and binds behaviors to DOM elements, to reduce to a maximum the amount of inline code required within my generated pages.
The one thing I went round and round about was how to declare in markup that binding. Here’s a few solutions I tried or seen proposed through various tools.
<div style="behavior: url('myBehavior.htc')" />
This is something introduced in ie4, but it breaks the CSS standard *and* htc are only recognized by Internet Explorer. No good to me.
The next contender is…
…xml-script, and was originally presented early in the life of asp.net AJAX (back when it was called ATLAS). This is awfully verbose, and worse than that it won’t ever validate in non-xml languages (aha HTML 4.01 or XHTML5). The same is true of the proposed changes in asp.net AJAX Futures, which uses namespaces everywhere even though they’re not allowed in non xml renderings.
[Update: As Simon Pieters correctly points out in the comments, this syntax would indeed be compatible with HTML5 (the non-xml serialization one), because the definition of CDATA sections has been modified to include anything not including the closing tag. Hence what is after <script> can be anything that is not </script>. This redefined definition of a CDATA element is not something the XML specification agrees with however, which means that in all languages, aka XHTML 5.0, XHTML 1.1, XHTML 1.0 and HTML 4.01, you need to enclose the content of the script tag in a CDATA section, aka <![CDATA[ … ]]>. This makes HTML5 the only rendering with which xml-script would work. I may have misread some of those specs however, so if I have please comment and I’ll update and buy you a beer.]
In choosing how to map behaviors, I had several goals:
- declare the behaviors contextually within an element,
- being able to use the exact same notation for both HTML 4.01 (the SGML language), XHtml 1.0 and 1.1 (the XML language) and Html 5 (both the whatever it is format that is not sgml anymore *and* the xml language, as both exist)
- being able to pass additional customizations and parameters specific to an instance
- Not look too out of place.
I initially settled on an extension to the way content type definitions are expressed:
<div class="behavior/graphicscroll;horizontal=true;vertical=true;">test</div>
This says, ask the behavior family to add a graphicscroll behavior and pass it values for horizontal and vertical. All was good and I was happy with myself. For a whole five minutes.
Then you realize that while that syntax works like a charm, it is invalid in Xhtml 1.1, because the class attribute was redefined to be of type NMTOKENS, where the previous version had a type of CDATA. This is a serious breakage for content out there, and I wonder what the reason for this is.
The other issue I had with this is the need to declare the full syntax for each element I wanted to use, and I really wanted to leverage CSS selectors. One solution I would have wanted to use was to simply extend the CSS stylesheets with custom css attributes. This would have then looked like the following.
<style type="text/css">
div {
-rasta: "behavior/graphicscroll;horizontal=true;vertical=true";
}
</style>
The syntax just felt very unnatural. And worse than that, the CSS validator doesn’t validate CSS with vendor expansions, even though they are defined as such in the specification.
After twiddling around endlessly, I’ve settled on defining a css-like language, behavior stylesheets, without some of the restrictions of the existing CSS. I now have this code:
<style type="text/vnd.rasta.bss">
div
{
behavior: graphicscroll {
horizontal: true;
vertical: true;
}
}
</style>
The selector syntax is simply the CSS one, which means you can combine and match them in the same way you would define your stylesheets. The properties however are dynamic, with the first level name always matching a family of components (implemented as a loader) with a value matching the component, and a sub-group letting you define properties on that component.
You’ll notice I mentioned my first goal was for this to be contextual within the element. Because you’re still using selectors, nothing prevents you from declaring a value in your class attribute and do your selection on that. The same of course goes for ids.
Time will tell if this is as compatible with current UAs as it could be, and I have the feeling it will be ignored when necessary, but it’s extensible, simple enough, doesn’t require the script engine, leverages an existing html element and still passes in all versions of html that support the style element.
