Ok. To be honest a large number of these ideas I've actually suggested before on the list, and those times I got a lot of comments suggesting it wasn't something that would be accepted, or suggesting some cheap flawed workaround as the fix instead. I guess I'll just have to discard all those old comments and ignore any comments on "You could do this X way instead." and open up tickets for review on patches.
I'm half finished that borderRadius code. It has a piece of code common with ticket#4295 (the margin/padding combined css bug I reported). I think I'm going to go ahead and recommend .rawCss over use of the closure and use .rawCss inside of the code for making .css extensible. When that's done I'll separate borderRadius from css extensible and post a ticket and a patch for making .css extensible. As well I'll post a patch for the code that makes it possible to create a function instead of jQuery(...); which will accept ( [context], selector, selector, ... ); that is completely backwards compatible and merely adds some harmless extra features which shouldn't affect performance. What about that json support you have on the roadmap? I'm willing to code that up and give you a patch if you tell me what you want it to do. I already have a .jsonParse method which would try to make use of FF3.1's native JSON.parse, json2.js' parse, json_parse.js' parse (same for the state machine version), json_sans_eval.js' parse, and if nothing else works falls back to eval. However I don't know if you want that, something that requires directly registering a json library, or some json parsing code injected directly into the library. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://nadir-seen-fire.com] -Nadir-Point & Wiki-Tools (http://nadir-point.com) (http://wiki-tools.com) -MonkeyScript (http://monkeyscript.org) -Animepedia (http://anime.wikia.com) -Narutopedia (http://naruto.wikia.com) -Soul Eater Wiki (http://souleater.wikia.com) John Resig wrote: > There's really no need to branch out a whole project like this. If you > have a patch to add some extensibility (make it easier to handle > oddball CSS properties, for example) I'd definitely imagine that > something like that would be accepted, no problem. Just make a patch, > file a ticket, then post it here so that we can review it. > > --John > > > > On Thu, Mar 5, 2009 at 5:33 AM, Daniel Friesen > <[email protected]> wrote: > >> I've been thinking about my 4query offsite branch and the merits of >> something more tied to jQuery. >> A project more involved with jQuery definitely has the advantage of >> being much easier to keep compatibility and avoid the code differing to >> much. >> >> jQuery has strong policies on things being compatible with all browsers, >> and a number of other things wouldn't fit in jQuery itself right away. >> What about something like a jQuery Labs project. The project could work >> on experimental, and preemptive features. Things like HTML5 stuff, >> partially standardized / implemented features, making a lot more >> internals transparently extensible, modularizing the code and supporting >> a jQuery.ui like system for bundling jQuery, and various other ideas >> people could suggest which could be worked on. >> >> I actually have half the code for a module that adds borderRadius css >> support (All the css.get code, working on the css.set). It adds a >> interface that follows the w3 draft, works in Gekko and Safari, and >> gracefully falls back in other browsers. It's also future compatible so >> if you're using .css({borderRadius: 10}); now it'll still work in a few >> years when browsers fix up their implementation of the spec (FF doesn't >> support irregulars, Webkit doesn't let you get borderRadius on it's own; >> and neither of them understand the "horiz / vert" syntax in the spec now >> that the ambiguity has been resolved) and implement real borderRadius >> support rather than vendor extensions. >> Originally I was going to directly support it in the library, but after >> working for awhile making it fully compatible the code is about 2-3x the >> size of the code for opacity via filter support. So instead I setup a >> fairly nice method of making it possible for plugins to implement this >> kind of extra compatibility where desired. >> Things like borderRadius would probably become part of an optional >> compatibility module which the bundler would let you pick if included or >> not. >> >> -- >> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://nadir-seen-fire.com] >> -Nadir-Point & Wiki-Tools (http://nadir-point.com) (http://wiki-tools.com) >> -MonkeyScript (http://monkeyscript.org) >> -Animepedia (http://anime.wikia.com) >> -Narutopedia (http://naruto.wikia.com) >> -Soul Eater Wiki (http://souleater.wikia.com) >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
