[jQuery] :visible fails in MSIE8 (in a ThickBox)
Okay, so jQuery 1.3.2 defines the visible filter like this:
Sizzle.selectors.filters.visible = function(elem){
return elem.offsetWidth 0 || elem.offsetHeight 0;
};
Now I've got a table of hidden (style=display: none) rows. The user
will click something that will .show() a specific row, and the whole
table -- along with a lot of other stuff -- will be displayed in a
lovely thickbox.
The problem is that MSIE 8 assigns offsetWidths and offsetHeights to
the rows; even those with display: none active on them. In
compatibility mode, MSIE will set the offsetHeight to 0, but there
will still be an offsetWidth.
Firefox doesn't have this problem; Chrome doesn't have this problem.
I'm not sure if MSIE got wildly confused by moving hidden rows into a
thickbox. I know I've broken MSIE's rendering of other similar tables
on the page, but I doubt those have anything to do with jQuery.
I've gotten around it by using .addClass and .removeClass and
filtering on that new class instead of :visible, but I'd rather know
that :visible is working as intended in the long run.
Cheers,
JM (wanders off to lunch)
[jQuery] Re: POST Redirection
If your browser is posting a request and recieving a response, there should be information about the transaction (headers and post data) in Firebug's Console tab. That said, for watching HTTP streams, I tend to go for the Tamper Data FF plug-in -- it allows you to watch the outgoing requests and (usually, unless it gets confused) see the server response in plain text. HiH On May 4, 12:54 am, Cryptonit dom.helfenst...@gmail.com wrote: Let's bring this on top... On 3 Mai, 11:11, Cryptonit dom.helfenst...@gmail.com wrote: As I said in my last post. I'm creating a firefox extension -- there is no form. There is only my menu entry and when I fire it, nothing happens in firebug. But my question is not what url I get. I want to know where I have to look for it, because the url will be different everytime... Hope you still can help me. On May 2, 6:30 pm, Danny Nolan danny_no...@yahoo.co.uk wrote: got it installed? Enable it, have it running while viewing the form. Now submit the form and firebug will capture the post URL, will popup inside the firebug window. --- On Sat, 5/2/09, Cryptonit dom.helfenst...@gmail.com wrote: From: Cryptonit dom.helfenst...@gmail.com Subject: [jQuery] Re: POST Redirection To: jQuery (English) jquery-en@googlegroups.com Date: Saturday, May 2, 2009, 9:20 AM Could you please be a little more precise? I've installed firebug, now what? Maybe I also have to be more specific: I don't create a web page, I'm creating a firefox extension. So I can't just debug everything I like... Could you please point me to the exact property I have to look for? On 2 Mai, 02:07, Danny Nolan danny_no...@yahoo.co.uk wrote: Firebug is your friend --- On Fri, 5/1/09, Cryptonit dom.helfenst...@gmail.com wrote: From: Cryptonit dom.helfenst...@gmail.com Subject: [jQuery] POST Redirection To: jQuery (English) jquery-en@googlegroups.com Date: Friday, May 1, 2009, 2:22 PM Hi Folks! Here's my problem: I want to make a post request to a web service site. This site is automaticly redirecting me to a file. Now I want to find out the location of this file. As far as I can see (please correct me if there are more) there are two possible solutions: 1. I somehow disable redirecting (on jQuery) and so I would have the link to the file in the answer of my call 2. Or I read the final location after the redirection But of course I don't know how to do this... So I really hope someone can help me! Greetz cryptonit- Hide quoted text - - Show quoted text -
[jQuery] $.fadeTo() vs. MSIE6 through 8
So, despite how perfectly .fadeTo works with FF and how easy opacity: 0.40; is to write, it seems like MSIE is lost and confused. In MSIE 8, with compatibility mode off, then .fadeTo process appears to be roundly ignored (at least for jquery 1.3.1). If you turn compatibility mode on, it behaves in the same manner as MSIE 6 and 7, which is this: Given an inline span with a background color, some margin (2/4/0/0), some padding (1/8/1/8), and a word bounded by a border (1px), MSIE will apparently add ~2px of padding to the top and bottom of the element, and then correctly apply the fade. Problem, of course, being that the extra 4px of padding makes the item that is fading out stand out from its smaller peer elements. If I had to take a guess, I'd expect that the resizing problem is the elem.zoom = 1; (line 1031 in v1.3.1) as that allows/forces MSIE to think about things have been rendered and potentially re-render them. But it's just a guess at the moment. Anybody got a better theory as to what's going on (and how to resolve it)?
[jQuery] Re: $.fadeTo() vs. MSIE6 through 8
MSIE8 ignoring the .fadeTo directive is apparently tied to using ! DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http:// www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd which puts MSIE into standards mode, whereby it doesn't have the actual standard of opacity but doesn't admit to having filter: alpha(opacity) either. List of doctypes that put MSIE 8 into standards mode is over at http://msdn.microsoft.com/en-us/library/ms535242(VS.85).aspx and testing between !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN (standards off) and !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; (standards on) would seem to confirm that MSIE 8 believes that disabling features improves standards compliance. I don't have any additional information on where the vertical shift is coming from when MSIE does admit to having opacity capabilities.
[jQuery] Re: $.fadeTo() vs. MSIE6 through 8
Okay, nevermind, got it. The lines:
// IE has trouble with opacity if it does not
have layout
// Force it by setting the zoom level
elem.zoom = 1;
are referring to the .hasLayout property of elements in MSIE. There's
a nicely extensive document on it over at
http://www.satzansatz.de/cssd/onhavinglayout.html,
and a jQuery oriented bit of knowledge at http://realjenius.com/node/633,
which points back to the delightfully opinionated and informative
http://www.haslayout.net/haslayout. The upshot of it is that...
the span element (among others), by default, has a .hasLayout of
false. In order to adjust opacity on an element, MSIE requires it
to .hasLayout == true. I was using a span element as my wrapper,
and thus affected by this.
As near as I can tell, elem.zoom = 1; is no longer a satisfactory
workaround for MSIE's .hasLayout property (and was also the cause of
the wiggle when .hasLayout got toggled) as .zoom is what got
eliminated thus breaking MSIE 8. My chosen workaround (there are
several possible) was to use a display: inline-block instead of just
the default display: inline.
If you think you're encountering this issue, here's some javascript
to test MSIE with:
$(.myspan).click(function() {
alert($(this).get(0).currentStyle.hasLayout); // will return
false.
//$(this).get(0).zoom = 1;
$(this).css({ display : inline-block });
alert($(this).get(0).currentStyle.hasLayout); // will return
false
if using the zoom line, true if setting display to inline-block
$(this).css({ filter : alpha(opacity=30) }) // will only
work
if previous line alerted true
//$(this).fadeTo(300, $(this).hasClass(selected) ?
1.00 : 0.40);
$(this).toggleClass(selected);
});
And now I'm done.
[jQuery] Re: .append misbehavior in MSIE7 with cross-window element injection
Thanks Dave! script type=text/javascript var newElement = $(li /, opener.document).text(Mod State); $(opener.document).find(#injectHere).append(newElement); /script works great in MSIE7 FF3. /script On Mar 10, 5:47 pm, Dave Methvin dave.meth...@gmail.com wrote: Try this: $(li /, opener.document) That way it will create the li element in the right document. http://docs.jquery.com/Core/jQuery#htmlownerDocument
[jQuery] .append misbehavior in MSIE7 with cross-window element injection
I need to alter a parent window from its pop-up (customers insisted) child, using dynamic data. The following works in Firefox 3, but not in MSIE7. script type=text/javascript var newElement = $(li /).text(Mod State); $(opener.document).find(#injectHere).append(newElement); /script See http://www.5pmstudio.com/js/base.htm (click on the word popup) for a demo. If I were to write out the newElement as just a string, MSIE7 accepts it. If I were to write in an element as a string and then select it out of opener.document and modify its .text, MSIE7 allows for it (just very slowly). But sending a crafted element (as above) outside of the current window fails in one of several ways. (1.3.1 complained of an unsupported interface, 1.3.2 doesn't do anything.) In this particular case, I want to use the .text property of my newly- crafted element because the string data isn't entirely safe to be injecting into the middle of string-built elements, otherwise this really wouldn't be a problem. Thoughts? NNeko
[jQuery] Re: .append misbehavior in MSIE7 with cross-window element injection
Same behavior -- which is a No such interface supported exeception on this WinXP/IE7.0.5730.13 machine. The $(newElement).appendTo($ (opener.document).find(#injectHere)) permutation also behaves in this way. On Mar 10, 8:48 am, Joseph Le Brech jlebr...@hotmail.com wrote: What about something like this? $($(opener.document).find(#injectHere)).append(newElement); Date: Tue, 10 Mar 2009 08:32:28 -0700 Subject: [jQuery] .append misbehavior in MSIE7 with cross-window element injection From: nekura.n...@gmail.com To: jquery-en@googlegroups.com I need to alter a parent window from its pop-up (customers insisted) child, using dynamic data. The following works in Firefox 3, but not in MSIE7. script type=text/javascript var newElement = $(li /).text(Mod State); $(opener.document).find(#injectHere).append(newElement); /script Seehttp://www.5pmstudio.com/js/base.htm(click on the word popup) for a demo. If I were to write out the newElement as just a string, MSIE7 accepts it. If I were to write in an element as a string and then select it out of opener.document and modify its .text, MSIE7 allows for it (just very slowly). But sending a crafted element (as above) outside of the current window fails in one of several ways. (1.3.1 complained of an unsupported interface, 1.3.2 doesn't do anything.) In this particular case, I want to use the .text property of my newly- crafted element because the string data isn't entirely safe to be injecting into the middle of string-built elements, otherwise this really wouldn't be a problem. Thoughts? NNeko _ Free photo editing software from Windows Live . Try it now!http://clk.atdmt.com/UKM/go/134665240/direct/01/- Hide quoted text - - Show quoted text -
[jQuery] Re: Reset individual form objects to their original display state
I'm thinking that
$(form input).each(function() { $(this).val(origFormData[$(this).attr
(id)]); });
should step over each input field in a form and conjure up values from
the origFormData object based on the id of the current element
conjuring a value.
But the state-saving code should be more along the lines of
$(:input).each(function(){
origFormData[$(this).attr(id)] = $(this).val
(); // Might not work with checkboxen
});
to get the value of the field and keep the origFormData based on the
ID of the field.
Hope it helps!
NNeko
On Mar 10, 10:36 am, Brad nrmlcrpt...@gmail.com wrote:
I have a need to reset individual form objects to their original
state. When the document loads I save the element like this:
var origFormData = {};
$(document).ready(function(){
// Save original form data for each input field
$(:input).each(function(){
origFormData[this.name] = $(this);
});
});
For example I have a form with fields named name, age, and dept
selectable by $(#name), $(#age), and $(#dept) respectably.
How would I go about later restoring/resetting a specific field. Is
there a simple way to overwrite the object represented by $(#name)
with origFormData.name?
[jQuery] Re: on click on a checkbox, highlight complete table row
Going for $(input[name^=paradigm]).is(:checked) or $(input
[name^=paradigm]).not(:checked) should get you the list of input
elements with name attributes starting with paradigm -- because I'm
not comfortable with that [] in the name attribute... -- which either
are or are not checked. You can then either .each() or .map() across
that collection to get the .val() out of the checked (or not checked)
elements. Since the checkbox you're trying to avoid doesn't have a
name, it shouldn't be selected by either query.
If I were in your position, I'd try to add a CSS class or some other
custom attribute to all of the checkboxes in the collection that we
want to select off of and query for that.
But what the subject of your post suggests is that you're looking
for...
$(document).ready(function() {
$(input[type=checkbox]).click(function() {
$(this).parents(tr).toggleClass(HighlightClassDefinedByMyCss);
});
});
which will result in any checkbox on the page adding (or removing) the
HighlightClassDefinedByMyCss from the first TR in its parent chain
when it is clicked. In theory.
To step things up a notch, consider that this tangentally related code
selectedBookmarkTitles = $(input:checked).map(function() { return $
(this).parents(tr).find(.bookmarkTitleLink).text() }).get();
will find every checked checkbox on a page, and then go to their
parent table row, dig up whatever has the CSS class bookmarkTitleLink,
get the text out of that element, and return that entire list of
strings as an array that is being stored in the selectedBookmarkTitles
variable.
Hope it helps!
On Feb 19, 2:43 am, heohni heidi.anselstet...@consultingteam.de
wrote:
Hi, sorry, for this newbie question:
input type=checkbox name=paradigm[] value={$value.ver_id} /
How can I check if this checkbox is checked or not?
And how can I avoid this check for this particular checkbox: input
type=checkbox id=paradigm_all /
Thanks so much!!
[jQuery] [autocomplete] making it work with JSON web service data source
I'm trying to replace a MS AJAX.NET autocomplete control with
something a bit lighter and more cache-and-compress friendly and I
really love how smoothly the Autocomplete plug-in generally works
(http://bassistance.de/jquery-plugins/jquery-plugin-autocomplete/). I
had to change a couple of things to make it work with our JSON-service-
based design:
1) Our application is using web services serialized to JSON and it's
working great up until the autocomplete. You can read about the
general methodology thanks to Dave over at
http://encosia.com/2008/03/27/using-jquery-to-consume-aspnet-json-web-services/.
To get around that for proof-of-concept purposes, I went into
Autocompleter.request and replaced the existing AJAX call with
$.ajax({
type: POST,
url: ajaxProxy.asmx/TagAutocomplete,
data: '{ prefixText : ' + lastWord(term) + ',
count : ' + options.max + '}',
contentType: application/json; charset=utf-8,
dataType: json,
success: function(msg) {
var mashed = options.parse options.parse
(msg.d) || parse(msg.d);
cache.add(term, mashed);
success(term, mashed);
}
});
and altered parse() to just take an array instead of a delimited
string (var rows = data; // = data.split(\n);). Now we're currently
just returning an array of strings, so this is no problem for us (so
long as a user doesn't stick a | or in terms, though that can likely
be modded out as well).
Question at this point: Is there a simpler way to get the same JSON
callback out of Autocomplete? If not, given the above, can it be
added to the official source?
2) Given the above, there was an odd behavior in starting a new term
in a multiple-term box -- toss in a , and the correct form of the
previous term shows up ready to be auto-completed. I fixed that by
eliminating the 0-character word check (//if ($.trim(value))) in
trimWords such that an empty string can go into the array. It was a
quick fix, but I'm not sure how solid -- the core symptom appears to
be that lastWord is treating a 0-length word as not a word and instead
skipping to the previous word when onChange is figuring out what to
suggest autocompletes.
Question at this point: Did I find a bug? If so, is eliminating that
length-check when making an array of terms the most effective way of
dealing with it? If so, is this something that will be patched in the
near future?
Thanks!
