Hello Barnaby,
From your 1st post, I thought it was the Firebug bug:
http://www.happyworm.com/jquery/jplayer/latest/developer-guide.htm#jPlayer-known-issues-firebug
Glad you got it sorted out.
You raise an interesting point though... While I designed jPlayer to
work with multiple selectors during the constructor stage of the
initialization (from jPlayer 1.0.0), I had in fact never tested it.
Partly because it was using the jQuery UI core code for that bit and I
figured it would work... And also because I suppose when you get too
close to something you sometimes get the blinkers on. ie., I should
expand my tests.
I thought of a 3rd solution though... During the _init() where the ID
is got from the jPlayer <div>, we could do a check to see if it has
one. It there is no ID, then we generate one similar to what is done
for the <audio>, <embed> and hidden text <div>. That ID is written to
the <div>... It should solve the problem of using class selectors
without ID names.
Would this 3rd solution help your case?
- I think it would.
I'm wondering what problems it could cause though... If there was no
ID to begin with, the the dev would hardly set one themselves at a
later time would they? ie., after jPlayer initialized the array of
selectors found using the class.
As for the unique IDs... Well I suppose jPlayer could check somehow,
but I cannot think of a simple way for 1 instance to know all the
others... jPlayer knows what instance number it is... I guess I'd need
to store a pointer to all the instances on $.jPlayer.instanceSelector
using an array for them, then check there. I'll ponder over this one a
while. Duplicate IDs are bad in general, so it is not like jPlayer is
a special case.
What do you think of the 3rd solution that I proposed?
Best regards,
Mark P