I remember the last time this discussion was brought up it ended in
Prototype is perfectly valid Javascript, we don't need to conform to
JSLint. I still believe there's no need to pass Crockford's
validation, it would take the style out of Prototype.
You mean return function someNamed() { ... }, right? That's fine by the
specs
Love it.
Let's not prematurely optimize.
My proposal isn't just an optimization but a different approach for
the more complex tests used throughout the library. You asked for
feedback on how to handle feature
Whenever you make something public, you have to continue supporting
it. This makes refactoring more complex.
Yeah, but if those tests are in one place there's not much complexity
to it.
If Prototype itself was wrapped in a closure beautifying the internals
would become so much easier, these
If a feature test ends up being used in various sections (dom, event,
string..) deciding on proper placement could become a problem. I think
it's easier to keep feature tests in one place.
Prototype.BrowserFeatures doesn't seem like the right place for those
tests since both features and bugs
Sizzle[1] is probably closer to a stable release, John mentioned
releasing it before the end of the month. Looking at those benchmarks,
having something similar wouldn't hurt (1.6.1?).
[1] http://github.com/jeresig/sizzle/tree/master
--
Nick
On 22 okt, 15:58, Simon [EMAIL PROTECTED] wrote:
On 1 okt, 19:15, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
here's a version that uses custom
events:http://neverninetofive.com/mouseenterleave/
Calling invoke('observe') and invoke('stopObserving') like that is
overkill. The patch I've posted is much easier on the browser since it
observes
/ mouseout on all browser and then use
event.stopPropagation() method or event.cancelBubble=true for IE ?
Are there browsers where the bubbling phase of these events can't be
cancelled ?
--
Diego Perini
On 10 Giu, 21:58, Nick Stakenburg [EMAIL PROTECTED] wrote:
Andrew has a script
Andrew has a script that shows how to do it with custom events:
http://github.com/savetheclocktower/javascript-stuff/tree/master/custom-events/mouse_enter_leave.js
It's not as convenient as real mouseenter/mouseleave behaviour,
because these event will bubble. Child elements will fire
Thanks John.
My point is that dom:loaded should ensure a successful appendChild on
document.body in all cases, not throwing the random IE Operating
Aborted. Using the scroll approach ensures this, it's more accurate
then the current implementation and will prevent having to use those
the problem.
--
Nick Stakenburg
On 6 mrt, 06:07, Matthew [EMAIL PROTECTED] wrote:
The relevant code in version 1.6.0.2 is:
dimensions[d] = (B.WebKit !document.evaluate) ? self['inner' + D] :
(B.Opera) ? document.body['client' + D] :
document.documentElement['client' + D];
Here Opera 9.5
Yes there might be a better/more complete possibility, and someone might do
it in the future
I think I'd rather see an incremental fix now; AND wait for someone to write
an even better version later.
Perhaps once this patch is in, someone else will look at it
You could be that someone ;)
Based on Mislavs function here's on that also handles special cases
like _rc1.
function vnum(vstring) {
var v = vstring.replace(/_.*|\./g, '');
v = parseInt(v + '0'.times(4-v.length));
return vstring.indexOf('_') -1 ? v-1 : v;
}
vnum('1.6.0') vnum('1.6.0_rc1') //- true
vnum('1.6.0') //-
I recently wrote a patch for Scriptaculous that allows version
checking beyond the x.x.x scope. It allows to check for 1.6.0.2
instead of just 1.6.0, this will help to inform people when they use
incompatible version of prototype/scriptaculous.
http://dev.rubyonrails.org/ticket/10966
Tobie
A build number based on both version and svn changeset could prevent
those issues with backported bugfixes.
A suggestion: Prototype.Build: 1602.8769
On 3 feb, 17:13, Tobie Langel [EMAIL PROTECTED] wrote:
Hi Artemy,
The version number is just a pain to parse.
A build number also happens to
I think we should have both version string and SVN revision from which it
was built.
Also, Prototype versions could simply be compared like integers in this
fashion:
function vnum(vstring) { return parseInt(vstring.replace(/\./g, '') +
'0'.times(4-(vstring.length/2).ceil())) }
vnum('1.6')
However I don't see a reason for Nicks patch. If you need to check the 4th
digit of version number due to compatibility issues then we have an
issue
.: Fabian
A lot of questions on irc #prototype relate to people not using the
correct version of prototype/scriptaculous together. Even
Is it worth the extra bloat so that some people can use noConflict? I
don't think so, most people never use noConflict. People who want to
have multiple frameworks play together should think twice.
Maybe that's just me, but I wouldn't want to stimulate people into
mixing frameworks.
On 30 jan, 17:22, Dr Nic [EMAIL PROTECTED] wrote:
Alternately, can I have permission to make unittest independent of
prototype? :P
I did look at it _very briefly_ and realised that I just needed to
cleanup the use of $.
If multi framework unittests is what you want, you should have a look
I'm hoping document.viewport.getDimensions() can be improved.
At the moment I'm using a patched version in a href='http://
www.nickstakenburg.com/projects/prototip'Prototip/a to keep
tooltips within the viewport, as it works better then the method from
trunk. Mootools uses a similar approach.
To
19 matches
Mail list logo
