+2  A: 

I kind of understand where you are coming from and the only advice I can give you on this is to look into the eval() tag. The eval() function evaluates and/or executes a string of JavaScript code. First, eval() determines if the argument is a valid string, then eval() parses the string looking for JavaScript code. If it finds any JavaScript code, it will be executed.

So you could parse the text inside of a DIV or any element by using the eval() tag. Sorry I couldn't help you further.

Dwayne
Ok, this is a step closer I think - I'd forgotten about eval(). Is eval() considered bad practice? I've heard various things, the idea of executing any string as javascript, via a method call sounds sketchy...
Danjah
To be honest eval() is more resource intensive than it is a security risk (at least in JavaScript), unless you're passing user information. Eval() is considered more dangerous in languages like PHP for example than JS.Here are some caveats of using eval() in Javascript:1. Improper use of eval opens up your code for injection attacks2. Debugging can be more challenging (no line numbers, etc.)3. Eval'd code executes more slowly (no opportunity to compile/cache eval'd code)4. Each invocation of eval() creates a new instance of the JavaScript interpreter. This can be a resource hog.
Dwayne
Thanks Dwayne, yeah I'm in agreement about eval() now - did some reading around the risks/benefits. In my case there is almost zero risk and the problem it solves for me has a large pay-off. Also in my case, eval() might only ever be run once per appropriate element found, and that might only ever be up to 5 elements on a page, so 5 evals. If I'm wrong in thinking this isn't a performance hit.... please correct me :P
Danjah
The degradation of performance would probably not even be noticeable unless you're profiling your Javascript with Firebug or something, if anything it might add a few extra milliseconds. I'd say you are safe with 5 eval's, provided you're not executing large chunks of Javascript for per eval().
Dwayne
A: 

Why not

<div class="thing virgin">
  <script>
    var newElems = yd.getElementsBy(function(el){
     return yd.hasClass(el,'thing') && yd.hasClass(el, 'virgin');
    },null,document );
    // find the 'virgin's and remove the 'virgin' class from them as you init?
  <script>
</div>

You could of course remove the <script> tag entirely if you are adding this element via javascript, and just execute the code on the elements you create.

gnarf
Not sure this is going to benefit me more than what I'm currently doing. As it stands, I do currently have everything being executed in an external file, but that file gets loaded on potentially hundreds of pages - so it is a common file. I definately won't have the same config requirements from <div class="thing"> #1 and <div class="thing"> #69, between pages 1 and 200 - if you catch my meaning. So far I can either define config objects in a 'bank' of info, identified by an instantiated Thing() object by the URL of the page it resides within, or do the config within a script block as above :/
Danjah