[Prototype-core] Re: JavaScriptLint formatting for Prototype
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.
http://groups.google.com/group/prototype-core/browse_thread/thread/955370df2e66af04/
--
Nick
On 17 jan, 22:38, avillad avill...@gmail.com wrote:
Greetings,
I've been using Prototype for a year or so now and think it is very
useful. I have a web project currently underway, and I have been
integrating JavaScriptLint (www.javascriptlint.com) validation into my
build/test cycle and I run JSL with almost all options turned on after
reading Douglas Crockford's JSLint website and book (Javascript: The
Good Parts).
When I cranked up all the options on JavaScriptLint (jsl), I found
that the Prototype library was producing a number of minor errors and
warnings, from missing semicolons at the end of lines to unbracketed
if clauses. Nothing huge, but my tests were failing. I find that
having all the code checks enabled has helped me catch errors in my
own JS in the past and I like to have all my JS code checked,
including open source libs.
I've submitted a patch (Lighthouse ticket #525) to the current version
of Prototype which fixes all errors and warnings. The ticket includes
the details, including regression tests. Tobie Langel suggested that
I bring up the topic of JSL/JSLint validation on this mailing list.
Apparently fixing the warnings has been suggested in the past but no
action was ever taken. I hope this patch will be seriously
considered: I have already done the work to fix the warnings so it
passes the lint tests.
From a question of code style, my personal opinion is that the
benefits of strict lint checking outweigh the additional burden of
slightly more verbose code. For example,
if (foo 0) bar = undefined; // JSL warning
vs.
if (foo 0) { bar = undefined; } // no warning
I've tried to keep with the code style present in the baseline as much
as possible. I realize I have introduced a few more substantial
structural changes, converting
while(foo = list.next()) { ... }
loops to
for(foo = list.next(); foo; foo = list.next())
in order to avoid assignments within tests, but I agree with Crockford
that this more explicit coding style improves the ease with which the
code can be read and understood.
Please understand that I'm not trying to start a coding-style holy war
here. It seems like more and more blogs are writing about lint for
javascript so I thought others might like to have a version of
Prototype which passed all the tests.
I hope this patch is accepted and committed to the main Prototype
baseline.
Thanks again for the great work on Prototype.
-Dane Avilla
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[Prototype-core] Re: Style Guide for rewrite branch
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 testing, I think we could do better
then simply wrapping everything in closures. Here's what is comes down
to:
// complex test upfront in 'foo' closure.
var foo = (function(){
var REUSED_COMPLEX_FEATURETEST = (function(){
// ...
})();
if (test == simple) {
return function simpleWorkaround() {
// ..
};
}
if (REUSED_COMPLEX_FEATURETEST) {
return function complexWorkaround() {
// ..
};
}
//..
})();
Compared to Feature proposal:
// Reused complex test outside 'foo' closure.
var foo = (function() {
if (test == simple) {
return function simpleWorkaround() {
// ..
};
}
if (Feature.test('REUSED_COMPLEX_FEATURETEST')) {
return function complexWorkaround() {
// ..
};
}
// ..
})();
The optimizations are just an added bonus.
I actually don't think these should be made public.
What's the harm there? Like with Prototype.BrowserFeatures it would
only make things easier internally.
It seems like you favour placing everything inside the different
closures as in my first example. What about complex tests used in more
then one place (dom, selector, array, etc.)?
A namespace like Feature could solve that issue. Perhaps it's not even
an issue right now though but having complex feature tests in one
place with documentation seems more maintainable in the long run.
--
Nick
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Style Guide for rewrite branch
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 things would be a non-issue. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Style Guide for rewrite branch
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 are tested for. The content of
Prototype.BrowserFeatures is currently camelcase, that wouldn't play
well with the uppercase names.
How about not having to run every single one of those tests upfront?
If tests are defined in let's say Feature.tests they can be run only
when required instead of upfront. That would prevent running complex
tests you don't end up using.
Here's a possible implementation using some of kangax' tests:
http://gist.github.com/24895
With this approach, running a feature test would look like this and
the result will be cached for future use.
Feature.test('TREATS_ATTRIBUTES_AS_EXPANDO_PROPERTIES');
---
Nick
On 13 nov, 23:59, kangax [EMAIL PROTECTED] wrote:
On Nov 13, 2:25 pm, Andrew Dupont [EMAIL PROTECTED] wrote:
Here's what this would look like when genericized into an imaginary
API:http://gist.github.com/24571
A couple of things:
(1) I'm altogether in favor of this new approach, but it will result
in less implicit organization of code. A reader of the code will
likely find it harder to scan for the specific method they're looking
for. We'll probably have to address this by marking code sections
with comments.
I would be in favor of having every non-trivial method declaration in
a separate wrapper function. This would make it easier to
distinguish methods and keep all the implementation details in one
scope (avoiding accidental name clashes, etc.). In other words, keep
only one method declaration (together with all the supplementary tests/
methods) in one anonymous function. If we do that, it also becomes
possible to get rid of `Object.extend` and a returning object:
NativeObject.prototype.method = (function(){
var isBugPresent = (function(){
// feature test something...
})();
function original(){};
function workaround(){};
if (isBugPresent) {
return workaround;
}
return original;
})();
On the other hand, there are so many possibilities here that I think
we should do what makes more sense. E.g. if two methods need to use
one helper function or one test, they should probably be combined
under one wrapper:
(function(){
var isBuggy = (function(){
// ...
})();
function originalEscape(){};
function originalUnescape(){};
function workaroundEscape(){};
function workaroundUnescape(){};
if (isBuggy) {
String.prototype.escapeHTML = workaroundEscape;
String.prototype.unescapeHTML = workaroundUnescape;
}
// ...
})();
My only concern about this pattern is memory usage. There are many
functions created during branching process, yet only one is returned/
assigned (and is then used throughout the rest of the application
life). Those alternative functions are stored in a closure (e.g. in a
closure of final function) and so consume memory; every method has a
burden of its branching environment (memory-wise). This wouldn't
happen if we were to use function expressions (rather than function
declarations), but then our methods wouldn't have identifiers:
var someMethod = (function(){
if (doTest()) {
return function(){
// original function
}
}
else return function(){
// alternative version
}
})();
I've never found this to be a problem (i.e. lack of function names)
but Tobie says that having those is useful for debugging. I'm still
not sure if such clarity/convenience worth memory loss. Perhaps this
loss is a non-issue and I'm just being overly paranoid : ) I
definitely like how clean and maintainable such pattern looks, though.
[snip PDoc section]
(3) Simple capability/quirk checks, as in the String#escapeHTML
example, can go directly into the conditional. More complex checks,
like the kind kangax has been working on, will need to be wrapped in
anonymous functions and distilled into booleans. I'd prefer these
booleans to have the naming conventions of constants (e.g.,
TREATS_ATTRIBUTES_AS_EXPANDO_PROPERTIES) so that they can be
recognized easily in the code.
Agreed about capital names. I'm not sure where we should keep feature
tests, though. On one hand, it makes sense to keep them all under
`Prototype.BrowserFeatures`. On the other - it might be a bit
disturbing not to see the actual test implementation in the
appropriate method declaration (where all the branching occurs).
Cheers,
Andrew
[...]
--
kangax
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options,
[Prototype-core] Re: Prototype Selector Engine
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: Hi everyone, recently I heard about Peppy (http://jamesdonaghue.com/?p=40), a new selector engine that is definetly one of the fastest around (http:// jamesdonaghue.com/static/peppy/profile/slickspeed/#). I was wondering if there was a main reason why prototype is so slow compared to it, is it all about extending resulting nodes or is it that our engine is a bit obsolete. Plus, is there actually some people in charge of the rewritting of this module and if not, is there a possibility to port some routine of Peppy to Prototype to benefit from it? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: mouseleave and mouseenter
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 what's needed only once. It also doesn't errors on Firefox
when you mouseover the input elements.
Custom events are not the best way to implement this since custom
events bubble. See the Lighthouse ticket for more details
http://prototype.lighthouseapp.com/projects/8886/tickets/350
--
Nick
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: IE onmouseleave
Diego, on IE custom events can't be cancelled. fireEvent will always
fire an event that bubbles.
http://msdn.microsoft.com/en-us/library/ms536423(VS.85).aspx
That's why I'm for making Element#observe handle mouseenter/leave in
the core. Firing and then filtering custom events goes against the
point of making this easy to use. These events should not bubble, this
can't be done with custom events, therefore the observe approach is
the better one.
I've been saying this for some time but custom events seem to be used
as an excuse not to implement this properly, like other frameworks
have done. Of course it can be done with custom events but it's
clearly not the best approach. Ah well, I guess this needs more time
before others draw the same conclusion.
--
Nick
On 11 jun, 03:08, Diego Perini [EMAIL PROTECTED] wrote:
I am probably missing something, but...
Why not use mouseover / 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 that shows how to do it with custom
events:http://github.com/savetheclocktower/javascript-stuff/tree/master/cust...
It's not as convenient as real mouseenter/mouseleave behaviour,
because these event will bubble. Child elements will fire mouse:enter/
mouse:leave events onto their parent. You'd have to filter out these
unwanted event before this will work.
I'd prefer something similar as the patch Ken posted implemented into
core. It doesn't have the overhead and is much more convenient since
it allows you to do this:
$(element).observe('mouseleave', handler);
jQuery and Mootools use a similar approach. It's much closer to the
spec, since it doesn't involve event bubbling like the real mouseenter/
mouseleave events.
On 10 jun, 21:10, Alex K [EMAIL PROTECTED] wrote:
Hi Guys, I've suffered IE weird bug:
this browser sends onmouseout events even if the mouse is actually
within the scope of the element, this happens when the mouse is over
the child element. There is a way to solve this, IE send the proper
event with name 'mouseleave', so my code looks like:
//one more weird IE bug
var mouse_out_event_name =
Prototype.Browser.IE?'mouseleave':'mouseout';
Event.observe(list_item,mouse_out_event_name,this.onmouseout.bindAsEventListener(this));
Just a thought that it can be handled by the lib to save time of other
folks,
Thanks,
Alex
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: IE onmouseleave
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 mouse:enter/
mouse:leave events onto their parent. You'd have to filter out these
unwanted event before this will work.
I'd prefer something similar as the patch Ken posted implemented into
core. It doesn't have the overhead and is much more convenient since
it allows you to do this:
$(element).observe('mouseleave', handler);
jQuery and Mootools use a similar approach. It's much closer to the
spec, since it doesn't involve event bubbling like the real mouseenter/
mouseleave events.
On 10 jun, 21:10, Alex K [EMAIL PROTECTED] wrote:
Hi Guys, I've suffered IE weird bug:
this browser sends onmouseout events even if the mouse is actually
within the scope of the element, this happens when the mouse is over
the child element. There is a way to solve this, IE send the proper
event with name 'mouseleave', so my code looks like:
//one more weird IE bug
var mouse_out_event_name =
Prototype.Browser.IE?'mouseleave':'mouseout';
Event.observe(list_item,mouse_out_event_name,this.onmouseout.bindAsEventListener(this));
Just a thought that it can be handled by the lib to save time of other
folks,
Thanks,
Alex
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: DOMContentLoaded for IE
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 workarounds. On 12 mei, 03:26, John-David Dalton [EMAIL PROTECTED] wrote: Nick, A little OT (non-related to Prototype) but here is more info on your issue of IE operation aborted. I had to patch it for the PHP framework we use. Fix IE Operation Aborted bug by inserting script elements at the bottom of the body element.http://www.ryangrant.net/archives/internet-explorer-cannot-open-the-i...http://weblogs.asp.net/infinitiesloop/archive/2006/11/02/Dealing-with... - JDD --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Opera 9.5 and document.viewport
It's good to see Opera is trying to be more like the other browsers. But we'll still have to add backwards compatibility for the older version. Luckily version targetting in Opera is easy since later version all have window.opera.version(). I've added a patch to the ticket using it to fix 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 in strict mode behaves just like Firefox and IE 6 in strict mode, so the above code will not work. Under Opera 9.5 strict, the current code will return the height of the body, not the viewport. But in Opera 6 to 9, document.body.clientHeight is always the height of the viewport, so a generic browser check won't suffice. So to summarize, viewport.getDimensions() is broken under Opera 9.5 strict but works fine in Opera 9.5 quirks, which is the opposite of what one would expect. I know Opera 9.5 is a beta, but surely its new behavior is intentional. -- Matthew Leverton --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Cross-browser Event.simulateMouse [bump via kangax]
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 ;) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Adding Prototype.Revision
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') //- 1600
vnum('1.6.0.2') //- 1602
vnum('1.6.0_rc1') //- 1599
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Adding Prototype.Revision
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 suggested to add the svn changeset number to Prototype. I think that is a much better way to go. Adding something like Prototype.Revision will help Scriptaculous and other extensions to write proper version checks. What do you think, is it something worth adding? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Adding Prototype.Revision
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 be much more machine readable, which
is the use case here.
I'd like to have other core members' opinion on this.
And contrary to what I mentioned earlier, I'm not sure if the svn
changset number is the way to go as we sometimes backport bug fixes to
earlier versions of Prototype.
Best,
Tobie
On Feb 3, 4:39 pm, artemy tregoubenko [EMAIL PROTECTED]
wrote:
Latest Prototype
here:http://prototypejs.org/assets/2008/1/25/prototype-1.6.0.2.js
has following lines at the top:
var Prototype = {
Version: '1.6.0.2',
Isn't this enough?
I think using revision number is mostly replacing one readable number with
another unreadable. I believe versions are already mapped to specific
revisions, and using intermediate revisions is a dangerous way to go.
But if someone really needs this - why not? Except that usually such
specific needs aren't put in the core, afaik.
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 suggested to add the svn changeset number to Prototype. I think
that is a much better way to go. Adding something like
Prototype.Revision will help Scriptaculous and other extensions to
write proper version checks. What do you think, is it something worth
adding?
--
arty (http://arty.name)
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Adding Prototype.Revision
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') //- 1600
vnum('1.6.0.2') //- 1602
That is because none of the version fragments will ever be bigger than 9.
That's nice. I went into more trouble to make so Scriptaculous'
version could be checked, it sometimes has '_pre1' or '_beta2' in it's
version string. But I see a little more regex could do the same there,
good idea.
Even though it could be that simple, a build number will make this
more user friendly. You could then simply do:
Prototype.Build Prototype.Build = 1602
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Adding Prototype.Revision
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 though Scriptaculous packs the latest build of Prototype, not everyone uses that one. So informing them to upgrade for everything to work correctly is important. Another example is that in some of my extensions I require 1.6.0.2 to get document.viewport.getDimensions to work correctly. The 4 digit releases are just as important. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
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. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
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 at Ext.js adapters. Writing something similar for your unittests is easier then getting every framework to implement noConflict. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Improving document.viewport.getDimensions()
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 point out the issues in the current function I've added unit tests.
They show that resizing an element { position: absolute; top: 0; left:
0; } to the viewport causes change in document properties. Those
properties should not be affected.
When resizing and showing overlay layers for example (lightbox), this
will add extra scrollbars in browsers where those document properties
are affected. The unit test I've added will run this example as a
test.
Patch and Unit test: a href='http://dev.rubyonrails.org/ticket/
10148'http://dev.rubyonrails.org/ticket/10148/a
Thanks for checking it out,
Nick
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
