@ludovicFeature detection is often preferable, but not always possible. For
example opacity can be detected to not exist, but when you use the
'filter:alpha' instead you already assume you're on IE so it's not really
detection then. :)
Another detection that might be removed for a lot of known browsers is the
boxmodel, it is detected after the DOM is ready by adding an element to it
and checking the dimensions. This must cost an extra msec or so for each
load of the jQuery library... while we know that certain browsers don't need
this check at all.
You could support both tags to allow different usage scenarios, the tag
@browser documents browser support, and @support documents a required
feature.
In the example we could put the '@browser IE' tag at the 'compatible'
version, and the '@support inarray' before the 'correct' version. This way
you document both what is required for correct operation and known browsers
that require the workaround. When anyone generates jQuery versions for
purpose X they can decide if browser is known or detection is needed.
These comments should do only one thing: *document *what is going on in the
code block it surrounds, and especially the quirky stuff not needed by all
browsers. This is useful for the developer, and for a parser that needs to
know more about the code. They are not real conditional comments, although a
jQuery version could also be generated that does support it. I avoided a
term like 'if' and 'else' to create this distinction...
THD
On Thu, Sep 3, 2009 at 1:42 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> Sorry guys, a little OT for jQuery developers:
> guys did you get the fact jQuery.inArray could be easily optimized? The
> code I posted does not exist in the latest jQuery core.js file, you are
> using the loop version for every browser - it's a quick improvement, I would
> go for it :D
>
>
> On Thu, Sep 3, 2009 at 12:20 PM, ludovic <ludothebe...@gmail.com> wrote:
>
>>
>> @THD
>> I agree with the principle of creating your own precompilation syntax,
>> but not to have a regression, it would be preferrable to use features
>> detection.
>>
>>
>> inArray = function( elem, array ) {
>>
>> /* @if support indexOf
>> * Creates correct inArray function when browser does not support
>> native
>> array.indexOf
>> * Use === because on IE, window == document
>> */
>> for ( var i = 0, length = array.length; i < length; i++ )
>> if ( array[ i ] === elem )
>> return i;
>> return -1;
>> /* @else */
>> return array.indexOf(elem);
>> /* @ */
>> }
>>
>> And create a database of correspondances between features support and
>> browsers. Then, when you want to create your IE file, you search in
>> your correspondances what features are known to be supported by the IE
>> version, and then, excecute precomputation tests by replacing features
>> detection by the value.
>>
>> It would cost much less work to make the migration of jquery as
>> features detection are already managed.
>>
>> Regards,
>> Ludovic
>>
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
