I'm calling window.open() like this:
window.open('blank.html', 'New_Window\x3a_Jamie', 'width=800,height=800');
What I've done in the code is taken the window's name and JavaScript encoded it using the Microsoft Web Protection library. I'm also replacing spaces with underscores because I read that IE doesn't like spaces in window names. FYI the original string was "New Window: Jamie" and it looks like the ":" gets encoded as "\x3a". The window opens in FireFox just fine, but the window does not open in IE8. Does IE8 just not like this encoding, or the character or what? Are there rules around what characters can appear in the window name for IE8?
Are there rules around what characters can appear in the window name for IE8?
Yes. Although it doesn't seem to be documented, IE has always required that a window name be composed of alphanumerics and underscore. A colon won't be accepted, whether read from an encoded string literal or not.
If you really needed to map an arbitrary string to a unique name-safe version you'd have to do something like encoding every non-alphanumeric character into an escape sequence, eg:
function encodeToName(s) {
return s.replace(/[^A-Za-z0-9]/g, function(match) {
var c= match[0].charCodeAt(0).toString(16);
return '_'+(new Array(5-c.length).join('0'))+c;
});
}
alert(encodeToName('New Window: Jamie'));
// 'New_0020Window_003A_0020Jamie'
I agree with casablanca though, it seems very unlikely you should actually need to do this. The user is never going to get to see the window name, so w1 is just as good. It's rare enough that you need window names at all.
I think it wants the window name to be something that'd work as an identifier. Thus, "New_Window_Jamie" would probably be OK.
Do you really need a window name? From the docs:
Such string can be used to be the target of links and forms when the target attribute of an <a> element or of a <form> is specified. This string parameter should not contain any blank space.
That's about the only use of specifying a name, and though I don't see any restrictions apart from "no spaces", it would be safe to just stick to letters, digits and underscores.
Related
var div = document.createElement('div');
div.style.cssText = "background-image: url('http://imgs.com/mouse.png ')";
div.style.cssText
//=> "background-image: url("http://imgs.com/mouse.png\9 ");"
The above code, with that being a tab after the .png suffix, when run in either Chrome or Firefox console will output the shown line with with \9 appended to the URL. Why is that?
I've read that \9 is some sort of a hack for targeting only specific versions of IE, but why would Chrome and Firefox be automatically inserting that?
PS: For additional browser fun, can you guess what happens if that URL is relative and you want to resolve it with the classic <a> href trick? Here's what would happen on the fictional http://imgs.com domain:
var a = document.createElement('a');
// Actually parsed from the above response, not assigned manually
a.href = "/mouse.png\\9 ";
a.href
//=> "http://imgs.com/mouse.png/9" (in Chrome)
//=> "http://imgs.com/mouse.png%5C9" (in Firefox)
So while the URL with the \9 suffix would still actually work, the resolved URLs will now point to incorrect locations.
When the console has to print out source code, it tries to do so in a way that's unambiguous. A tab character is not obviously a tab, and there are many other special characters with that same problem. Therefore, non-printable or non-obvious characters are rendered using an appropriate escape sequence, where "appropriate" means "appropriate to the language context".
CSS escapes look like \nnnnnn where the ns are hex digits. There can be from one to six such digits. The escape \9 is the escape for the tab character.
Note that in actual CSS source text, you too can use actual tab characters and the notation \9 interchangeably and get precisely the same results, because the CSS parser interprets \9 as a single tab character, just like an actual tab character.
The described behavior of the console is not in any standard (because the developer tools themselves are not standardized), but it's the sort of thing that any designer of such tools is very likely to do.
I'm designing chess board in HTML. ♖ is the code to display the WHITE ROOK.
I'm trying to set the value while page loads and it is displaying it as a string, but the ROOK is not coming on the button
function load() {
document.getElementById('A1').value="♖";
}
function load() {
document.getElementById('A1').innerHTML="♖";
}
http://jsfiddle.net/RM5VD/2/
The notation ♖ or ♖ has no special meaning in JavaScript; they are just strings of characters, though these strings can be assigned to the innerHTML property, causing HTML parsing.
The simplest way use a Unicode character in JavaScript to insert it as such, though this requires a suitable editor and the use of the UTF-8 character encoding. Example:
document.getElementById('A1').value = '♖';
The next simplest is to use the JavaScript escape notation, namely \u followed by exactly four hexadecimal digits. Since WHITE CHESS ROOK is U+2656 (2656 hex = 9815 decimal), you would use this:
document.getElementById('A1').value="\u2656";
This makes sense only if the element modified has the value property as per HTML specs. For example, <input type=button> has it, but button doesn’t. But this affects just the left hand of the assignment, i.e. what you assign the string to.
Beware that font support to chess piece characters like this is rather limited. Moreover, browsers may have their own ideas of the font to be used in buttons. In practice, you should probably use some downloadable font.
You need to rewrite the function like this:
function load() {
document.getElementById('A1').value=String.fromCharCode(9814);
}
It's not clear exactly what kind of element you're modifying, but you may need to modify the innerHTML instead of the value depending on your situation.
The way you have it, it is passing the text as a literal string, not a representation of a single character.
jsFiddle example
I am using the following code to convert a dynamic string into a valid class.
domain.replace('.','_','gi')
This works fine in all major browsers, but not in Internet Explorer and I'm wondering why. The gi flags are for global and case insensitive, but removing them means that the replace doesn't work in Firefox either.
Any ideas on how I change this to make it more friendly with more browers?
You'll need to use an actual regexp instead of a string:
domain.replace(/\./g, "_")
The third argument (flags) is non-standard.
You need to do it like this:
domain.replace(/\./g, '_');
I want to check if a user submitted string is the same as the string in my answer key. Sometimes the words involve Spanish accents (like in sábado), and that makes the condition always false.
I have Firebug log $('#answer').val() and it shows up as sábado. (The á comes from a button that inserts the value á, if that matters) whereas logging the answer from the answer key shows sábado (how I wrote it in the actual answer key).
I have tried replacing the á in the answer key with a normal á, but it still doesn't work, and results in a Unicode diamond-question-mark. When I do that and also replace the value of the button that makes the user-submitted á, the condition works correctly, but then the button, the user string, and the answer string all have the weird Unicode diamond-question-mark.
I have also tried using á in both places and it's no different from using á. Both my HTML and Javascript are using charset="utf-8".
How can I fix this?
If you're consistently using UTF-8, there's no need for HTML entities except to encode syntax (ie <, >, & and - within attributes - ").
For anything else, use the proper characters, and your problems should go away - until you run into unicode normalization issues, ie the difference between 'a\u0301' and '\u00E1'...
The issue is that you're not using the real UTF-8 characters in both strings (entered answer and the key). You should NOT be supplying "a button that inserts the value á" -- Re: "if that matters" it does!
The characters should be added by the keyboard input system. And your comparison string should also be only utf-8 characters. It should NOT be character entities.
What is the proper cross-browser encoding for the href when using window.open() in JavaScript? First I was using
var href = "http://127.0.0.1:8000/etf/admin/escola/t34atividade/?pop=1©=1";
var win = window.open(href, name, 'height=500,width=800,resizable=yes,scrollbars=yes');
IE8 opens: http://127.0.0.1:8000/etf/admin/escola/t34atividade/?pop=1©=1
FireFox opens: http://127.0.0.1:8000/etf/admin/escola/t34atividade/?pop=1©=1
var href = "http://127.0.0.1:8000/etf/admin/escola/t34atividade/?pop=1©=1";
var win = window.open(href, name, 'height=500,width=800,resizable=yes,scrollbars=yes');
IE8 opens: http://127.0.0.1:8000/etf/admin/escola/t34atividade/?pop=1©=1
FireFox opens: http://127.0.0.1:8000/etf/admin/escola/t34atividade/?pop=1©=1
Use the Javascript "encodeURIComponent" function for each piece of the URI that's not part of the URI syntax (that is, separator slashes, the question mark for the query string, parameter separator ampersands, etc).
URI encoding is not the same as HTML escaping. For example, you don't escape an ampersand in a URL as &.
IE8 appears to be trying to coerce the query string argument ©=1 to the entity ©, which is the copyright symbol (©). That is actually funny. Just like Microsoft to encumber the user with "help".
Pointy is correct about encoding. Be careful also that you don't have a code minifier that removes everything on a line after a pair of double slashes (//); I've seen those wreck pages before.
The simplest solution I found was to stop using copy as a GET parameter. The problem is that © is actually an HTML entity for the copyright symbol. IE applies an entity replacement converting it to the symbol even though it's in JavaScript code. Apparently Firefox does not perform the entity replacement. According to a comment in this blog what IE is doing might be correct, but to avoid all the mess I just renamed my parameter to clone.
http://nedbatchelder.com/blog/200812/accidental_html_entities_in_urls.html