I took a cue from Sam's "Prototype.BrowserFeatures" object.
I am not against adding to the namespaces, but I want to make sure it's
done judiciously and carefully. Note that typng
"Prototype.Browser.KHTML" is still easier than typing
"navigator.userAgent.test(/KHTML/)". And while I don't think
On Jan 19, 3:42�am, "Mislav Marohni " <[EMAIL PROTECTED]>
wrote:
Also, tell us if this behavior is consistent among browsers
The only browsers to worry about are IE 6 and 7, since other browsers
have the native extensions.
--~--~-~--~~~---~--~~
You received th
I posted about this on Basecamp, but now that we've started to use this
list I'm going to post it here for public consumption.
We've talked about optimizing $$ in the past -- it's one of my personal
goals for 1.5.1. So I took great interest in Jack Slocum's new
DomQuery extension for YUI
(http:/
Function.protototype.bindAsEventListener originally took just one
argument (unlike its cousin bind, which takes an arbitrary number of
arguments and passed all but the first to the bound function). A while
back we changed it to behave the same way as bind. So its parameter
list should be empty,
Opera has always been supported.
On Jan 21, 11:09 am, "Tobie Langel" <[EMAIL PROTECTED]> wrote:
> And BTW is Opera 9 officialy supported by Prototype? If not, couldn't
> that be one of the goals of a future release?
--~--~-~--~~~---~--~~
You received this message
On Feb 6, 3:40 pm, "Martin Ström" <[EMAIL PROTECTED]> wrote:
> What do you other guys think, are you interested in a patch with test
> or would it just be a waste of time? :)
Martin, I like your implementation a lot (especially the
Element.writeAttributes idea, which I think should be added no ma
all means, submit a patch with tests on the already existing
> ticket:http://dev.rubyonrails.org/ticket/7476#comment:1
>
> Doing so will enable easy reviewing and comparing.
>
> -m
>
> On 2/6/07, Andrew Dupont <[EMAIL PROTECTED]> wrote:
>
>
>
> > Martin, I l
#7475 (http://dev.rubyonrails.org/ticket/7475) will fix this once it's
applied.
I admire the hell out of Doug Crockford, but sometimes I want to shove
a JSON string down his throat.
Cheers,
Andrew
On Feb 7, 10:21 pm, Ken Snyder <[EMAIL PROTECTED]> wrote:
> NL wrote:
> > When loading both Protot
If setting the expando to a function, rather than a boolean, prevents
it from persisting when it should not, then that's fantastic. It'd
also solve the similar problem where cloned nodes say they're extended
but are not. Write a patch!
Andrew
On Feb 8, 12:05 pm, "Mislav Marohnić" <[EMAIL PROTE
On Feb 8, 6:26 pm, Alexander Presber <[EMAIL PROTECTED]> wrote:
> Now my question is: What is the advantage of the new Hash
> implementation? Why did Class.create not suffice? I can see added
> complexity but no real gain, since Enumerable is not really in the
> prototype chain of Hash, it
Apologies -- I didn't fully understand this question until I re-read
#3592.
I agree that we need to apply this patch and will raise some hell
forthwith. In the meantime, the issue is specific to Hash, so can't
you do...
Object.extend(Hash.prototype, {
reject: function() { /* ... */ },
findAll:
On Feb 8, 7:59 pm, Alexander Presber <[EMAIL PROTECTED]> wrote:
> > With prototype-based inheritance they all point to
> > the same copy. It's a big win for memory usage. Read this interview
> > with Dean Edwards:http://snook.ca/archives/writing/an_interview_wi/
>
> I see your point. But this i
On Feb 10, 7:10 pm, caillou <[EMAIL PROTECTED]> wrote:
> what would be the easiest way to suggest these corrections?
>
> greets ... caillou
Feel free to post them on this list. Eventually I think we'll enable
users to add (screened) comments to the docs, but that's a Mephisto
thing, so it'll pro
Thanks for the compliments, guys.
Alex Russell's post on the subject (http://blog.dojotoolkit.org/
2007/02/04/dojoquery-a-css-query-engine-for-dojo) has stirred some
diplomatic talks. It looks like Alex, John Resig, Jack Slocum, Dean
Edwards, and I are going to pitch in toward some sort of site
On Feb 15, 4:14 pm, Thomas Fuchs <[EMAIL PROTECTED]> wrote:
> Andrew, this is just incredible. Keep it going. :)
Thanks!
I've finally submitted this as patch #7568 (http://dev.rubyonrails.org/
ticket/7568) and have updated the test page at (http://
andrewdupont.net/test/double-dollar/). There a
Oh, one more thing I forgot to mention...
I'd still like to make optimizations for three common kinds of
selectors:
* A single tag name ("li")
* A single class name (".external")
* Any selector with an ID in it ("div #sidebar")
The first two are important, in my opinion, because they'll get used
On Feb 16, 8:43 am, Christophe Porteneuve <[EMAIL PROTECTED]> wrote:
> This is great, but you would need to provide unit tests for the extra
> features...
Yeah, working on that. I posted the patch in the airport in Tel Aviv
right before boarding a plane, and unit tests slipped my mind at the
tim
On Feb 16, 11:57 am, Ken Snyder <[EMAIL PROTECTED]> wrote:
> Andrew Dupont wrote:
>
> Do you have a list of pseudo-elements you want to support?
The list you posted is more or less my list, in terms of priority.
> Do we want to address pseudo-elements that normally refer
Disregard -- you *do* have your terms right. I should read the spec
before I say these things!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype
AIL PROTECTED]> wrote:
> Andrew Dupont wrote:
> >> Do we want to address pseudo-elements that normally refer to text nodes
> >> or fragments such as :first-letter, :first-line, and ::selection?
>
> > I'd rather walk barefoot across a barbecue.
>
> Oh come
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 t
On Feb 18, 2:01 pm, Marius Feraru <[EMAIL PROTECTED]> wrote:
> Exactly. I'm on your side and I guess many more are using their own
> Prototype tweaks. Just keep your development bench up-to-date (synchronized
> with the current trunk [1]), update your tweaks and, whenever you think you
> found som
On Feb 18, 3:05 pm, "Martin Ellis" <[EMAIL PROTECTED]> wrote:
> Why cant prototype have elegant code and optimised code. I'm not
> talking about milliseconds of optimisation, even i am not that
> machocistic.
>
> But when a function gets so much use like setStyle, should
> asthetically pleasing co
On Feb 18, 3:29 pm, "Mislav Marohnić" <[EMAIL PROTECTED]>
wrote:
> Unfortunately, this is where JavaScript 2 is going right now. And it's
> already too late to change anything.
It's really not as bleak as all that. Most of what JS2 borrows from
Java is syntax. And if you don't care for type annot
On Feb 18, 6:50 pm, "Martin Ellis" <[EMAIL PROTECTED]> wrote:
> Anyway we're straying massivly from the topic. The point goes back to
> the setStyle being a resource hog.
>
> How can this be improved as with the heavy dependance of it in
> script.aculo.us it is in desperate need of reworking.
I j
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...
Gentlemen, based on your progress I've managed to implement some more
stuff. I've updated patch #7568.
Supported are nearly all of the argumentless pseudoclasses, which I
consolidated into one regex. (Also implemented the general sibling
combinator: "div ~ p".) I haven't done exhaustive testing
On Feb 19, 2:01 am, Christophe Porteneuve <[EMAIL PROTECTED]> wrote:
> I'll resume my own work based on this new source. I see you used just
> about all the feedback I had done on it, except for the NS attributes
> detection. How come?
I think that was an oversight. I'll correct that.
> Oh,
I'm not sold on this. I certainly see how it would be useful, given
the "falsy" nature of 0 and false and all that, but:
* There isn't a compelling enough use case *outside the framework*
that would warrant putting this function in the dollar namespace. And
without a short name it wouldn't save
If you bleeding-edgers do an SVN update you'll notice that there's a
new selectors branch. The version of selector.js contained therein is
another major advancement from the previous version (attached to patch
#7658). Christophe's excellent code reviews and revisions have been
indispensible; now
On Feb 20, 4:10 am, "Dan Webb" <[EMAIL PROTECTED]> wrote:
> The thing is is that there's loads of cross browser problems with
> setting attributes (as mentioned previously) and working around at
> least the common problems with a tool like this is essential otherwise
> your just going to end up
On Feb 21, 3:47 am, Thomas Fuchs <[EMAIL PROTECTED]> wrote:
> Do you guys need benchmarking results? If yes, in what form? :)
I modified the benchmark page (which was originally jQuery's) to
output the results to CSV in a TEXTAREA below the table. I just now
realized I didn't update the page onl
On Feb 21, 1:31 pm, "jd" <[EMAIL PROTECTED]> wrote:
> Right,
>
> Ya I would say server solutions are best, but you can always combine
> them. Anways its just a little somethin. I figured having proper semi
> colons n what is prolly worth the dload 8). Its always nice to have
> options.
Agreed.
On Feb 21, 4:26 pm, "Martin Ellis" <[EMAIL PROTECTED]> wrote:
> Instead of sadistically adding semi colons and other needed things to
> make it small, run it through rhino and it can spit out good looking
> code.
Rhino can do this? Can you tell us how?
--~--~-~--~~~
On Feb 23, 4:37 pm, "Colin Mollenhour" <[EMAIL PROTECTED]> wrote:
> Man this is getting annoying.. I wish json.org would change their code
> or Prototype would use $H().each in setRequestHeaders or both
> (preferable) would happen soon. This is popping up on Rails Spinoffs
> at least twice a day i
You're still treating Request.responseText as if it were JSON, even
though you're no longer converting it to JSON. The solution is not to
remove the JSON conversion -- it's to find a JSON library that doesn't
muck with Object.prototype. (I seem to recall there's an older version
of Crockford's li
The commits I made yesterday are inching us ever closer toward a code-
complete implementation of *all* of CSS3. Thanks to everyone who
helped out, especially Christophe.
I'm more than satisfied with the performance, but I won't feel
confident enough to mark this as "ready" until we've got some
#4 looks fine to me.
On #1 and #2: perhaps the answer is...
{ foo: undefined } => "foo="
{ foo: null } => ""
I don't know if this is useful or not, but it would allow you to
distinguish between these two cases, since null and undefined are
distinct values with different meanings.
I have no opi
On Mar 8, 3:43 pm, "Rick Olson" <[EMAIL PROTECTED]> wrote:
> How are you planning to do date serialization for json? I did some
> work in Rails and noticed it used "Thu Mar 08 15:41:36 CST 2007",
> which is no good. I wrote a json plugin for rails that uses the fjson
> gem to parse incoming js
On Mar 8, 4:00 pm, "Rick Olson" <[EMAIL PROTECTED]> wrote:
> Madness. I'll add it myself then. I can't see why you'd pass
> xmlschema dates around and want to treat them like strings.
You wouldn't, but all other data types can be parsed by a simple eval
call. (Obviously you'd want to sanitize,
On Mar 15, 9:39 am, "Tobie Langel" <[EMAIL PROTECTED]> wrote:
> I'd favor writeAttribute to be consistant with readAttribute... and
> setStyle (which is not pluralized).
>
The issue here is that each attribute is a separate unit, whereas you
could argue that each of the properties you pass to s
You act as if the web isn't built upon conventions, even arbitrary
ones.
I think this is a POLS issue, only we disagree on which behavior is
least surprising. But since Prototype is designed to go hand-in-hand
with Rails, and since JavaScript methods can be redefined at runtime,
I think the empt
inions on this issue? I don't want this to be
decided only by the handful of people who've posted in this thread.
Cheers,
Andrew
On Mar 15, 6:30 pm, Marius Feraru <[EMAIL PROTECTED]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Andrew Dupont wrote:
&g
This was an oversight on my part: I assumed that there were more
constraints on the "an+b" syntax than there actually were. Reading
over the spec once again I see this...
"The :nth-child(an+b) pseudo-class notation represents an element that
has an+b-1 siblings before it in the document tree, fo
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/
#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 -
On Mar 17, 2:57 am, Christophe Porteneuve <[EMAIL PROTECTED]> wrote:
> OK, start by using the latest version, OK?
D'oh! Google has failed me!
Both questions answered.
On Mar 17, 3:31 am, Trevan Richins <[EMAIL PROTECTED]> wrote:
> (position-b)/a >= n (only if (position-b)/a is an integer - no
This is what I came up with for the XPath version: http://pastie.caboo.se/47671
It's a direct port of the logic of parseNth (albeit not yet tested).
I'll look at yours and see if it makes more sense, though.
Cheers,
Andrew
On Mar 17, 4:51 pm, Trevan Richins <[EMAIL PROTECTED]>
That's an interesting idea.
Parts of CSS3 parser could be reused. You could certainly use the
regexen we define to identify various CSS tokens.
My first thought was that combinators should not be allowed in that
syntax (i.e. new Element('div#mynode div.someClass'), but then I
suppose you could u
It's a native part of JavaScript.
Cheers,
Andrew
On Mar 21, 4:04 pm, "jdalton" <[EMAIL PROTECTED]> wrote:
> I noticed that in the String.prototype.evalJSON you create a new
> instance of SyntaxError.
> I don't see this object in the code.
> I may be showing some ignorance to error detection and
After a whole bunch of heated discussion about a subject that I had no
idea was so controversial, my inclination is to stick to a very spec-
compliant and unambitious Hash serializer for 1.5.1.
Those who need more out of their serialization (proper handling of
nested hashes, arrays, etc.) can wri
Add-on. We're already pushing 100K as it is.
Cheers,
Andrew
On Mar 28, 1:05 pm, "Mislav Marohnić" <[EMAIL PROTECTED]>
wrote:
> On 3/28/07, Stefan Liebenberg <[EMAIL PROTECTED]> wrote:
>
>
>
> > Does anybody know how to send a serialized upload file value thing to
> > your server I tried and
Element#getElementsBySelector lets you specify a context node other
than the document. (http://prototypejs.org/api/element/methods/
getElementsBySelector)
I can only speak for myself, but the reason I haven't felt the need to
add any documentation on the Selector class itself is because I can't
t
On Mar 30, 8:32 pm, "Jacob Rockowitz" <[EMAIL PROTECTED]> wrote:
> Maybe http://www.prototypejs.org/api/utility/dollar-dollar should have a
> reference to 'Elements.getElementsBySelector'.
Good idea. I've updated the $$ page to point to
Element#getElementsBySelector and did a little tidying up
I don't know much about the code in question, but I believe those
catch blocks are in place to intercept thrown exceptions that are
extraneous (i.e., can occur sporadically without changing the result
of the code or have no bearing on the result). I can't be sure,
though, so let's take them one b
I like the idea of Function.prototype.curry. It goes hand-in-hand
with Enumerable and is useful for stuff like argument rearranging.
I feel like Function.prototype.rcurry is an edge case, but I might be
in the minority there.
While we're on the subject, I proposed Function.prototype.defer in
Ca
On Apr 10, 11:50 am, Christophe Porteneuve <[EMAIL PROTECTED]> wrote:
> Nice, but that doesn't explicit the fact that these are just the *first*
> arguments: you can add more when calling the resulting function.
I don't see how this is different from call, apply, or bind. The
differences between
I've submitted a patch to add Function#curry, #compose, and #defer.
(http://dev.rubyonrails.org/ticket/8134)
Cheers,
Andrew
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this g
The win32ole module is part of stdlib, so no external dependencies
needed.
*Fantastic* work, dude. I can't wait to try it out.
Cheers,
Andrew
On Apr 26, 5:06 pm, Ryan Schuft <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I've submitted a ticket with an attached patch to fix the problem on
> Windows
http://www.andrewdupont.net/2006/05/18/javascript-associative-arrays-considered-harmful/
On Apr 26, 5:27 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> Sort of new to prototype, but it seems that when I have a associative
> array, and do the following:
>
> for(var j in myAssocArray){
>
Dan Webb wrote:
> > It's not a bad cause, I just think the solution is a performance eater.
> > Imagine: the loop runs on every object instantiation. It wraps every
> > function inside another and it needs $A for that. After that, every function
> > call internally calls another, triggering $A on
> Would it? ;)
>
> The new Event code binds whatever it gets in IE to someElement. It doesn't
> know anything about Foo.
I wasn't being very clear -- sorry. Those first two examples
illustrate what would happen if we implemented *both* the stuff in the
events branch as it is now *and* Dan's prop
On May 23, 7:16 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> With the latest prototype (1.5.1), the next() function (and probably
> also prev() and the rest of the navigation function) cause a
> tremendous slowdown in IE if they are used with the following syntax:
> next(Number). From what
On May 24, 5:53 am, "Mislav Marohnić" <[EMAIL PROTECTED]>
wrote:
> Andrew, it doesn't matter - getElementsByClassName tends to extend EVERY
> node in the document! If that isn't slow I don't know what is.
No, it doesn't. It extends only those nodes that match the class
name. I've personally spen
On May 25, 3:10 am, "Mislav Marohnić" <[EMAIL PROTECTED]>
wrote:
> It calls Element.hasClassName for every node, I hope we can agree on that.
> Now, let us remember what do methods from the Element namespace all have in
> common.
>
> Hint: it has something to do with the first argument and the $ f
On Jun 3, 9:06 am, "Mislav Marohnić" <[EMAIL PROTECTED]>
wrote:
> That doesn't make any sense. "element.form.serialize" should work in
> FF andOpera because they support native DOM prototypes. It
> shouldn't work in IE because the form element is not DOM extended by
> Prototype. And now you're te
We'd almost have to call them "viewportHeight" and
"viewportWidth" (perhaps prepended with "get"), since we already have
"viewportOffset." But I don't know where we'd put them -- they don't
work as Element methods.
I'd suggest "window" if it weren't the global namespace. Thoughts?
Cheers,
Andrew
On Jun 6, 10:56 pm, Tobie Langel <[EMAIL PROTECTED]> wrote:
> and what about making them properties of navigator ?
Perhaps, but "navigator" contains metadata about the browser itself. I
though about attaching them to "document," but I think that's
counterintuitive (viewport dimensions, not docume
On Jun 17, 8:34 am, "Mislav Marohnić" <[EMAIL PROTECTED]>
wrote:
> Am I right when saying that this will fail if the ID was dynamically set (in
> other words, it was not an attribute in HTML source)?
Adam's test is correct -- even dynamically-set ID attributes will
still be picked up by readAttr
On Jun 18, 2:01 am, "Mislav Marohnić" <[EMAIL PROTECTED]>
wrote:
>There are only 3 possible options we're facing:
>
>1. Don't change the $ function, leave everything as-is;
>2. Fix the issue in $ by using $$('*[id=foo]');
>3. Don't fix the issue, throw error instead.
My vote is for #
On Jun 21, 6:30 am, Rebecca Blyth <[EMAIL PROTECTED]> wrote:
> Finally, an aside on not having control over the HTML source:
> I ran into this issue when using the radio_button_tag helper method in
> Rails, which inconveniently used the name of the input as the id -
> unhelpful, as all the radio
On Jun 21, 2:35 pm, sed <[EMAIL PROTECTED]> wrote:
> I'm not sure why this worked before, it must be related to the html/
> script being generated into the div from the ajax.updater rather than
> just being on the page.
Nope. It's sillier than that. Let's say you've got an element with an
ID of
We've been working on a more robust class-based inheritance model,
fashioned after Dean Edwards's Base and others like it. There's an
inheritance branch in the SVN repository that shows our latest
efforts.
We've had some lively internal discussions about syntax. I figured I'd
hold my finger to th
It's got nothing to do with luck. Arrays are implemented as a very
light veneer on top of Objects; the only real difference between them
is the literal syntax ([]) and the magic "length" property that counts
your numeric keys. (In fact, the numeric keys aren't really numbers,
since all object prop
On Jun 24, 7:48 pm, Tobie Langel <[EMAIL PROTECTED]> wrote:
> I personally prefer the following syntax:
>
> var Animal = new Class({
> ...
>
> });
>
> var Cat = new Class(Animal, {
> ...
>
> });
I abhor this syntax. I wish I could put it any more mildly.
In languages with class-based inherit
On Jun 25, 4:41 am, "Gareth Evans" <[EMAIL PROTECTED]> wrote:
> Is Base an option for the naming of the parent class?
I'd vote against it assiduously. It was my problem with Dean's
original naming as well. In a deep class structure (Organism > Animal
> Cat) it implies that the method being call
I agree with everything Mislav said and would adopt that syntax in a
heartbeat.
My only concern is with the signature of Class.create and
Class.extend. I feel like having instance methods and class methods in
adjacent arguments can hurt the readability of the code. If you're
skimming a file you m
On Jun 25, 11:29 am, Ken Snyder <[EMAIL PROTECTED]> wrote:
> I'd also like to throw in the idea that we need to prove the final
> OO-design decisions with use cases. We can write animal-sounds code all
> day long, but JavaScript is such a unique language, I think we ought to
> prove the design
> for(element in elements) {
That's the problem. Use elements#each [1] or a for loop with an index
to iterate through arrays. You can read more about this issue here
[2].
Cheers,
Andrew
[1] http://prototypejs.org/api/enumerable/each
[2]
http://andrewdupont.net/2006/05/18/javascript-associative
On Jul 4, 1:52 pm, Vincent <[EMAIL PROTECTED]> wrote:
> I agree on the multiple declaration syntax, but in the cases above,
> those variables have already been declared earlier in the code and are
> simply assigned new values in the reported lines.
Yeah, it's a mistake, but it's an innocuous one
Have you tried "*[id='myForm:myName']"? That ought to work, though it
wouldn't surprise me if it did not.
A colon is a valid character in ID attributes, so it should be
supported. Part of me thinks that the attribute selector approach (if
it works) would be sufficient -- but another part of me th
This will nonetheless be fixed in Prototype 1.6 -- Event.observe will
automatically "fix" scope.
Cheers,
Andrew
On Jul 13, 12:42 am, Paladin <[EMAIL PROTECTED]> wrote:
> Thanks. Sometimes when bugs pop out it's really difficult to tell
> where they come from.=)
>
> On Jul 12, 4:46 pm, jdalton <[
Are you in strict XML mode (XHTML served as application/xhtml+xml)?
That's the first thing that popped into my head; it may or may not be
relevant.
Andrew
On Jul 24, 12:26 pm, Michael Peters <[EMAIL PROTECTED]> wrote:
> I'm just trying a simple use of $$()
>
> $$('#top_nav a.dropdownmenu);
>
>
To clarify: I'm not suggesting that XML mode is a *bug* (at least not
in a diplomatic setting) -- if this were the source of the error, the
bug would be Prototype's -- just that we do no formal testing for XML
mode, so I wouldn't be surprised if this were the cause.
On Jul 24, 1
Wherever it makes sense, Prototype follows Ruby's general philosophy,
and that includes naming scheme. If the most confusing result is that
someone expects "unique" instead of "uniq," that's a gambit I'm
willing to make. A developer would immediately know what "uniq" means
upon reading documentati
No - that'd be incorrect in both cases. Semicolons are needed when a
line is ended with the closing brace of a function literal or object
literal, but not when a line is ended with the closing brace of a
control structure.
Cheers,
Andrew
On Aug 7, 1:09 pm, "Mislav Marohnić" <[EMAIL PROTECTED]>
w
This is probably the most glaring flaw in RC0: any event types that
are not part of the DOM L2 Events spec, but are nonetheless honored by
one or more browsers, are handled incorrectly by Prototype as custom
events.
We've got to figure out a way around this, even if it means we create
a whitelist
On Aug 31, 2:12 am, "Mislav Marohnić" <[EMAIL PROTECTED]>
wrote:
> On 8/31/07, Jeff Watkins <[EMAIL PROTECTED]> wrote:
> Let me see if I'm getting this correctly. You are saying that you need to
> inject content in the DOM received by XHR ... while the current page is
> still being loaded? That
On Sep 1, 5:18 pm, "Nicolás Sanguinetti" <[EMAIL PROTECTED]> wrote:
> Anyway, the custom event solution seems tidy enough. What do the w3c
> specs say on xmlhttprequests and contentloaded, if anything?
They don't. Despite its name, the "DOMContentLoaded" event is not part
of any standard.
--~--
That very blog post points to HTML5 work on the issue. If you're
brave, Mislav, you could ask for a spec clarification on the HTML5
mailing list.
Cheers,
Andrew
On Sep 5, 10:20 am, "Mislav Marohnić" <[EMAIL PROTECTED]>
wrote:
> On 9/5/07, jdalton <[EMAIL PROTECTED]> wrote:
>
>
>
> > I just saw a
The CSS2 and CSS3 specs disagree on this, annoyingly enough. [1] I'd
originally written ":not" to throw an exception on selectors with more
than one token, but then I saw the conflicting definitions and
relented. All the other major libraries seem to allow this confusing
syntax.
Not being able to
The "size" method comes from Enumerable#size. Array and Hash both have
it because they both mixin Enumerable, of course. It's a type-agnostic
way to get the number of items in a collection, since not all
collections have a "length" property.
This isn't the case for strings. Strings always have a
Gah. That's not good.
We need to follow the same pattern used in all the Element instance
methods: start by extending the event, just in case it isn't extended
yet. That way, calls to generics are guaranteed to be safe.
I'll fix this over the weekend if nobody else gets to it first.
Cheers,
And
Historically the JS libraries haven't seen enough patch volume to
justify the process overhead. I feel like we're turning the corner
there, though; we should probably start following the "Report 12"
process for Prototype. What does the rest of Core think?
Any message that proposes a new feature i
I'm not crazy about it. Deviations from the CSS3 spec are troublesome
because they're not discoverable and they violate POLS. If we're going
to go down that slippery slope, selector.js will get even larger than
it already has.
The extended Enumerable#grep semantics in 1.6 make kangax's
alternativ
Prototype & script.aculo.us don't release "official" compressed
versions, but there are a few different people who make unofficial
compressed versions for each major release. I'm sure one will be
available shortly after the 1.6 final release (which will be soon).
Cheers,
Andrew
On Nov 1, 8:25 pm
There are other popular scripts that rely on this behavior, most
notably Dean Edwards's original base.js inheritance script.
It should also be noted that this behavior does not comply with
ECMA-262, which states that Function.prototype.toString shall return a
string that has the syntax of a funct
Great work, Nick. I'll take a look at this patch when I get a chance.
Cheers,
Andrew
On Nov 13, 3:01 pm, Nick Stakenburg <[EMAIL PROTECTED]> wrote:
> I'm hoping document.viewport.getDimensions() can be improved.
> At the moment I'm using a patched version in href='http://www.nickstakenburg.com/
On Nov 22, 10:29 am, "Mislav Marohnić" <[EMAIL PROTECTED]>
wrote:
> Because of the silence of other core members at the moment,
Keep in mind the western faction has been asleep, and it is a holiday
in America. ;-)
> it would be best
> for you to make a plug-in script that is included after Pr
On Nov 22, 6:21 pm, "Mislav Marohnić" <[EMAIL PROTECTED]>
wrote:
> While maybe not a good fit for core (most of the users wouldn't use it),
> those seem definitely useful. I'll hope you'll still share them somehow
> (public dir in your svn repo is an option).
I'd like to emphasize this. Despite
The Selector class translates to XPath in browsers that support it.
Some of the Selector unit tests failed in Safari 3 -- seemingly because
WebKit doesn't correctly implement some XPath functions. If I recall,
the failures are related to the ":first-of-type/:first-child"
pseudoclasses (and their b
1 - 100 of 165 matches
Mail list logo
