John,
Thanks for your quick reply. I reached the same conclusion, but was
hoping I might have overlooked some functionality of the current
selector engine. I'm looking forward to the release of Sizzle---I'll
play with the development version until then :) Thanks a lot for your
hard work,
Bram
On Oct 31, 10:06 pm, "John Resig" <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
