On 13 Feb., 01:03, weepy wrote:
> I would still expect that the string you get back from the dom would
> be valid html.
Where is that invalid HTML?
--Klaus
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery
I set a breakpoint at line 899 and inspected the div variable. It
seems to be bound a phantom document that does not have any attributes
(e.g., the xmlns:lift="..." attribute).
This div is created in line 850 (div = context.createElement("div");)
Hope this helps.
On Feb 12, 9:24 pm, David Poll
Hi, I was working with Kelvin Luck's great jScrollPane library, and
found that it would stop rendering the scrollbars if I set a max-
height property in the css.
I found this conditional statement (things were cropped and pasted to
just give the gist of the problem):
$this = $(this);
va
On Feb 12, 7:37 pm, John Resig wrote:
> I'm trying to figure out if this is something that's blockUI-specific.
> What happens if you do:
> $("#hi").html('Hi');
That fails in the same way on line 899 of jQuery 1.3.1.
>
> Inside your try/catch.
>
> --John
>
> On Thu, Feb 12, 2009 at 10:08 PM, D
I'm trying to figure out if this is something that's blockUI-specific.
What happens if you do:
$("#hi").html('Hi');
Inside your try/catch.
--John
On Thu, Feb 12, 2009 at 10:08 PM, David Pollak
wrote:
>
>
>
> On Feb 12, 6:09 pm, John Resig wrote:
>> > "application/xhtml+xml"
>>
>> What do yo
On Feb 12, 6:09 pm, John Resig wrote:
> > "application/xhtml+xml"
>
> What do you do for the other browsers? (IE)
The XHTML is sent through a quirks mode rewriter for IE and served as
text/html
>
> >> 2) Self-closing script tags are invalid (may want to fix those first).
>
> > Why are they in
> "application/xhtml+xml"
What do you do for the other browsers? (IE)
>> 2) Self-closing script tags are invalid (may want to fix those first).
>
> Why are they invalid for xhtml?
Dunno, but they are:
http://www.w3.org/TR/xhtml1/#C_3
--John
--~--~-~--~~~---~--~
I would still expect that the string you get back from the dom would
be valid html.
On 12 Feb, 22:29, Klaus Hartl wrote:
> On 12 Feb., 10:42, weepy wrote:
>
> > Thanks Klaus I suspected as much.
>
> > It is quite odd that you can pull some html out, push the same back in
> > and it isn't the
On Feb 12, 1:49 pm, John Resig wrote:
> 1) What mimetype are you serving this with?
"application/xhtml+xml"
> 2) Self-closing script tags are invalid (may want to fix those first).
Why are they invalid for xhtml?
>
> --John
>
> On Thu, Feb 12, 2009 at 1:43 PM, David Pollak
>
> wrote:
>
> >
On 12 Feb., 10:42, weepy wrote:
> Thanks Klaus I suspected as much.
>
> It is quite odd that you can pull some html out, push the same back in
> and it isn't the same! I guess this is a bug in Firefox ?
It's not that odd at all. As soon as you understand that a browser
will not just copy some te
1) What mimetype are you serving this with?
2) Self-closing script tags are invalid (may want to fix those first).
--John
On Thu, Feb 12, 2009 at 1:43 PM, David Pollak
wrote:
>
> Folks,
>
> I use and *love* jQuery. I also run the Lift web framework project.
> In Lift, we use jQuery and we us
On Feb 12, 10:49 am, Leonardo Rossetti wrote:
> what is the purpose of this try-catch block?
To catch and display the exception.
If the try/catch block is omitted, the problem still ocurs, but is
silently discarded (unless you've got Firebug running.)
>
> 2009/2/12 David Pollak
>
>
>
>
>
>
On Feb 12, 2009, at 1:28 PM, ajpiano wrote:
>
> I don't know how much harder the point that @ is gone can be driven
> home. It was deprecated in 1.2.6. A major problem is bad/outdated
> tutorials that are still telling people the wrong way.
Actually, it was deprecated in 1.1.4, but your point
what is the purpose of this try-catch block?
2009/2/12 David Pollak
>
> Folks,
>
> I use and *love* jQuery. I also run the Lift web framework project.
> In Lift, we use jQuery and we use XHTML namespaces (we need to
> decorate certain XHTML elements with lift:gc attributes.)
>
> We've run into
> I don't know how much harder the point that @ is gone can be driven
> home. It was deprecated in 1.2.6. A major problem is bad/outdated
> tutorials that are still telling people the wrong way.
Actually, it was deprecated in jQuery 1.2.0 - back in 2007.
--John
--~--~-~--~~---
Folks,
I use and *love* jQuery. I also run the Lift web framework project.
In Lift, we use jQuery and we use XHTML namespaces (we need to
decorate certain XHTML elements with lift:gc attributes.)
We've run into a very weird interaction between jQuery BlockUI and
Firefox and XHTML namespaces.
B
I don't know how much harder the point that @ is gone can be driven
home. It was deprecated in 1.2.6. A major problem is bad/outdated
tutorials that are still telling people the wrong way.
On Feb 12, 10:35 am, David Zhou wrote:
> Actually, nevermind. I forgot there was a changes section:
>
>
Yeah, that looks like an easy fix - thanks!
--John
On Thu, Feb 12, 2009 at 11:11 AM, mike.helgeson wrote:
>
> Not sure if this is considered a bug, but it breaks some of my code...
> Passing any non-element into the offset method throws an error... I
> think it should instead return zero valu
Not sure if this is considered a bug, but it breaks some of my code...
Passing any non-element into the offset method throws an error... I
think it should instead return zero values...
$( document ).offset(); // ERROR
$( window ).offset(); // ERROR
Here is a very simple proposed patch...
http:/
I feel an idiot now, thanks.
Patch uploaded :D
On Thu, Feb 12, 2009 at 4:02 PM, John Resig wrote:
>
> Actually, in order to generate a patch you would generally need to
> diff two files (the old file and the one you've made changes to).
>
> If you have svn you can do "svn diff" and that'll spit
Actually, in order to generate a patch you would generally need to
diff two files (the old file and the one you've made changes to).
If you have svn you can do "svn diff" and that'll spit out the
differences in a format that will be easy to consume.
--John
On Thu, Feb 12, 2009 at 10:42 AM, An
Done, 3 files fixed with RegExp test, if you want I can use indexOf where
possible (case sensitive, no different chars) but for me it is already
better than before.
http://dev.jquery.com/ticket/4113
Best Regards
On Thu, Feb 12, 2009 at 3:31 PM, John Resig wrote:
>
> Correct. Feel free to uploa
Actually, nevermind. I forgot there was a changes section:
http://docs.jquery.com/Release:jQuery_1.3#Upgrading
Maybe change the "Changes" name to something more explicit like
Backwards Incompatible Changes? Right now, a person scanning the
release note headers could easily misconstrue that as
I wasn't able to duplicate the issue either--if I run into this same
problem again, I will file a ticket. If not, I will assume that there
was something else in my codes that were throwing this error. Again,
time will tell :P
--Vuong
On Feb 7, 11:15 am, John Resig wrote:
> I tried to duplicate
Correct. Feel free to upload any patches to the bug, though!
--John
On Thu, Feb 12, 2009 at 10:21 AM, Andrea Giammarchi
wrote:
> Actually I was replacing from nightly ... but I guess I cannot commit stuff,
> right?
>
> On Thu, Feb 12, 2009 at 2:11 PM, John Resig wrote:
>>
>> You should add t
I wonder if it would be helpful to have a backwards incompatible
changes section for every jQuery release, and a master page somewhere
collating all those changes. The changes are usually highlighted in
the release notes, but it'd be more clear if there was a section
specifically calling out the
Actually I was replacing from nightly ... but I guess I cannot commit stuff,
right?
On Thu, Feb 12, 2009 at 2:11 PM, John Resig wrote:
>
> You should add that to this tracking bug:
> http://dev.jquery.com/ticket/4113
>
> --John
>
>
>
> On Thu, Feb 12, 2009 at 8:50 AM, Andrea Giammarchi
> wrote:
I just added this point to the release notes - thanks for bringing it up.
Have you run across any other problems that we haven't mentioned? We
definitely want to make sure that we cover them all.
Oh, and no problem - glad you're enjoying jQuery :)
--John
On Thu, Feb 12, 2009 at 9:53 AM, THD
OK, thanks. I already suspected this was deprecated, it was no elegant
solution by any means. At least there is a simple fix for old code.
I noticed there are a lot of different little problems when upgrading
1.2.6 to 1.3.1. It might be worth it to add a readme to the release
version of jQuery 1.
I don't see anything that is particularly troubling about your code -
do you have a demo online?
--John
On Wed, Feb 11, 2009 at 2:20 PM, Yusuf wrote:
>
> Hi,
>
> I'm new to jQuery. I started using it and wrote some fairly straight
> forward code. Here is the what I got
>
> - Downloaded the la
This was intentionally removed. Including extra code for doing code
evaluation was seriously affecting other environments like Adobe AIR
and Caja. (Not to mention the fact that having those code strings was
probably just a bad idea to begin with.)
We deprecated that behavior a while back, actuall
You should add that to this tracking bug:
http://dev.jquery.com/ticket/4113
--John
On Thu, Feb 12, 2009 at 8:50 AM, Andrea Giammarchi
wrote:
> Guys, I spot a match in the core of the 1.3.1
>
> line 3294
> s.url += (s.url.match(/\?/) ? "&" : "?") + (s.jsonp || "callback") + "=?";
>
> in my opi
This sounds more like a problem of circumstances. IE was being
unhelpful and not providing the nice error message that we specified -
and the error was only happening in IE (since the fix was browser
specific). All of it was very unfortunate - but I'm not sure if
there's a lot that we can do on ou
Guys, I spot a match in the core of the 1.3.1
line 3294
s.url += (s.url.match(/\?/) ? "&" : "?") + (s.jsonp || "callback") + "=?";
in my opinion String.match used as true/false result is useless, slow, and
memory greedy
/\?/.test(s) is about 2X faster
~s.indexOf("?") about 4 times faster
Is an
Custom expressions like the ones in jQMinMax fail with an error when
used in the selector. (jQMinMax is found here:
http://davecardwell.co.uk/javascript/jquery/plugins/jquery-minmax/)
All browsers fail with an error that 'filter is not a function' in the
line:
return filter( elem, i, match, arr
$.ajax({
*cache:false*,
...
});
On Thu, Feb 12, 2009 at 9:43 AM, squiddy wrote:
>
> Hello,
>
> as far as I know, GET requests are far more often cached by the
> browser than POST requests. So maybe this could be a problem here? You
> could try to use POST instead, or add a random value a
Hello,
as far as I know, GET requests are far more often cached by the
browser than POST requests. So maybe this could be a problem here? You
could try to use POST instead, or add a random value as parameter to
the request, a timestamp for example.
Otherwise, can you try to be more specific abou
The selector 'i...@src$=png]' failed with the latest version of jQuery
(Sizzle).
At first I thought this problem only occured in IE6, but that was just
because it only got executed in the png alpha fix for IE6). I only
found this problem after a long search, only to find a small message
in the doc
Hi,
I'm new to jQuery. I started using it and wrote some fairly straight
forward code. Here is the what I got
- Downloaded the latest version (ver 1.3.1)
- My script is in \js folder
- Included the script in my page -
Finally I am resizing iframe on document.ready
$(function()
{
Thanks Klaus I suspected as much.
It is quite odd that you can pull some html out, push the same back in
and it isn't the same! I guess this is a bug in Firefox ?
On 10 Feb, 09:42, Klaus Hartl wrote:
> On 10 Feb., 09:48, weepy wrote:
>
> > This is why I had to regex them back in :-(. I think
40 matches
Mail list logo
