- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Mon, 20 Apr 2009 10:47:08 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: www-style <www-style@w3.org>
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 type=radio> 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 case 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 tab</span> </div> .... <div class="panels"> <div> First panel. </div> <div> Second panel. </div> <div> Third panel. </div> </div> Having this markup and active CSS extension [1] I can define tabs/cards in CSS as: div.tab-strip span { /* when element will get :active state do: */ active-on!: /* remove @current attribute from any other*/ $1(div.tab-strip span[current]).current = null, /* set @current attribute on this */ self.current = true; } div.tab-strip 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 = true; } /* pure visual styles: */ div.tab-strip 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: http://www.terrainformatica.com/htmlayout/csss!.whtm <http://www.terrainformatica.com/htmlayout/csss%21.whtm> -- Andrew Fedoniouk. http://terrainformatica.com
Received on Monday, 20 April 2009 17:47:53 UTC