Wednesday, January 21st, 2009
JavaScript Behavior Sheet
Bertrand Le Roy of Microsoft is experimenting with JavaScript Behavior Sheets, a way to separate styling, markup, and behaviour.
He has created a notion of a behaviour file that uses CSS to tie in the behaviour:
-
-
<script type="text/behavior" src="BehaviorSheet.jss"></script>
-
The experiment uses a JSON object for now (e.g. the quotes):
-
-
"input[type=text].nomorethanfive": {
-
click: function(e) {
-
alert("You clicked input #" + e.target.id);
-
},
-
"Bleroy.Sample.CharCount": {
-
maxLength: 5,
-
overflow: function(source, args) {
-
$(source.get_element()).jFade({
-
property: 'background',
-
start: 'FFFF00',
-
end: 'FFFFFF',
-
steps: 25,
-
duration: 30
-
});
-
}
-
}
-
}
-
He also discusses jQuery and how reglib is playing in this world too. What about separating layout from style? :)












I’ve actually been working on a similar concept for awhile (based on E4X for the selector syntax). It’s good to see a different approach for some ideas.
Isn’t this just the same as dojo.behavior ? Dojo’s had that for a while now – http://docs.dojocampus.org/dojo/behavior
@sos: Dojo behavior or the way some jQuery plug-ins work come pretty close, but in an imperative way. Here, I’m playing with a more *declarative* approach that aims at clean separation of style, behavior and markup.
Doesn’t Dojo already have declarative? I’m confused.
I like that this does class instantiation, something dojo.behavior does not do. It would be trivial though, the behaviors are just css selectors with functionality, and dojo.behavior just wraps dojo.query, and dojo.query has an .instantiate(classname, {props}) … just a matter implementing it.
.
I find behaviors great in small cases, but tedious to manage on a larger scale. Automating delegation within sets of selectors for these behaviors (sort of like jq’s new .live() or reglib) would be really cool, too.
@Nosredna: afaik, Dojo does its declarative markup directly on the HTML tag, whereas here the coupling with the markup is both declarative and done through selectors. So declarative has been done to death, doing stuff imperatively to a selected set has been done to death. It’s this particular combination of declarative and coupling through selectors that I’m experimenting with.
BertrandLeRoy,
.
I see. Thanks for the explanation.
First of all, I have to say adding yet another event system without implementing the W3C event model is not a very nice thing to do to web developers.
.
Secondly, I think this declarative event model, though interesting, is not going to be that useful in the real world because of one important point: scope. Most event handlers that I implement have a specific scope, which is not the element on which they’re executing. With script-attached event handlers, it’s easy to set a different scope, but in a declarative model it’s basically impossible because you can’t refer to instances.