On Feb 18, 12:22 pm, Marius Feraru <[EMAIL PROTECTED]> wrote: > So, the only issue still standing in this paragraph is "how to detect > different versions". People [1] think the right choice is not "browser > detection", but "object detection". This is a very weary subject, I don't > really want to reiterate it. > FWIW, I'll just say Prototype folks did the (almost) right thing by > never-saying-never (to "browser detection") and you have seen examples right > in "setStyle" (kludging "opacity" with "filter" for all versions of MSIE, or > choosing to replace "full opacity" - 1 - with 0.999999 for all Geckos). > Yes, it's a real PITA, but we really have to deal with all these annoying > bugs. I'm sure there are better ways, we just have to discover them. > So, please help us ;-)
We recognize this issue and are working on a better way to handle the browser checks in Prototype. Ticket #6800 [1] is our attempt to standardize browser checks and remove redundancy. I expect Sam to apply this patch soon, at which point we can change nasty stuff like... if (/Konqueror|KHTML|Safari/.test(navigator.userAgent)) to... if (Prototype.Browser.WebKit) I also think Mislav's patch (moving the browser checks from "inside" the functions to "outside") is a very important one. The patch itself is outdated, but I think it's an issue we need to revisit. > Depends on your purposes. Now that you mentioned "ruby", AFAICT ruby folks > don't give a rat's ass about performance (yet), they want to create an > elegant programming language. Performance? Later on, they're still young. > Maybe that is (should be) the case with Prototype too ;-) The modus operandi for Prototype these days is to optimize after the fact. First we try to write elegant code; only then do we make sacrifices in the name of optimization. On the small scale, this often means replacing Enumerables with ordinary for loops; on the large scale, it means a total rewrite of $$ like the one that's happening right now. To illustrate: I'm not interested in making $$ the fastest selector query engine on Earth. To shave milliseconds off of DomQuery or dojo.query would take far more lines of code than I'm willing to write. I'm interested in making $$ *fast enough* that it's practical to use on a regular basis. Performance is not our chief goal, but it shouldn't be a deal-breaker. 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 [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~----------~----~----~----~------~----~------~--~---
