I'm facing a little issue with my javascript code. In fact it's working in Firefox but not in Chrome, do you have any idea why I'm facing this issue?
Here is my code:
$('a').each(function(){
if($(this).css('background-image')=='url("linktothepng.png")'){
$(this).parent().remove();
}
});
Thank you for helping me, have a good day ;)
chrome will get it as url(linktothepng.png) (no quotes)
browsers parse css and format it their own way, it is not advisable to do text matches on those properties, just use a class with that background and check with hasClass() to prevent the inconsistency
The value returned by css('background-image') can be normalised in different ways by different browsers; they're all valid as long as they are equivalent CSS.
You could test for css('background-image').indexOf('linktothepng.png') != -1 which would work, assuming there isn't another image in use that has linktothepng.png as part of its name (which would require a more complicated test).
If possible though, you'd be better off only ever setting that background image by setting a class.
Easier to change.
Separates the meaning you are ascribing to that image from the fact that the image is how you are representing it.
Quicker to find, instead of replacing the test to something like if($(this).hasClass('the-class-you-use') remove the test and change the selector to $('a.the-class-you-use').
Related
I saw this pattern being used in some code...
currency = $(document.getElementById('currency'));
Which is expect is functionally equivalent to...
currency = $('#currency');
I am guessing the idea is to make the selector faster, as it does not need to parse the selection string... but does it really make a discernible difference? Is there something else at play I have not considered?
Why would someone use this kind of pattern?
Internally, when parsing the selector string passed, jQuery automatically detects that you passed an id selector and calls document.getElementById for you.
So, when you're fetching the element yourself prior the call to jQuery, you're only saving the selector parsing portion, but that's negligible for most use cases.
See source
No sense to use first sintax -- both do the same ( at second part you skip parsing for jq-query ) -- also jq can cache requests -- so just right $('#..') and keep your code clean
http://jsperf.com/document-getelementbyid-as-jquery-selector
I saw this pattern being used in some code...
currency = $(document.getElementById('currency'));
Which is expect is functionally equivalent to...
currency = $('#currency');
Now, yes. It didn't used to be, back when IE6 and IE7 were still on the scene. The getElementById in IE7 and earlier was broken and would return elements with a matching name as well as a matching id. jQuery (1.x) has intelligence built into it to deal with broken old browsers. Thankfully, Microsoft fixed this in IE8.
I am guessing the idea is to make the selector faster, as it does not need to parse the selection string... but does it really make a discernible difference?
It probably makes an actual difference, but not in a way that translates to anything perceptible in the real world. The only way to know for sure is to test it on a DOM that's representative of the ones you want to know the answer for, and on the browsers that you want to know the answer for. (JSPerf seems to be having issues at the moment, though.)
Here's a test that doesn't use a representative DOM suggesting a significant percentage difference:
...but again, in real world terms unless you're doing this millions of times in a loop, it's not going to matter. Also note that what's being tested is so fast that error margins are likely to be large.
$(document.getElementById('currency')); is less readable and in the end there will be getElementById called anyway. You will not see it's effect in most cases (element is cached and will be called only once).
It uses document.querySelector() if is supported, and if not uses document.getElementById()
In my opinion, for non-jquery purpopses, document.querySelector() is better (for me)
document.querySelector("#id .class > tag.nested");
Im trying to use ranges to check if the mouse is over an url, but I dont know how to tell the range that expand to get the full url, not just each word in it.
Here is an example to show the problem: jsFiddle
I will use this code in an editable iframe. If an user write an url, I want to give him the possibility to open it although it isn't an anchor element but plain text. Im not sure if can achieve that, but i want to try it.
One problem is that the expand() method of Range is non-standard and only supported in WebKit. Another is that document.caretRangeFromPoint() is also WebKit-only. Yet another is that there is no way of specifying a regular expression to match when identifying a word.
One option is the new TextRange module of my Rangy library, which works in all major browsers and provides a more flexible expand() method of ranges. There's also a work-in-progress position module that provides a cross-browser implementation of document.caretRangeFromPoint() (which is standardized as document.caretPositionFromPoint()).
Unfortunately, the position module is flaky in Firefox, but I intend to fix it soon. Also, the following demo doesn't work in IE at the moment, for reasons I think related to jsFiddle. So overall this is far from satisfactory, but may give you some ideas.
Live demo: http://jsfiddle.net/q3AtL/5/
I've searched for an answer and no solution seems to fix this problem, so hopefully stating it specifically will help me find a solution.
I'm trying to read cssText of the first stylesheet using document.styleSheets[0].cssText, but it always returns undefined. I do have a stylesheet and it's visibly noticeable, but JavaScript doesn't seem to recognize it.
This did, however, work when I included the stylesheet within the page using <style>. I don't see why this would change when using <link>, though. Not only is it placed before the script, but it even returns undefined when using javascript:alert(document.styleSheets[0].cssText) in the omnibar after the page is fully loaded.
Thanks for any help.
Edit: This applies to any method with document.styleSheets[0], including those of which are supposed to work on multiple browsers and have worked for me prior to using <link>. For example: document.styleSheets[0].cssRules[0].selectorText
According to quirksmode.org, document.styleSheets[n].cssText is only supported in IE.
The form
document.styleSheets[n].cssRules[m].cssText
seems to be more widely supported, so you could just loop over that and build a string from the individual rules. (Although you have to replace cssRules with rules for IE).
I thing that this answer is out of time, but it could be useful for someone else.
The result can be "undefined" due 2 different reasons:
a) In some browsers, the property "cssRules" does not work (in accord with http://www.javascriptkit.com/domref/cssrule.shtml, only for supported in NS/ Firefox). For the other browser, you should use the property "rules", instead.
You can solve the problem using something like:
if (document.styleSheets[0].cssRules)
crossrule=document.styleSheets[0].cssRules[0]
else if (document.styleSheets[0].rules)
crossrule=document.styleSheets[0].rules[0]
to extract the rule and, afterwards, to extract the name of selector:
document.styleSheets[0].cssRules[0].selectorText
b) After the overpassing of the issue a), you may have another problem: The rules that starts with a #, like #import of #font-face, as considered as rules. However, their "selectorText" is undefined. So, you must have a way of skip them. I am working on it, right now. But I have not found yet a solution. Anyway, it is an help to know way it is happening.
Hope this helps
Could someone take a moment to look at my script and see where I have gone wrong. This works fine in all modern browsers. Its IE6/7 which have the problem.
A 9KB color picker loaded.
Once loaded the picker is run.
picker.run();
This makes the picker and saves it as an object variable.
This variable can then be shown using.
picker.show();
I think the delay in opening the picker in IE might be due to the size of the color-pickers HTML. I have been tinkering with this all day and have run out of ideas. Can anyone advise?
picker : http://jasonstanley.co.uk/test/color-picker/
script : http://jasonstanley.co.uk/test/color-picker/js/color-picker.js
I have experienced slow JavaScript execution in IE7 when using prototype.js. It all boiled down to:
Do not concatenate strings, use arrays
Add content ONLY via element.innerHTML, or even better, document.write, and add as little content as possible
Use event handling with care, add only handlers when you need them
Use ID's instead of classes.
In your cube function you do concatenate strings (and declare variables inside loops...), I would look into that first.
It could simply be a factor that targeting multiple instances of a class will be slow in ie6 - ie8. I would have a look for alternatives or see i've you can improve the accuracy of the selectors used in the script.
The script also removes the picker rather than hiding it. Is there a reason why this is necessary? If so using .empty().remove() will probably speed things up too.
See the comments here in the jQuery Api
My HTML is something like this :
<select>
<option>ABC (123)</option>
<option>XYZ (789)</option>
</select>
What I'm trying to do is: using JQuery and a regex, I replace the "(" with <span>( here's my JQuery line:
$(this).html($(this).html().replace(/\(/g,"<span>("));
It's working as intended in Firefox, chrome and safari, but (as usual) not behaving correctly on IE6/IE7 (the text after "(" just get removed)
Any thoughts ?
PS: I'm doing it this way because I need "(number") to be in a different color, and <span> in a <option> is not valid.
I don't think it's the regex breaking. The below works fine in IE7:
alert("(test".replace(/\(/g,"<span>("));
What's probably happening is that IE6/7 have no clue how to render a span inside an option and just fails to display anything.
You're saying that span in an option is not valid, and yet that's exactly what you're trying to add. Invalid code isn't prettier just because it happens to be valid at load-time, if you know you're going to mess it upp later. So really, if that's your only concern, do add this span declaratively in your HTML, rather than injecting it later.
But if you want to fix this, I think it might help if you rewrite the regex to cover the entire tag. In a lot of cases, IE doesn't let you just change the HTML to whatever, but will use its own internal representation to fix up the code, according to its own preferences. When you write a table, for instance, IE will always internally infer a tbody, even if there isn't any in the code. In the same manner, if you inject a <span> and there's no </span>, IE might insert one by itself. To get around this, make sure you inject the code in its entirety in one go:
$(this).html($(this).html().replace(/\((.*?)\)/g,"<span>($1)</span>"));
I don't have IE7 but in IE6 the following
javascript:"<select><option>ABC (123)</option><option>XYZ (789)</option></select>".replace(/\(/g,"<strong>(")
yields
<select><option>ABC <strong>(123)</option><option>XYZ <strong>(789)</option></select>
And gets correctly displayed (aside that <strong> has no effect). Also works fine when using <span> instead of <strong>