Thanks for the answer, I understand the performance drop is a far more
important issue, I just hoped there would be an easy solution.

But just to be clear - I didn't want Prototype to force *other*
browsers to behave as WebKit but to force WebKit to behave as others.
So when I do Object.toJSON({elm:HTMLDIVElement}) it wouldn't end on
error but with {elm:{}} instead.

Best regards,
Andris Reinman

On 5 märts, 10:48, Andrew Dupont <goo...@andrewdupont.net> wrote:
> On Mar 3, 2011, at 2:40 AM, andris wrote:
>
> > The question is, should Prototype address it or is it a developers
> > problem? Isn't the work of a JS library to smooth out these kind of
> > inconsistencies - for example either falling back to a non native
> > encoder with WebKit or forcing other browser to follow the same rules?
>
> Falling back to a non-native encoder isn't an option; it would result in a 
> _massive_ performance drop, an issue far more severe than the one you're 
> describing.
>
> Forcing other browsers to follow the same rules isn't an option; not only 
> would it require us to do non-native JSON encoding for certain code paths, it 
> would also require us to comb an object for any references to host objects to 
> know whether or not we'd need to bypass the native encoder.
>
> So it's got to be the developer's problem because there's nothing Prototype 
> can do, even if we wanted to.
>
> Cheers,
> Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en

Reply via email to