Re: Tabbed Interfaces in CSS

Tab Atkins Jr. wrote:
> The Problem
> ===========
> Tabbed layouts are reasonably common in heavily js-driven sites.  They
> allow you to present small bits of information, and offer further
> information if requested without a server round-trip.  I personally
> use a tabbed layout in *all* of the internal sites at my company, to
> organize information without producing a ton of pages.  Because it
> doesn't cause a proper server request, it's also very useful for when
> you are presenting a form, but want to make large amounts of
> information available as well
> In general terms, a tabbed layout consists of a number of 'cards'
> organized into a 'stack', such that only one card from a given stack
> can be displayed at a time.  There are also 'tabs', which activate
> particular cards, causing them to be displayed (and hiding the
> currently-displayed card in that stack, if it's different).
> When phrased in this way, the tabbed layout is even more prevalent
> than one would immediately think, as the popular web 2.0 "accordion"
> construct also matches this definition.  The only difference is that
> in a traditional tabbed layout the tabs and cards are grouped
> separately, while in a traditional accordion the cards are interwoven
> with the tabs.
> As well, a tabbed layout requires the ability to distinguish an
> 'active' tab (corresponding to a currently displayed card) from an
> inactive tab.
If to speak about pure CSS solutions then tabs require "bound" concept
that is not available in modern CSS.
I've mentioned this once: we have intrinsic behavior under <input 
group of DOM elements that in principle allows you to use this behavior for
switching tabs - one of the group will always be in :checked state.

The only thing is missed: this group of elements (each has 
behavior:radio applied)
should be bound to other group. "Bound" can mean different things. I one 
it is about visibility, in other case it is about synchronizing of some 
attribute with
correspondent element in bound group.

There are two approaches how to add such behavioral extensions to CSS.
1) We can pre-define something like "behavior:tabs" in BECSS that will 
do the
    magic "under the hood".
2) We can extend CSS to support state switches.

For the demonstration of second approach:

Typical markup of tabs/cards layout:

  <div class="tab-strip">
     <span current>First tab</span> <span>Second tab</span> <span>Third 
  <div class="panels">
      First panel.
      Second panel.
      Third panel.

Having this markup and active CSS extension [1] I can define tabs/cards 
in CSS as: span
    /* when element will get :active state do: */
    active-on!: /* remove @current attribute from any other*/       
                $1( span[current]).current = null,
                /* set @current attribute on this */
                self.current = true; 
  } span[current]
    /* when element will get this style do: */
    assigned!:  /* remove @current from card panel */
                $1(div.panels > div[current]).current = null,   
                /* set @current to card panel by this index */
                $1(div.panels > div:nth-child(< self:index >)).current = 

  /* pure visual styles: */ span[current] { background: yellow; border:1px solid; 
border-bottom:none; }
  div.panels > div { display: none; }
  div.panels > div[current] { display: block; background: yellow; 
border:1px solid; height:200px; }


CSS by its definition is a set of static declarations that defines 
styles of *states* of elements.
In order to define dynamic behaviors (in CSS) you has to have the way to 
define mutations in CSS -
rules like: "when this element is :active make those element :checked".

Any other "pure CSS solutions" are simply hacks, sorry.

[1] CSSS! - css "script" extensions:!.whtm 

Andrew Fedoniouk.

Received on Monday, 20 April 2009 17:47:53 UTC