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
