I just tried to upgrade to 1.3.2 and have a major issue with the
appendTo change. One paradigm we use is adding functions (and
properties) onto jquery objects with jquery extend. The jquery object
is often returned from a function and then appended into the DOM. For
example, our buttons are cre
setTimeout in WebKit for JavaScript issues is becoming like zoom: 1
for CSS issues in IE
I fixed a lot of odd reflow issues I was having with the jQuery API
Browser for the iPhone using setTimeouts.
--
Brandon Aaron
On 3/5/09, Parand wrote:
>
> Finally found a work-around:
>
> I was calling my
Finally found a work-around:
I was calling my objective-c function using window.location . It
turned out if I added a setTimeout around the call to window.location
everything started working again. I'm guessing calling window.location
would immediately call the objective-C code, interrupting the
Finally found a work-around:
I was calling my objective-c function using window.location . It
turned out if I added a setTimeout around the call to window.location
everything started working again. I'm guessing calling window.location
would immediately call the objective-C code, interrupting the
Finally found a work-around:
I was calling my objective-c function using window.location . It
turned out if I added a setTimeout around the call to window.location
everything started working again. I'm guessing calling window.location
would immediately call the objective-C code, interrupting the
I don't have much problem with using a nightly at work. For now I'll
probably just use some plain css for setting borderRadius on tooltips
till I can get a nice method of using .css;
Feel free to give me a poke when you've refactored that section of the
code, I'd be happy to setup the extensibl
Unfortunately, I have no idea - it doesn't make it easier that it's
such a custom set up. Maybe someone with more iPhone dev experience
can speak to the situation.
--John
On Thu, Mar 5, 2009 at 4:52 PM, Parand wrote:
>
> Hello,
>
> I'm having a strange issue using jQuery on UIWebComponent on
Hello,
I'm having a strange issue using jQuery on UIWebComponent on the
iPhone - at some point jQuery becomes unable to add content to the
DOM, while regular DOM methods (document.getElementById
('something').appendChild(x) ) continue to work.
I've posted details on stackoverflow, and I'll descr
Well, to be clear, this section of the jQuery code probably isn't
ready for this expansion yet - I'm going to be refactoring the
attribute/css code and will be splitting apart (giving you access to
the element, as well). I was planning on landing some of the custom
attribute/css property hooks the
Ok, I'm going to need some input on how to fix an issue I've run into
while coding that css extensibility.
Currently the API for that sits in a jQuery.css.callbacks list, to
extend .css to support another obscure css type you'd use:
jQuery.css.callbacks.push(function( style, name, value, force )
On Mar 4, 3:26 pm, lrbabe wrote:
> I'm aware that jQuery promotes features detection over browser
> sniffing but currently we provide no way for the user to figure out
> easily when the browser is IE8 operating in the so called
> "compatibility mode".
Why would you need to detect this? What prob
Ok. To be honest a large number of these ideas I've actually suggested
before on the list, and those times I got a lot of comments suggesting
it wasn't something that would be accepted, or suggesting some cheap
flawed workaround as the fix instead. I guess I'll just have to discard
all those ol
Right... but it's still an object, not an array, regardless of it's
mimics. Doesn't seem right.
(btw is right-click/inspect in DOM tab on one of the brackets the only
way to inspect the object?)
thanks,
- ricardo
On Mar 5, 12:40 am, John Resig wrote:
> It's supposed to be - and this was a chan
Well, In any case I think an explicit forEach could be helpful and more
reliable (specially with hidden keywords checks for IE as well) but I am
sure it is not that important. Regards
On Thu, Mar 5, 2009 at 3:54 PM, Ariel Flesler wrote:
>
> I'm not saying we need to patch this, just telling you
I'm not saying we need to patch this, just telling you what was my
situation, that's all :)
On Thu, Mar 5, 2009 at 1:51 PM, Andrea Giammarchi
wrote:
> I don't know in which case an each over a definition (prototype with a
> length) could be useful ... I think a forEach as for in could be explici
... with the return object in the forEach ... btw, if performances are a
problem, leave each as is but imho if you need a for in loop I do not get
this limitation over object with proper or inherited length
On Thu, Mar 5, 2009 at 3:51 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
>
I don't know in which case an each over a definition (prototype with a
length) could be useful ... I think a forEach as for in could be explicit
and less ambiguous for these weird case (I mean, you have the same problem
with window object, don't you?)
A=0;$.each(window,function(){ A++; });A
... A
I dunno how is Firebug sniffing arrays, maybe like:
if( this._proto_.length !== undefined )...
In that case, this change would matter, anyway
As for the other thing, I suppose it happened because I was using
$.each to iterate $.fn.
Go to jquery.com, then try this on Firebug's console:
A=
if length is always assigned, you do not need it in the prototype, so why
you asked if that was the problem? :-)
I did not get the proto un-iterable but generally I prefer properties as
methods in the prototype rather than assigned runtime, so you can spot
everything simply logging the constructor
Each instance gets a length within $.fn.init, no exception. So that
prop was redundant.
It might also made the proto un-iterable back then when I needed to do that.
So, why re-add it ?
On Thu, Mar 5, 2009 at 12:12 PM, Andrea Giammarchi
wrote:
> Since every call to jQuery returns an ArrayLike in
Since every call to jQuery returns an ArrayLike instance I think you should
put back the length:0 into the prototype (could be also useful to understand
different instances via constructors prototype).
On Thu, Mar 5, 2009 at 1:30 PM, Ariel Flesler wrote:
>
> Maybe because we removed:
>
> lengt
Apologies for the double post on this.
It already exists in general support as I didnt think it submitted correctly to
dev.
Adam.
_
From: AdamJessop [mailto:a...@infused-gaming.net]
To: jQuery Development [mailto:jquery-...@googlegroups.com]
Sent: Thu, 05 Mar 2009 09:26:22 +
Subject
Maybe because we removed:
length:0,
from jQuery's prototype ?
--
Ariel Flesler
http://flesler.blogspot.com
On Mar 5, 12:40 am, John Resig wrote:
> It's supposed to be - and this was a change in Firebug, not in jQuery
> - it was actually a regression in Firebug that this no longer worked.
>
Hi,
I am currently working on a site where we are implementing a fluid
layout with the heavy use of percentages so it works over multiple
resolutions. As part of the site we wish to animate objects coming
onto the screen and ending in a certain position.
We have the CSS for the objects final pos
I'm not sold on this. We were discussing the cloning of data recently,
it seems like this should be sufficient:
.clone(true) - Clone events and data (which is reasonable,
considering that events are part of data)
.clone(false) - Clone just elements (no data)
As far as removeID goes, it seems
There's really no need to branch out a whole project like this. If you
have a patch to add some extensibility (make it easier to handle
oddball CSS properties, for example) I'd definitely imagine that
something like that would be accepted, no problem. Just make a patch,
file a ticket, then post it
I've been thinking about my 4query offsite branch and the merits of
something more tied to jQuery.
A project more involved with jQuery definitely has the advantage of
being much easier to keep compatibility and avoid the code differing to
much.
jQuery has strong policies on things being compat
Mark Gibson wrote:
> Hi Daniel, thanks for your feedback, just to clear up some points:
>
> On Mar 4, 10:10 am, Daniel Friesen wrote:
>
>> I'm not really a fan of the [float, float, float] but if 'rgb(255, 255,
>> 255)'; is supported I suppose that's ok (heck I could throw a function
>> rgb(r,
Hi Daniel, thanks for your feedback, just to clear up some points:
On Mar 4, 10:10 am, Daniel Friesen wrote:
> I'm not really a fan of the [float, float, float] but if 'rgb(255, 255,
> 255)'; is supported I suppose that's ok (heck I could throw a function
> rgb(r, g, b) into code).
RGB values u
Great to hear it, Mike. If this is going off list, feel free to be in
contact via email.
-Trey
On Mar 5, 3:52 pm, Mike Hostetler wrote:
> Trey-
>
> Just found this thread right before shutting down for the night. I wanted
> to respond and let you know that I'm *very* interested in talking wi
30 matches
Mail list logo
