Re: Tabbed Interfaces in CSS

On Thu, Apr 23, 2009 at 12:23 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
> On Apr 22, 2009, at 2:15 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>> Displaying a front/back tab in a UA-default way seems like an
>> appropriate job for appearance, but you are using it as well to
>> somehow move the tabs to the top/bottom/side/etc.
>
> NO. I never said that. You are reading too much into it, and then arguing
> against your own conceptions. All I suggested is that the appearace of an OS
> tab is different for different sides, which I hardly thought was
> controversial. For instance, a tab that was intended for the bottom would
> look a lot like an upside-down version of a tab intended for the top, except
> that the text would be right-side up. This says nothing about where you
> actually put the tab.
>
> If you wanted to actually move said tab to the bottom of the fieldset, it
> would be a fairly simple matter with absolute positioning. And you could
> move to sides with that and transformation, I imagine. But again, that's
> just more styling that goes beyond the simpler concept that I was trying to
> show (that extending checkbox and radio button 'checked' states and behavior
> beyond just inputs would be useful, and could be used for things like tabs,
> which to programmers are generally just a sub-class of radio buttons
> anyway). I didn't think I would need to get into all the obvious stuff about
> how to use CSS 2.1.

Gotcha.

>> If you could provide a simple ugly example just using border, padding,
>> and margin, while still achieving the desired tab *layout*, I'd be
>> happier.  ^_^
>
> Why? When you wrote an example you just wrote "/* insert generic tab styling
> here */", which pretty much describes how I was using appearance. But if you
> want to take your own example and fix the display:none part according to you
> newer understandind of how I was hiding inactive cards, then you'd have your
> answer. Or you could use fixed widths on the tabs and set the 'left'
> position of each according to the width of those that preceded it. Or use
> one of the other methods I've described already.

I wanted a simple example to make sure that any positioning that
occurred was explicitly spelled out, since I was still thinking that
you were relying on the appearance property to do something with
positioning.  Plus, hey, the less new things used in the examples, the
better.  After all, using appearance when normal properties would have
sufficed seems to have confused the hell out of us.  ^_^  At least, it
distracted us from the more relevant parts of your proposal.

>> Frex, look at the fieldset/legend example.  Let's say the first
>> fieldset is :checked currently.  In this case, then, the order of
>> content is:
>>
>> fieldset-one content before the legend
>> fieldset-one legend
>> fieldset-one content after the legend
>> fieldset-two legend
>>
>> That's... not really what you want.  It's basically an accordion,
>> because the card contents will be distributed between the tabs.  I
>> think you may have overlooked this,
>
> No, I think you are overlooking that the fieldsets are position:absolute. So
> they don't take up space and this should all have the same x and y
> coordinates (I think I said this before).

Indeed I was overlooking that!  That changes, well, everything.  ^_^
I'm pretty certain you didn't mention that before, but there are a lot
of emails here and I'm not interested in reading back through all of
them to check.

Okay, so absolute positioning is a possibility.  You have to manually
position the tabs, but hey, it's workable in many circumstances.
Template Layout'll allow a more flexible solution as well.  I think
we're good here, then.

>> and thus not really understood why
>> Giovanni and I keep harping on the degree of appearance magic you're
>> depending on.
>
> This is the first I've heard of this particular misunderstanding. I've
> always maintained from the start that I was not depending on any appearance
> magic. If something didn't make sense, it had little to do with Appearance.

Your words fell on deaf ears.  ^_^  We kept not seeing the couple of
details that provided the magic (and in your previous example code,
the details wouldn't have worked correctly even *had* we noticed
them).

>> 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.

(Fixed-width tabs are indeed often just fine.)

> OK thanks. Sorry if I come off as a little defensive. I've typed the above
> on an iPhone, and don't want to edit this message any more.

It's cool.

~TJ

Received on Friday, 24 April 2009 05:07:22 UTC