Wedge
Public area => Bug reports => The Pub => Archived fixes => Topic started by: Arantor on April 7th, 2013, 04:55 PM
-
I don't know if this should even be fixed, but I do want to make record of it.
I have a select, it has a simple onchange, which is to alter the disabled property of another input. Specifically, onchange="$(\'input[name=\"infraction_duration_number\"]\').dostuff();"
The nested quote mark causes issues, but as I said, I'm not sure this necessarily needs a fix - doing something like this is not what you would necessarily call common.
-
You can remove the double quotes entirely. That solves your problem. Or use chr(24) or something like that. I don't remember the number exactly. This will stand for a double quote in one of my upcoming commits which precisely aims to fix that. ;)
-
As it turns out I changed the code to use an id rather than reusing the name but yeah I can now fully understand the need for the workaround as proposed ;)
/meis not really a jQuery / JS guru, not the way he is with PHP
-
It's not that a workaround was needed for this... I've always suppressed double quotes in these situations when embedding in an inline event. It's just that when you include some JSE string in these, sometimes you'll get a double quote, whether you want it to not. Originally it was handled differently (i.e. would convert it to a quot entity), but I recently figured (and documented it) that I could get away with a chr() call, like I'm doing in other situations.
I really need to get started committing stuff...!
-
It's not that a workaround was needed for this...
onchange="$(\'input[name=infraction_duration_number]\').dostuff();"
would have been legal?I really need to get started committing stuff...!
-
You mean
onchange="$(\'input[name=infraction_duration_number]\').dostuff();"
would have been legal?
And even if it didn't validate, it's JavaScript, so it's not processed by validators anyway... :PYou wait until the commit I'm working on lands. I can't do it in bits because it all absolutely has to work together >_< So far, 25 modified, 3 added (will be 4 added by the time I'm finished, I'm not doing Eng-UK until I'm done)
Oh, speaking about Eng-UK, I stumbled upon the Google dev blog, which mentioned that hreflang="..." must use a string like "en-GB", while we're using "en_UK". We don't have "en-GB" in our language strings, but we do have "GB", so it might be possible to build the complete string from scratch by taking the paypal one and adding it to the generic language string, I don't know... What's your say?
Let's see... My uncommitted stuff... 26 modified files, 1 removed file. I'm in the same waters as you are..!
I'll post them in another topic for you to see, if you're curious!
-
And jQuery understands this perfectly, too.
We don't have "en-GB" in our language strings, but we do have "GB", so it might be possible to build the complete string from scratch by taking the paypal one and adding it to the generic language string, I don't know... What's your say?
If only there were some fecking consistency between these fecking things. The locale string is for setlocale, the PayPal one for PayPal, why can't Google accept either of these without having to make its own standard on top? For hreflang, we should supply str_replace('_', '-', $txt['lang_locale'])
On the other hand, the <html> tag also expects a language identifier following ISO 630-1, which is two characters (which is currently provided by $txt['lang_dictionary'], although originally set up for pspell, and no, enchant doesn't use that, enchant uses the locale setting)
Why can't everyone just adopt the locale format and be bloody done with it? >_<