And then with a separate behavior sheet.
<img src=Cheddar.png alt="Pungent Orange Cheddar Cheese" data-type=food-dairy-cheese-cheddar data-smell=pungent data-color=orange>
And the Behavior Sheet
<style type="text/behavior2.0">
[data-type|=food-dairy-cheese]{
@behavior Sing {
type: show tune;
speed: fast;
}
@behavior Dance {
type: waltz;
speed: slow
}
}
</style>
Or flat…
<style type="text/behavior2.0">
[data-type|=food-dairy-cheese]{
sing-type: showtune;
sing-speed: fast;
dance-type: waltz;
dance-speed: slow
}
</style>
Or flat with shortcuts!
<style type="text/behavior2.0">
[data-type|=food-dairy-cheese]{
sing: showtune fast;
dance: waltz slow
}
</style>
Or as JSON
<script type="text/behavior-json2.0" charset="utf-8">
{
"[data-type|=food-dairy-cheese]": {
"sing": ["showtune", "fast"],
"dance": ["waltz", "slow"]
}
}
</script>
The reasoning behind wanting Behavior Sheets is the obvious scaling issue of putting declarative behavior info into your HTML.
It's the exact same scaling issue of embedding unrelated style into into style attributes in all our tags.
If it is unrelated to what that element it and what it's primary purpose for existence is, it should be separated out into a separate layer.
However, the flexibility of simply creating a massive
domready
function in your JS code tends to lead to massive amounts of code living in a single massive function.You would choose to use something like a declarative markup syntax when you want to expose a very strict and limited API for some developers without allowing them to add any freeform data.
You would likely not choose a declarative syntax if you are a freelancer or work in a team of 3 and everyone works on the frontend and backend.