Ok, then let me try this:
Keypress, keydown/up and textInput handling is broken in the browsers.
jQuery makes that better AND WORSE. Please discuss.
See my previous message to see what I think can be done about it.
Clifford Heath.
On 08/01/2010, at 3:14 PM, John Arrowwood wrote:
Probably has
Probably has to do with the volume of messages on the list. I've had
similar experience, though I try to pitch in when I can.
On Thu, Jan 7, 2010 at 7:56 PM, Clifford Heath wrote:
> Why can't I get a response when I write here?
>
> I've posed serious questions, and offered serious
> solutions, b
Why can't I get a response when I write here?
I've posed serious questions, and offered serious
solutions, but nothing, niente, nada. What gives?
Sorry to be so direct, but nothing else has worked.
Clifford Heath.
--
You received this message because you are subscribed to the Google Groups
"j
On Jan 7, 5:26 pm, John Resig wrote:
> Since we're going to be using JSON.parse, which throws an exception
> (and triggers the Ajax error handler) it should probably be consistent
> across platforms.
well it might not be consistent across platforms, since in CHROME
window.JSON.parse will happil
@John, I did not say it clearly, so I will do it now: I agree 100%
with no-compromise approach to "non-standard" (aka illegal) JSON
strings. It is only that in reality, there are well known and
(commercial) paid for RESTfull services, which return this wrong kind
of JSON. Especially this kind :
> That's all nice & dandy for json. But the "javascript getting executed
> solely on server saying so" problem still remains. The fact you had to
> change the synchronous request tests is a clear proof of the problem to me:
> existing code will break (no issue if documented), existing code will fac
That's all nice & dandy for json. But the "javascript getting executed
solely on server saying so" problem still remains. The fact you had to
change the synchronous request tests is a clear proof of the problem to me:
existing code will break (no issue if documented), existing code will face a
secu
Since we're going to be using JSON.parse, which throws an exception
(and triggers the Ajax error handler) it should probably be consistent
across platforms. I backported some syntax-checking logic from
json2.js and now throw an exception if it doesn't look like it's
proper JSON (which prevents atte
On Thu, Jan 7, 2010 at 11:04 AM, Douglas Crockford
wrote:
> I strongly recommend that you not compromise on safer.
Unfortunately we're in the very challenging position now where
introducing the use of window.JSON will absolutely break some
jQuery-using applications - and will continue to do so fa
@Juilan, believe me I was on the JSON secuirty issue more than once
with Mr Crockford.
The issue I have pointed out is that one can have whole functions as
symbol names in JSON.
And then execute them with an inoccently looking "sleeper"
On Jan 7, 2:49 pm, Julian Aubourg wrote:
> What I'm worried
What I'm worried about is attacks on existing pages.
So far, in jQuery, executing javascript was borded to conscious actions by
devs:
- inserting HTML in the document (ajax doesn't execute embedded script
automagically),
- jsonp,
- specific ajax wrappers (getScript, load) or cross-domain access to
> btw, I also saw you landed an auto-fetching for script (FYI, I
> "synchronized" the rewrite with latest changes, including javascript
> auto-execution) but I believe it is just plain wrong to let the server
> decide of what should be executed client-side (especially with cross-domain
> xhr gettin
I'll quote what I said in the $.ajax "auto" discussion (see last 2
paragraphs especially):
> > There's something significant behind the buzz, though. I really don't
> want
> > to read the announcement: "ATTN everyone using jQuery.ajax(). If you're
> > going to update your library or if you're link
Browsers don't provide height/width information for elements when
they're display: none (or within a display: none element). There is no
workaround for it - other than making the element not display: none.
Sorry :-/
Naturally, if an alternative is ever developed for retrieving the
height/width of
We already support non-standard JSON strings since that's what we've
always supported. We do so by putting a try/catch around the
JSON.parse and falling back to the new Function technique, if an
exception is thrown.
Fundamentally though, using JSON.parse is faster and safer (although,
if we use th
Sensible approach. But how is the following issue of using "non
standard" JSON strings solved :
IE8:JSON.parse("{ 'a':1 }") ---> Syntax Error
CHROME:JSON.parse("{ 'a':1 }") ---> OK
FF: JSON.parse("{ 'a':1 }") ---> Syntax Error
OPERA 10.10: JSON.parse
16 matches
Mail list logo
