Opened 8 years ago

Closed 7 years ago

#7715 closed enhancement (wontfix)

Option to specify the tab list selector

Reported by: Skaffen Owned by: Skaffen
Priority: minor Milestone: 1.9.0
Component: ui.tabs Version: 1.8.16
Keywords: Cc:
Blocked by: Blocking:

Description

In #4877 there was a request to allow specification of the selector for the list instead of the hardcoded "ol, ul". The reason was because it was using .children instead of .find and the requester wanted to use nested markup. Unfortunately this does have a side effect on a use case involving the third party UI.Layout plugin whereby it's desirable to have a nested UL ahead of the UL that's to be used as the tab list, so it would be more useful to be able to specify the selector!

To give some background - in the UI.Layout plugin it is possible to have the tab widget be a pane and have just the tab content scrolled - UI.Layout has special support for that by flagging that the "tab" part is header and the "panes" part is content. It is also possible to add additional header and footer sections into a pane, which for this simple case would go inside the tab container element at the same level as the tabs.

Unfortunately with the selector for the tabs widget being fixed to pick up the first UL or OL it means if you have additional header content in the pane then you can't have a UL or OL in there or it gets tabified!

To give an example of the structure I'm wanting to use:

<div id="mytabs" class="ui-layout-center">
  <div class="ui-widget-header">Some header content
    <ul class="notTabHeader"><li>Some list in the header</li></ul>
  </div>
  <ul class="tabHeader">
    <li><a href="#atab">A Tab</a></li>
  <ul>
  <div class="ui-layout-content">
    <div id="atab">The pane content</div>
  </div>
</div>

Now under UI.Layout I can use this structure easily to get it to set out the header and tabs first and give them enough vertical space so they don't scroll and then the panes will be scrollable if necessary, but if I include a UL in the header then the tabs widget will find that rather than the later UL.

An alternative to allowing the selector to be specified as an option would be to maybe give priority to child ULs and fall back to searching for the first UL regardless of whether it's a direct child or not:

this.list = this.element.find( "ol,ul" ).eq( 0 );

Could become one of:

this.list = this.element.children( "> ol, > ul, ol,ul" ).eq( 0 );
// or
this.list = this.element.children( "ol,ul" ).add( "ol,ul", this.element).eq( 0 );

This would break backward compatibility only if someone has a non-nested UL (i.e. direct child UL of the tab element) that they don't want to be used as the tab list, which would seem to be extremely unlikely!

I understand that my request might be a bit of an unusual case - I can work around the problem by using nested layouts - it just seems a shame to need to do that extra plumbing just because the tab widget is fixed to always use the very first UL or OL it finds.

Change History (8)

comment:1 Changed 8 years ago by Scott González

Version: git1.8.16

comment:2 Changed 7 years ago by Scott González

Owner: set to Skaffen
Status: newpending

This use case seems bad to me. I really don't understand why you would ever want to have content before the tabs. This really sounds like a limitation of the layout plugin. Why can't you put the tabs inside the layout panel instead of having the tabs be the layout panel?

comment:3 Changed 7 years ago by Skaffen

Status: pendingnew

My second paragraph explains why - if it's not clear I can see if I can come up with another way of explaining it.

comment:4 Changed 7 years ago by Scott González

I'd need to see an actual page that does what you're trying to do. I can't picture a scenario where the example markup would be necessary.

comment:5 Changed 7 years ago by Skaffen

With jquery layout a pane can be a straight container, in which case if the contents of the container are too big to be shown in the pane then the container gains the scrollbar. Or a pane can have header/footer elements plus a content element. In which case the pane will be set out such that the header and footer elements are shown in full and the remaining space is used for the content element. The jquery layout plugin site describes the support they have for tabs and accordions whereby the tab or accordion is the pane such that the tab content/tab accordion is the bit that's treated as scrollable by being flagged as the "content" portion and the rest of the elements are header/footer. You can see their demo here: http://layout.jquery-dev.net/demos/tabs.html

You'll see in my use case I have additional header content which precedes the tabs. So the intention is the pane will consist of my header section, then the tabs heading, then the tab content, and the layout plugin will size the content to use the space left after placing my header and the tab heading.

It works at the moment unless UL content appears in my header, in which case the tab code picks that up in preference to the UL which is the direct child of the tab div, hence my request.

Due to gnome shell screen shotting misbehaving I can't get you a screenshot of my use case to help give more of an example, but I'll try sort one out on monday if that would help.

comment:6 Changed 7 years ago by Scott González

This seems like an extremely rare use case. I'd be willing to move this.element.find( "ol,ul" ).eq( 0 ) out of _processTabs() and into its own function so you can override it and add the functionality you want.

comment:7 Changed 7 years ago by Skaffen

I can easily believe it's rare - adding additional header or footer sections into a tabs would only have occurred to me as something to try/do because of the support in the layout plugin for having just the content part of tabs be scrollable. Your proposal for moving that to its own function would certainly solve the problem for me and would be much appreciated.

comment:8 Changed 7 years ago by Scott González

Resolution: wontfix
Status: newclosed

Landed in 0cf6bc042938a11abc09ed4e575c8792585607ac. I'm closing this as won't fix, though it's now possible (and easy) to build an extension that does this.

Note: See TracTickets for help on using tickets.