I stumbled upon the same shit, and this is how IE8 reacts on OPTION
tags without value specified (like, blahblah). Until
jQuery is fixed to support it (and in my case I must stick to old
version 1.2.6, so fix is impossible) the workaround is to always use
blahblah notation, if possible. Of
course i
cking element's
display attribute back to static after unblocking?
Thanks a ton in advance,
snobo
On Jun 19, 7:36 pm, Mike Alsup wrote:
> > Yes it is modified, because the div itself (not the blocking overlay) comes
> > over the ul/li elements when calling blockUI on it.
>
> To
ists or invalid'
},
...
}
so, in case the input value is invalid, my custom message is correctly
displayed, but only on blur. On submit, when I click the submit
button, the default message ("Please fix this field") is displayed.
How can this be fixed?
On
he plugin skip
> the method. Otherwise, delegate to the default remote method to
> perform its task.
>
> Let me know if that works for you, might be worthwhile adding to the
> docs (until depends/remote is fixed).
>
> Jörn
>
> On Fri, Apr 17, 2009 at 3:34 PM, snobo wrote
would check the condition first and
then making an AJAX call manually only if needed...
On Apr 17, 4:16 pm, Jörn Zaefferer
wrote:
> This is indeed a bug, in this case something never tested for.
>
> Is using required: function() {} together with remote an option?
>
> Jörn
>
> On
I've been trying to use remote method coupled with depends, like this:
remote: {
depends: function(element) { element.value = $.trim(element.value);
return element.defaultValue != element.value; },
url: 'my.php',
type: 'post',
data: { action: 'check_user_name' }
}
emo/tabs/
>
> Jörn
>
>
>
>
>
> On Fri, Apr 17, 2009 at 12:26 PM, snobo wrote:
>
> > Hi Jörn,
>
> > incredibly awesome plugin you've made, thanks a million! Started to
> > explore and using it, and stumbled onto situation.
>
> > In my invalid
Hi Jörn,
incredibly awesome plugin you've made, thanks a million! Started to
explore and using it, and stumbled onto situation.
In my invalidHandler, I'm trying to access the first input which is
marked as invalid (in order to ensure that it is visible - my form is
split on tabs, and I need to s
I've stumbled upon a wicked problem, which appears only in 1.3.2
(works ok in 1.3.1, 1.3.0 and 1.2.6), and only in Safari (3.2.2 on
Windows) (works ok in FF2/3, IE6/7, Opera). To cut a long story short,
here's the test case:
http://tmp.ahlers.com/test/safari-132.html
My application employs Flexi
d takes the WIDTH OF THE CONTAINER (td), which is way bigger - 330px
in my case. Needless to say, the container turns to be excessively
wide.
I worked this around by enclosing my original SELECTs in a span. But
the question to the developers of LinkSelect - is it the intended and
correct behavio
I was going to modify the standard "digit" parser for the tableSorter
plugin to fix the other problem I reported here:
http://groups.google.com/group/jquery-en/browse_frm/thread/c5d1ecc422e68a89
but I found out that it seems impossible. It's very easy to add a new
parser using $.tablesorter.addP
By default, tableSorter assumes that decimal point character is '.',
and assigns a "text" parser to a column that contain strings like
"123,45". There is an undocumented (why?) property "decimal", which
helps tableSorter understand that these are in fact numbers:
$(...).tablesorter( { decimal: ',
tr('rowspan',1).
FF forgives and understands all of the above. Weird...
On May 29, 9:19 am, snobo <[EMAIL PROTECTED]> wrote:
> Huh, interesting! Indeed, specifying an attribute in lowercase makes
> it work.
>
> All in all, it seems like a inconsistency to me, that att
e same problem when I upgraded to 1.2.6 and using
> "rowspan" instead of "rowSpan" fixed it. I guess it was a bug fix.
>
> On May 27, 1:27 pm,snobo<[EMAIL PROTECTED]> wrote:
>
> > Since upgrading to 1.2.5 (the same applies to1.2.6), an attempt to $
>
Since upgrading to 1.2.5 (the same applies to 1.2.6), an attempt to $
('... td').removeAttr('rowSpan') triggers an error in IE6/7.
Previously (up to 1.2.4b) it effectively set rowSpan to 1. It still
works that way in FF.
I'm not sure is it a bug or a feature, but of course it has broken my
applic
I stumbled upon a tricky situation. In my app, I use UI Dialogs based
on my 's. When a dialog is created, it takes the out of
the HTML context where it was originally located, moves before the
closing tag and wraps it with all these dialog divs, buttons
etc. But when my AJAX calls replace body c
Excellent, exactly what I needed! Thanx a lot for quick fix!
cheers,
snobo
On Apr 29, 2:21 am, "Mike Alsup" <[EMAIL PROTECTED]> wrote:
> v2.03 is available now. This page demos how to use the new position stuff:
>
> http://malsup.com/jquery/block/position.html
>
> Mike
>
27;s height at this particular moment.
And because I need a constant offset from the top of the blocked area,
currently the only solution that works for me is commenting a line in
the BlockUI source code. :( Ugh :(
-=snobo=-
On Apr 25, 5:49 pm, "Mike Alsup" <[EMAIL PROTECTED]> wrote:
orse than on FF.
On Apr 25, 8:06 pm, "Richard D. Worth" <[EMAIL PROTECTED]> wrote:
> Which plugin are you using? Also, which browser and OS?
>
> - Richard
>
> On Fri, Apr 25, 2008 at 9:27 AM, snobo <[EMAIL PROTECTED]> wrote:
>
> > hi,
>
> &g
hi,
when using modal dialogs with more or less complicated forms inside,
working with form controls gets noticeably slow, at least on Pentium 4
2.6 GHz. Opening drop-downs, pressing buttons, typing in the input
fields - all actions with a noticeable delay. I understand that in
order to make a dia
Hi,
the message is always centered horizontally+vertically within the
blocked area. I need the possibility to switch it off, the reason:
when I block a long screen section, the vertically centered message
might often displayed invisible for a user (below the bottom of the
screen!). It seems there
21 matches
Mail list logo
