Re: [Prototype-core] Re: event memo modified is evaluated to false
Tobie,
If that's so, then we should explictly forbid memo not being an object,
shoudln't we? Or at least make this crystal-clear in the docs. The
current docs only state memo: metadata for the event.
Otherwise, you can pull my commit b1bfdd5, fresh off the current main
master :-)
Le 26/03/2010 12:30, Tobie Langel a écrit :
The reason for this design choice was to avoid the following
altogether:
if (event.memo) {
foo = event.memo.foo;
}
and allow this instead:
foo = event.memo.foo;
There are memory costs involved with this design choice, but these can
easily be mitigated by passing in a value to the second argument of
Event.fire.
The contract this API tries to make is to systematically return an
object.
I think we should respect that.
Best,
Tobie
On Mar 26, 9:50 am, Christophe Porteneuvet...@tddsworld.com wrote:
Hey C dric,
Hmmm, I'd have to double-check the codebase for justification of this
defaults, but even if it turns out to be useful, the implementation
seems clearly faulty. It should go something like:
event.memo = (undefined === memo ? {} : memo);
Thanks for the heads up.
--
Christophe Porteneuve aka TDD
t...@tddsworld.com
--
Christophe Porteneuve aka TDD
t...@tddsworld.com
--
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
To unsubscribe from this group, send email to prototype-core+unsubscribegooglegroups.com
or reply to this email with the words REMOVE ME as the subject.
[Prototype-core] Re: Deprecated API documentation
Both ideas look rather good, although we need to consider line wrapping with the fairly long marker. While strikeout can look ugly (but then, it's a fairly subjective point of view), it's become a fairly commonplace representation of deprecated APIs (see most syntax autocompleters and class browsers in IDEs, for instance), and has immediate visual impact. -- Christophe Porteneuve aka TDD [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: isNumber or Not A Number ??
Станислав Анисимов a écrit :
Shouldn't Object.isNumber('111') be true?
Nope. '111' is a String.
--
Christophe Porteneuve aka TDD
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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: Unexpected/unwanted porn here
Franck PORCHER a écrit : Receiving unexpected porn ads through this mailing list :-( Owner, thanks for removing the sender adress ([EMAIL PROTECTED]) from this group. Yeah, we get annoying spam in here… As for the unsub, you can do it yourself either through the email interface (I think emailing [EMAIL PROTECTED] works) or online at Google Groups. -- Christophe Porteneuve aka TDD [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: New Name for Users Group (RoR Spinoffs)
My question is, when users search Scriptaculous in Google, don't they get script.aculo.us results? 'course they do, tons of it, and the dot-split mark appears as an actual match. So I think we should preserve the spelling (I know it's dear to Thomas) and not worry about it, I'm pretty convinced it's a non-issue. -- Christophe Porteneuve aka TDD [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Array.indexOf and strict equality
T.J. Crowder a écrit : So I'll file a ticket, my only question is whether I should file it against the code or the docs. ;-) File against the docs :-) This implementation is conformant to Mozilla's and IE8's implementation of the recent Array#indexOf extension. -- Christophe Porteneuve aka TDD [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Hash no longer works with templates/interpolate()
Mislav Marohnić a écrit : I'm torn between teaching Hash to respond to toTemplateElements or teaching Template to try toObject after toTemplateElements is unavailable. What do you guys think? The second version seems totally overreaching. If we do that AT ALL, I'd favor: Hash.prototype.toTemplateElements = Hash.prototype.toObject; This being said, I don't think there's a massive reason to add this orthogonal feature to Hash: people who want to use an actual Hash as a source object to a template should pass myHash.toObject() instead of just myHash... -- Christophe Porteneuve aka TDD [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: strip method of String class.
Mislav Marohnić a écrit : Erm, you sound like it's a hog. In fact, we've benchmarked it vs. a single regexp and it didn't do so well - that's why is the original 2-pass replace still in. Really? I had benchmarked the single-regex one on FF1.5 and FF2 and it *was* much faster on large string sets (not necessarily large strings). However, lemme guess... Safari b0rks? ;-) -- Christophe Porteneuve a.k.a. TDD [They] did not know it was impossible, so they did it. --Mark Twain Email: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: strip method of String class.
Miha Zimin a écrit :
strip: function() {
return this.replace(/^\s+/, '').replace(/\s+$/, '');
}
I can't even BELIEVE we still have that in place. I thought I had fixed
this ages ago. We'll have to patch that...
--
Christophe Porteneuve a.k.a. TDD
[They] did not know it was impossible, so they did it. --Mark Twain
Email: [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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: /script and ] in a regex confuses the Fox
Hello there, W. Niu a écrit : I'd just like to report a small issue I encountered when trying to upgrade from 1.5.0 to 1.5.1. I suspect this is more likely to be an issue from Firefox (2.0.0.3) script parser though. Actually it's no issue, it's entirely nominal. HTML mandates that an opening script tag should be closed at the soonest /script, without any specific processing of the text in-between. There is no parsing of the embedded JS until the closing tag is isolated. I am using a web framework which automatically read up all *.js files into the main page and place them into the following script block (don't ask me why, I am only using that framework for research purpose): Please tell us the name of this framework, just so that I don't end up inadvertently using it. Not only does this practice goes against UJS, it most importantly prevents any caching strategy. I can't imagine why the authors of the framework chose this path, which seems to have a strictly negative cost. with an actual closing one (because of the angle brackets). Is there a quick fix at your (Prototype team) side to avoid it? If not, I will We probably won't include the quick fix in the main distro (although Core may decide to eventually), but you should be in the clear by simply putting a backslash before the closing slash: ScriptFragment: 'script[^]*([\u0001-\u]*?)\/script', That won't affect the semantics of the regex, and should prevent the (X)HTML parser from considering it as the closing tag of your wrapper script element. -- Christophe Porteneuve a.k.a. TDD [They] did not know it was impossible, so they did it. --Mark Twain Email: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Bug in Position.cumulativeOffset
Tom Gregory a écrit : 1) Does this solution continue to work when borders are assigned with element/class selectors, rather than inline? Probably not, as the style property does not always contain computed styles, as Thomas will gladly tell you (and as Scripty's code is ample proof of). 2) I seem to recall there is something screwy with how borders are handled in IE's broken box model. How would that affect this solution, if at all? It's not just IE, it's QuirksMode. In quirks, the width and height values *encompass* padding and border. In standards mode, they are only the content area (they are within the padding). On every browser out there (well, on IE6+ and others, that is), if your document explicitely refers to a strict DTD, you're in standards mode in this respect. JS code dealing with this issue should probably not much care about quirks or standards: it's the page developer's responsibility to style according to their DTD ref (or lack thereof). -- Christophe Porteneuve a.k.a. TDD [They] did not know it was impossible, so they did it. --Mark Twain Email: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Form.serialize, Ajax.Request, Hash.toQueryString, .toQueryParams
Colin Mollenhour a écrit : Sweet, no replies.. I guess I've worn out my welcome with the Prototype Core team. No problem, I'll just go back to waiting for final versions and keep my opinions and code to myself. Oh I've always wanted to say this, but Christophe your contributions to the Spinoffs list are amazing, I don't know how you find the time... Why, thanks Colin. AAMOF, I find much less time these days, with my book getting overdue... Don't be put off by Core not addressing your suggestions in a timely fashion. We're all pretty busy these days, and trying to keep the feature array of Prototype, especially regarding the plans for 1.5.1, 1.5.2 and 1.6, in reasonable consistence. I haven't read the long list of replies to your post from Tobie, Andrew and Mislav yet, but we do value your feedback and contributions, which have always been pretty good. We're just a bit overloaded these days. -- Christophe Porteneuve a.k.a. TDD [They] did not know it was impossible, so they did it. --Mark Twain Email: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: $$() and checkboxes checked property
Hey there, Which exact version of Prototype are you using? -- Christophe Porteneuve aka TDD [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Dean Edwards new library
Hey, Mislav Marohnić a écrit : Danger. The page loads 2.5 MB of scripts and dojo.js makes tens of XHR (synchronous!) requests which all result in 404s (!). This can seriously hurt your browser! WTF is Dean doing? This page goes against every principle of pageload efficiency! It's not like him at all... It took my browser 1.24min for 512 requests to load this thing. The Firebug Net view for it is hilarious. At any rate, it will be interesting to look at his code. -- Christophe Porteneuve aka TDD [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Node Insertion Methods
Hey, Tobie Langel a écrit : append = Insertion.Top prepend = Insertion.Bottom OK, but... the other way around! :-) -- Christophe Porteneuve aka TDD [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: $$() and :nth psuedo-elements
Hey Andrew, Andrew Dupont a écrit : I'm frustrated at the ambiguity of the CSS3 spec on this issue. See for yourself at (http://www.w3.org/TR/2001/CR-css3-selectors-2003/ OK, start by using the latest version, OK? http://www.w3.org/TR/css3-selectors/ #nth-child-pseudo). The spec says that a and b must be zero, negative integers or positive integers, but does not give any examples in which b is negative -- neither in the spec nor in the test suite. It's much better expressed in the latest version. For instance: The value a can be negative, but only the positive values of an+b, for n≥0, may represent an element in the document tree. html|tr:nth-child(-n+6) represents the 6 first rows of XHTML tables When the value b is negative, the + character in the expression must be removed (it is effectively replaced by the - character indicating the negative value of b). :nth-child(10n-1) represents the 9th, 19th, 29th, etc, element :nth-child(10n+9) (same) :nth-child(10n+-1) (Syntactically invalid, and would be ignored) Based on this, I'll review your latest parseNth today ;-) -- Christophe Porteneuve a.k.a. TDD [They] did not know it was impossible, so they did it. --Mark Twain Email: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: $$() and :nth psuedo-elements
Hey Trevan, Trevan Richins a écrit : The new version of $$() is wonderful but doesn't seem to work all that well with the :nth psuedo-elements. It looks to only work correctly when in the formula an+b, a and b are positive and b a. I don't know if anyone has noticed this yet, but I couldn't find a bug id so I filled a new one and added a possible fix for it (as well as test cases). The bug is at: http://dev.rubyonrails.org/ticket/7841. Thanks for the heads up. It's possible, due to the code's freshness, that there are still bugs. The negative values, in particular, are very likely not handled, although I'm surprised about the b a thing. I (and Andrew, no doubt) will look into it ASAP. As a small note, $$ does not implement any pseudo-element, but pseudo-classes. Pseudo-elements, as their name implies, do not select *elements*. They select fragments, or sometimes as-yet-empty locations (:first-letter, :first-line, :before, :after, :selection). -- Christophe Porteneuve a.k.a. TDD [They] did not know it was impossible, so they did it. --Mark Twain Email: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: #7826 Ajax.Updater: evalScripts should happen before onComplete
Marius Feraru a écrit : Would/could anybody edit this ticket's subject to add the proper [PATCH] prefix? TIA :) http://dev.rubyonrails.org/ticket/7826 Trac's down just now. But if you look at the source, evalScript DOES happen before onComplete (after onSuccess/Failure, though, which is consistent with automatic JavaScript eval for JS-typed responses in Ajax.Request). -- Christophe Porteneuve a.k.a. TDD [They] did not know it was impossible, so they did it. --Mark Twain Email: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: suggested documentation update for $$()
Marius Feraru a écrit : Could you please explain why do you think this breaks W3C specs, as I cannot see it, neither at level 3 [1], nor at level 2 [2]? TIA. Indeed, this doesn't break the specs. Lexical scanning clearly states that both single and double quotes can be used. Which is why I went to so much Regex trouble to deal with both types, and make sure they match ;-) -- Christophe Porteneuve a.k.a. TDD [They] did not know it was impossible, so they did it. --Mark Twain Email: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Associative Array
This is the exact bug with Hash.toQueryString that was discussed in a thread less than an hour ago (about serialize). See my previous posts today. -- Christophe Porteneuve aka TDD [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Running in circles!
Hey Richard, Richard Quadling a écrit : But this doesn't give me a .inspect() method and there is no Object.create() method. Of course. Why would it? If you look at Prototype's source, you'll see that any object having an inspect method implements it (Array, String, Hash, and the like). This is because nobody can guess for you what inspect() should do for your specific class. There is also no such thing as Object.create. Anywhere. Except for Class.create. Creating a new object is done using the new operator, as in: var fpn = new class_FaxPageNumber(); NOTE: I only want to define the class to inherit the Object methods. Prototype classes don't inherit a thing. They only provide a initialize convention for the constructor, and Object.extend spares you having to manually deal with the native JS syntax, which is slightly more outlandish. -- Christophe Porteneuve aka TDD [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Running in circles!
Hey Richard, Richard Quadling a écrit : So, I suppose, how do I inherit Object into my class? All methods in Object are designed for static use (they only operate on their parameters, never using this), so I fail to see why you would want to inherit those... Are you sure you understand Object properly? -- Christophe Porteneuve a.k.a. TDD [They] did not know it was impossible, so they did it. --Mark Twain Email: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: New branch for $$/Selector rewrite
Hey all! At the risk of sounding like I'm appropriating this thing, I would just like to mention that I intend to tackle most of the To-Do for this (which Andrew knows about) in the coming days. I'll be very glad that people review the code in the meantime and smoke out bugs or potential performance issues, but in order not to get uh-ohs about stuff we *know* about, and in an attempt to avoid duplication of effort, here is the To-Do, in its raw/insider form (it's all about PC = pseudo-classes): [JS = Selector.handlers (JavaScript as opposed to XPath). Pattern = Selector.patterns (regex analysis of the expression) XPath = Selector.xpath (XPath translations, handlers, etc. CHECK = Verify algorithmic correctness. IMPROVE = Add existing ideas for optimizations. TEST = Add tests, run them (I run at minimum on FF2 and Konq3.5)] - PC/JS: IMPROVE by removing concats. Benchmark. Revert if negligible. - PC/JS: TEST unique on multiple calls. FIX expando removal if needed. - PC/JS: IMPROVE attr ~= and |= (strings). Benchmark. Revert if negligible. - PC/XPath: FIX empty. TEST. - PC/XPath: ADD (first|last)-of-type - PC/Pattern: ADD (first|last)-of-type - PC/JS: ADD (first|last)-of-type. TEST. - PC/XPath: ADD not - PC/Pattern: ADD not - PC/JS: CHECK/IMPROVE not. TEST. Until here, I do intend to have it done by Thursday night. I'll commit the further steps of my work right on the SVN branch, so stay tuned. - PC/XPath: ADD nth[-last]-(child|of-type) - PC/Pattern: ADD nth[-last]-(child|of-type) - PC/JS: CHECK/IMPROVE nth-child - PC/JS: ADD nth-[-last]-(child|of-type). TEST. I have very clear ideas on how to tackle this, but I may not have time before the next week-end. Cheers, and hurray for an upcoming kick-ass $$! -- Christophe Porteneuve a.k.a. TDD [They] did not know it was impossible, so they did it. --Mark Twain Email: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Proposed rewrite of $$/Selector
Ken Snyder a écrit : Yes, it was very slow for me too with any of the nth- predicates. That nth routine relies on counting the number of previous siblings FOR EVERY NODE. I'm not sure if that is avoidable, but I've added the Yeah, you're O(n²) on this, and I think I found a way to be O(n) quite simply. I'll let you guys know... first and last element separately is great, but not such a great practice when trying to separate presentation from logic with JS. Plus, you can use :first-of-type and :last-of-type or :first-child and :last-child to achieve identical selection. And :empty seems tricky in XPath too. So Christophe, keep us posted with any XPath magic you have up your sleeve This is it from me for now with $$. As for XPath, I do need to see whether we can achieve something efficient with XPath (building a global AND-based expression, much like the raw-OR version of include, would do nicely I guess). I am concerned with :not requiring a each/include, which is O(n²) as well, thus is very slow. I am thinking of another way to build the resulting set. If worse comes to worst, relying on the raw-OR variant of include *might* help in this case. -- Christophe Porteneuve a.k.a. TDD [They] did not know it was impossible, so they did it. --Mark Twain Email: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Proposed rewrite of $$/Selector
Andrew Dupont a écrit :
On Feb 18, 9:45 pm, Ken Snyder [EMAIL PROTECTED] wrote:
Yes, it was very slow for me too with any of the nth- predicates.
That nth routine relies on counting the number of previous siblings FOR
EVERY NODE. I'm not sure if that is avoidable, but I've added the
corresponding xpath... see below. The xpath syntax may need to be
reworked with previous-sibling or self, I'm not sure. Or this may just
be a wrong path :)
DomQuery sidesteps this by setting an expando nodeIndex property the
first time it iterates through a group of child nodes.
I don't know how well you'll be able to implement a CSS not()
equivalent in XPath. From what I could see, filtering out nodes in
XPath depends on the content of not(). Consider:
CSS3: div:not(#speech1)
XPath: .//[EMAIL PROTECTED]speech1]
CSS3: div.character:not([EMAIL PROTECTED])
XPath: .//div[contains(concat(' ', @class, ' '), ' character ') and
@id!='speech2']
Luckily, not is a function in XPath. It returns the opposite
boolean of whatever it contains:
.//div[not(@id=speech1)]
.//div[not(contains(concat(' ', @class, ' '), ' character ') and
@id='speech2')]
Still a little tricky because of the placement of the brackets. We
might have to remove the brackets from Selector.xpath.* so that we can
insert them properly based on the context of the predicate. Also, I'm
not even sure the second example qualifies as a simple selector the
way the CSS3 spec defines it.
It doesn't. As soon as you find yourself putting an 'and' in there,
you're doomed :-) A simple selector is a SINGLE selector that is NOT a
:not...
--
Christophe Porteneuve a.k.a. TDD
[They] did not know it was impossible, so they did it. --Mark Twain
Email: [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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: Form.Element: select() and focus() return undefined
Thomas Fuchs a écrit : Anyone up for correcting the docs? Just fixed the relevant pages (activate, focus, select). -- Christophe Porteneuve a.k.a. TDD [They] did not know it was impossible, so they did it. --Mark Twain Email: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: DOM builder in Prototype core?
Justin Palmer a écrit : Just casting my vote for the solution Martin proposed. Simple and to the point. Yup, +1. I like the weightlessness of it. We'll have to stress that it plays a lighter game than script.aculo.us' Builder though, so people don't think one replaces the other entirely. -- Christophe Porteneuve a.k.a. TDD [They] did not know it was impossible, so they did it. --Mark Twain Email: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Enumerable#grep: going beyond string representations
Mislav Marohnić a écrit : What is the fallback if match isn't defined on an object? Will there be one? I can't see a reasonable one. The spec will have to make that crystal clear: it's a match method or nothing. Just like Ruby's version mandates a === operator. Execution will end up with a match is not method error I guess. -- Christophe Porteneuve a.k.a. TDD [They] did not know it was impossible, so they did it. --Mark Twain Email: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
