+1 As gf3 mentioned, there are frequent questions about this in
#prototype. Right now we have nothing factual to offer :-)
On Apr 8, 2:58 am, "T.J. Crowder" wrote:
> +1 on more information outside the core team on where Prototype is
> headed, agnostic as to what form it takes. Since this is the c
+1 on more information outside the core team on where Prototype is
headed, agnostic as to what form it takes. Since this is the core
mailing list, it seems like it would be here, but I don't recall
mention of the new layout stuff or "on" here. (Could be my memory,
though.)
-- T.J.
On Apr 8, 12:06
Hi folks,
I'm being dense, there's already the outline of a roadmap:
http://prototype.lighthouseapp.com/projects/8886-prototype/milestones
There are milestones for 1.6.0.3 (completed), 1.6.0.4, 1.6.1, and the
inline documentation.
I don't know what the release with the big changes is going to be
On Oct 23, 5:12 pm, "T.J. Crowder" <[EMAIL PROTECTED]> wrote:
> Hi folks,
>
> Now that 1.6.0.3 is out the door (kudos!!), is there work toward a
> roadmap for 1.6.1, 1.6.2, and (gasp) 2.0 in the works? Obviously
> there was that discussion thread recently, but it was a lot of
> discussion and rel
First and foremost: handling the bug backlog.
I'm currently working on extracting and revamping the unittest (that
should be out pretty soon).
Ajax needs some love (for 1.6.1)
Dimensions work by Andrew.
...
On Oct 23, 11:12 pm, "T.J. Crowder" <[EMAIL PROTECTED]> wrote:
> Hi folks,
>
> Now th
I don't have anything specific that I'd like to see in Prototype. The
event delegation sounds excellent! I'm happy it will fix the memory
leak that's been plaguing me because of it.
My general feeling is that we should implement some new features that
get developers excited about Prototype. The
Any thoughts about a script.aculo.us 2 roadmap?
Maybe this is not the place to ask, but I had to try...
On Thu, Jul 3, 2008 at 5:13 PM, Nick Stakenburg
<[EMAIL PROTECTED]> wrote:
>
> I'll throw in some things:
>
> * mouse(enter|leave) events: Would be a big plus. I don't like the
> idea that Pro
I'll throw in some things:
* mouse(enter|leave) events: Would be a big plus. I don't like the
idea that Prototype authors have to write up hacks while other
frameworks have had this available in core for some time now. If this
is added using custom events it will require
* Firing non-bubbling eve
Viktor Kojouharov wrote:
> Ken, wouldn't Enumerable.addMethods be just a wrapper around
> Class.addMethods? Like Class.addMethods(Enumerable, methods)
>
>
No because Enumerable is not a class, it is a mixin or collection of
methods. Adding methods to or extending the Enumerable mixin leaves
Ken, wouldn't Enumerable.addMethods be just a wrapper around
Class.addMethods? Like Class.addMethods(Enumerable, methods)
On Jul 3, 7:31 am, "Ken Snyder" <[EMAIL PROTECTED]> wrote:
> Yes, those escapeHTML fixes are what I was thinking.
>
> I'm excited to see Event delegation!
>
> Also, I wanted t
All good additions, Ken.
Regarding Enumerables, we were actually considering a late-bound mixin
implementation. If we were to use such pattern, any objects that mix
Enumerable in, would automagically have methods that are added to
Enumerable later on. That would obviously work for any other mixin
Yes, those escapeHTML fixes are what I was thinking.
I'm excited to see Event delegation!
Also, I wanted to suggest some more ways to extend and customize Prototype:
*Event.addMethods* to allow adding methods to Event instances (
http://prototype.lighthouseapp.com/projects/8886-prototype/tickets
element.match is a boolean operator that tells you if a given element
matches a css selector.
so if you're observing document.click (delegation) and you want to know if
the element was clicked was a particular one...
(this is not an actual example)
if(e.element().match('div.fieldset div.subfield i
@Gareth Evans
* 1.6.0.3 will automagically stopObserving on Element#update.
Element#remove doesn't automate this because you could keep a
reference to the element.
In 1.6.1 it might be a non issue because the Event system may
avoid the memoryleak issue alltogeather
and not have to wo
Automagical stopObserving on update/remove?
Event delegation modification in core (so you can attach delegated events to
observe instead of having to write the same document.observe pattern with a
series of if-s and element.match(cssSelector)?
Gareth
On Thu, Jul 3, 2008 at 9:51 AM, kangax <[EMAIL
+1 for hasProperties/isEmpty
I would also want to see #setProperty.
Ken, which #escapeHTML fix are you talking about? We actually made few
changes in a current trunk.
Besides what was mentioned:
- deprecate Try.these
- deprecate Array#reduce (for compatibility with FF3+)
- update String#isJSON
Is avoiding document.write() for IE dom:loaded included in 1.6.1? I
think the core team concluded that doScroll was the way to go, but I'm
not sure.
What about fixing String#escapeHTML for IE and WebKit?
What about enhancing Element#siblings to accept a selector?
(http://groups.google.com/gr
Also utilizing element.ownerDocument more (this will help in
compatibility with iframes).
Maybe a Element#getDocument(), getBodyElement, getRootElement.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core
18 matches
Mail list logo
