W3C home > Mailing lists > Public > www-style@w3.org > April 2009

Re: Tabbed Interfaces in CSS

From: Brad Kemper <brad.kemper@gmail.com>
Date: Thu, 23 Apr 2009 22:42:43 -0700
Cc: Giovanni Campagna <scampa.giovanni@gmail.com>, www-style list <www-style@w3.org>
Message-Id: <9D505EE7-28CC-49E1-A85A-0BA741DCF7F0@gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>

On Apr 23, 2009, at 10:06 PM, Tab Atkins Jr. wrote:

>>> You *need* the ability to flow tabs out of their normal
>>> position to make this work properly as a tabbed layout;
>>
>> Not if you are willing to have fixed tab widths, and I have seen  
>> designs
>> that do. And not if tab appearance could include self management of
>> left-right placement in a line for proper OS overlap/spacing/ 
>> alignment. .
>
> This is a line that keeps setting off alarm bells in my head.  How in
> the world is *any* sort of tab-appearance supposed to automatically
> handle spacing in the abspos example you give?  There's no way to
> indicate that the tabs should be part of a cohesive whole.  Unless
> you're thinking something that I've completely missed, *this* would
> require strong magic, which I don't like.

Well, the way I saw that was that the UA would know that they were  
part of the same radio group (because we told it the group their  
nearest ancestor were all in, and that the legends should be tabs),  
would have a computed width for each, would be able to tell when they  
were positioned in a way that caused them to overlap, and would  
correct that by moving each successive one to the right. These seem  
like small leaps to me, and within the normal small magic of appearance.

It would be trickier if they had to be, say, center aligned, but  
something like that might also require the UA (regardless) to be able  
to draw a UA background for the tabs for the areas where individual  
tabs weren't, and that background tab field might need to be  
determined inductively by looking at the width of the tab card item  
and the vertical position of the first tab (or something). It does  
seem to me that "appearance:tab" is incomplete, and not just because  
it fails to take into account the different tab looks when they are  
are different side and front and back. You also need an appearance  
value for the "card" part that is revealed when you click on a tab,  
and an appearance for the field that the tabs are drawn against. If  
that field is generated automatically (the hard part), then self  
alignment of the tabs within it should be easy. If it has to be done  
by the author (via ':outside' or something on the first tab?) then it  
gets harder. I suppose it could be just an extra tall top pard of the  
card part...

Anyway, one of the other proposals seemed to have tab box appearance  
built into it, so I was including that idea in mine too, as I thought  
it could help a bit with making the tabs appear correctly aligned. But  
don't get hung up too much on that part, which should really be a  
separate proposal.


> (Fixed-width tabs are indeed often just fine.)
Received on Friday, 24 April 2009 05:43:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 03:46:58 GMT