Step 1: Comment jQuery code with some standard scheme describing each
section of code as a workaround for browser X version Y.Step 2: Create a
parsing script that 'compiles' the different browser versions.
Step 3: Design a foolproof method to get the right script loaded in the
right browsers.
You are now at step 3, and while this is a very interesting discussion, the
first step is a very big and essential job for the jQuery team.
When you decide this optimization is worth it you should start working on
step 1 for the next mayor jQuery release.
Steps 2 and 3 can be perfected separately, and the different browser
versions will probably be ready in a day after the code with proper comments
is available. ;)
As I understand it you might need some help with step one, so what mechanism
would best suit our need to let the community help re-comment jQuery?
It might be a little far out but isn't it an option to let a semi-automated
script leave out different pieces of uncommented code and test in various
browsers with the new testswarm. Kind of like reverse-feature-detection! :)
Regards,
THD
On Wed, Sep 2, 2009 at 10:39 AM, DBJDBJ <dbj...@gmail.com> wrote:
>
>
> Are we (or am I ) solving/discussing a non existend problem? I think
> no and I think there actually is a problem. Not very big, and not a
> "show stopper", but a visible one. Which makes this issues (or
> problem) worth solving.
>
> jQuery (as it is ) code is i sprinkeld with IE related comments. I do
> not need any hard data, to convince myself (and others who agree) that
> something has to be done to rectify the situation where core library
> has active/runtime workarounds arround IE issues. I am extrapolating
> (not just mine) concepts, knowledge and experience from other
> programing developments, into the realm of browser hosted javascript
> environment. I do not need any kind of tests to be convinced that
> having different jQ for IE and other browsers is a good thing. And
> that it must bring measurable benefits, in terms of speed and
> stability, of future jQuery releases (if adopted).
>
> There are people here who agree and even want to extend this idea into
> having different jQ for each of the browsers that matter. Someone even
> suggested PHP based solution which will make (compose) jQ "on-
> fly" (aka dynamicaly) by looking into the HTTP client descriptors. Or
> one can imagine a solution using server-side-includes :
>
> <!-- jquery_composer example running on Apache -->
> <!--#if expr="${Mac} && ${InternetExplorer}" -->
> IE on OS-X solution
> <!--#else -->
> Every other solution code goes here
> <!--#endif -->
>
> I think, have suggested much less dramatic, solution vs. above ;o)
>
> I would gladly do the jQery code changes (and spliting into two),
> myself, but I am not sure I am capable of matching each IE related
> comment in jQ to actual code, even less capable of understanding few
> uncommented IE workarounds.
>
> --DBJ
>
> On Sep 1, 5:20 pm, David Zhou <da...@nodnod.net> wrote:
> > On Tue, Sep 1, 2009 at 11:45 AM, DBJDBJ<dbj...@gmail.com> wrote:
> >
> > > @dz No offence, but why are you taking part in this "pointless
> > > discussion" ?
> >
> > Because if there *is* a significant speed increase, it's valid and
> > therefore interesting. There's a lot of sound and fury, but not a lot
> > of data.
> >
> > > I am really puzzled on what arises a certain ammount of confusion
> > > here? JScript conditional comments, IE html conditional comments, etc
> > > are nothing new. People have been using them for years. And the whole
> > > "conditional compilation" concept is decades old.
> >
> > People have been using them for years -- but not blindly. jQuery just
> > recently made a move towards feature detection rather than browser
> > detection. Separating out non-IE code is a step backwards towards
> > browser detection. If that step is to be taken, you need to show
> > measurable gains beyond screams of "it's better!" and beyond generic
> > appeals to tradition and authority.
> >
> > This isn't cargo cult mysticism. If there are gains, create some test
> > cases and show them.
> >
> > > (one very relevant and recent example :
> http://dean.edwards.name/weblog/2008/01/ie7-2/)
> >
> > How in the world is that relevant? His javascript does not use:
> >
> > 1. Jscript conditionals
> > 2. conditional compilation
> >
> > His front-end code uses HTML conditional comments, but that's a
> > completely tangential issue, and has no parallel to what is being
> > discussed in this thread.
> >
> > > One good example of a measurable benefit. Not in speed but in
> > > stability would be jQ UI. They would benefit even more from separating
> > > IE vs NON-IE code. The amount of greef (it seems to me) they are
> > > getting because of IE, is v.large. Most of the discussions in jQ UI
> > > forum are formed arround IE 6,7,8 issues ...
> >
> > Then take it to the jQuery UI forum. You do realize you're on the
> > jQuery mailing list?
> >
> > Although, I'd wager a fairly large sum of money that after all the
> > work in separating it out, you'll not help those people with IE6/7/8
> > issues one bit. Most, if not all, of the issues are not because the
> > IE branches are together with non-IE branches.
> >
> > > Ah, yes, and yet another no-brainer is CSS. CSS comunity has solved
> > > (is solving) many difficult issues by separating IE vs NON-IE CSS ,
> > > mostly through conditional HTML inclusion. I think this is very
> > > measurable benefit in the context of web apps stability. I do not know
> > > what was before, but it seems no one "over there" is confused with the
> > > beenefits of using
> >
> > You're conflating problem domains. It muddles your point and confuses
> > the hell out of everyone.
> >
> > HTML conditional comments were used because it was the *only* way to
> > properly ascertain browser version without resorting to CSS hacks,
> > which could change with each new browser.
> >
> > This isn't analogous to the code branching inside jQuery, especially
> > after it switched to feature detection.
> >
> > > Lastly. Of course tests need to be done. What makes you think I do not
> > > think so? But please understand the conceptual advancement here which
> > > is not going to be measurable just in the terms of raw-speed.
> >
> > Then stop saying, and I quote, "This kind of delivery, would show
> > measurable benefits (in spead increase and stability)."
> >
> > -- dz
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
