jQuery Forum

Currently every other option that sets a selected tab has higher
priority:
// Try to retrieve selected tab:
// 1. from fragment identifier in url if present
// 2. from cookie
// 3. from selected class attribute on <li>
// 4. otherwise use given "selected" option
// 5. check if tab is disabled
That never came up as an issue but now as you mentioned it it seems to
me that the selected option should have highest priority indeed, it
just seems to be expected behavior.
--Klaus
snobo

yeah, because currently, if I need to explicitly set the selected tab,
I'm forced to omit the .cookie option which I normally specify. And
this actually triggers an inconsistency in my application behavior,
because in this particular case the last selected tab will not be
remembered anymore!

...fixed in http://dev.jquery.com/changeset/5545
--Klaus

thanks! But... still a problem... try to explain...
normally, when I don't enforce a tab via .selected, the current state
is saved in a cookie named "ui-tabs13" (why so? what's the naming
algorithm?). Now, when I specify the .selected (but .cookie option is
still set, because I still want the tab position to be remembered!),
it works correctly. But... now when the user starts to change tabs,
the state now is being saved in a cookie WITH A DIFFERENT NAME - "ui-
tabs15"! So when the user refreshes the screen, it's not taken into
consideration (the state saved in the original cookie ui-tabs13 is
taken instead).
If I specify another .selected tab, the cookie might change its name
again - say, "ui-tabs36"... And so on...
Why is it so? Is it normal? How to achieve the consistency?

On May 10, 11:39 am, snobo <g...@riga.ahlers.com>