Bram -
IMO, it might be better to wait a little bit for Sizzle to land - one
of the big reasons that I re-wrote the selector engine was to make it
more extensible (as you're finding out here).
I hope to land something very soon!
--John
On Fri, Oct 31, 2008 at 4:38 PM, Bram Stein <[EMAIL PROTECTED]> wrote:
>
> I have been working on implementing a custom structural pseudo
> selector for selecting table cells in columns and column groups. I
> plan to release this as a stand-alone plugin and also use it as a
> basis for supporting character alignment in table columns. The
> selector syntax would be similar to the following:
>
> // select the cells in the third column
> $('#mytable td:nth-col(3)');
>
> // select the cells in the second header column
> $('#mytable thead th:nth-col(2)');
>
> // select the cells in the first colgroup (which can span multiple
> rows)
> $('#mytable td:nth-colgroup(1)');
>
> I have successfully implemented this as a "normal" jQuery plugin (i.e.
> $('#mytable td').nthCol(2);) with support for column and row spans. I
> however fail to come up with an efficient selector implementation, the
> reason being that the selector needs to iterate the table at least up
> till the point of the indexed column or column group to support row
> and column spans. It is possible to implement this as a simple boolean
> selector/filter but I think it would be highly inefficient.
>
> I've considered the following two approaches two overcome this
> inefficiency:
>
> * pre-calculate the column indexes and store them in the data cache.
> It would be very efficient to calculate the indexes once per table and
> look them up in the selector code, but it would break if the table is
> dynamically modified (since there is no reliable cross-browser way to
> detect changes in the DOM.)
> * override jQuery.filter and add a special case similar to 'nth-
> child()' and 'not()'.
>
> The second approach produces reasonable result, but I feel a bit
> uneasy about making such modifications to core jQuery code. Is there
> some other approach I have missed, or is it better to wait until
> Sizzle has been introduced (which---from my brief look at it---seems
> to give plugin authors more control over their selectors.) To
> reiterate: my main issue is that the current selector engine only
> allows plugin authors to write binary selector predicates, while my
> plugin requires custom code to perform the filtering efficiently. Any
> advice or ideas would be greatly appreciated.
>
> Bram
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
