Re: Tabbed Interfaces in CSS

On Tue, Apr 21, 2009 at 12:37 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>
> On Apr 21, 2009, at 9:52 AM, Tab Atkins Jr. wrote:
>
>> On Tue, Apr 21, 2009 at 11:48 AM, Brad Kemper <brad.kemper@gmail.com>
>> wrote:
>>>
>>> And actually, the more I think about it, the more appropriate I believe
>>> it
>>> is to have the "tab" near or within the "card" it is associated with. You
>>> have to consider that without styling the HTML should still make sense,
>>> and
>>> it doesn't so much if all the labels for each card are separated from the
>>> blocks representing the cards.
>>
>> I agree *if* a pure-CSS interaction is used.  In that case the older
>> display:stack/card/tab solution is best, because it degrades to a
>> perfectly normal page.
>
> But at the expense of all-new display properties, which I think is a bad
> thing. I should be able to have a set of tabs that use any of the existing
> display values, and not have to delve into this confusing
> display-model/display-role morass. It just doesn't seem necessary, and adds
> extra complexity. My way degrades into perfectly normal pages too.

Oh, indeed, a naive display-based solution would be a bad thing.  My
apologies; I was referring to the general solution of automagically
generating the tabs from markup within the card.

(Though, honestly, we *will* have to deal with the role/model
dichotomy in time.  The only reason it's not immediately obvious that
this is necessary is because all of the 'common' display values are
roles, and have trivial default associations to models (block-inside
and inline-inside, depending), so we are used to just dealing with
that.  We gained our first taste of the problems caused by the
conflation of role and model with the table and inline-table values
(arguably inline-block was the first, with role:inline and
model:block-inside), and we see it again with the stopgap solution in
the current Template Layout draft (an optional "inline" value
preceeding the template).  It will only get worse as we add more
models, and we already have a few roles that have problems combining
with other values.  It's impossible to make an <li> into a table,
frex, without losing the list-bullet (as that's part of
display:list-item).  Table's a model, though, while list-item is a
role.  Hell, it's impossible to make an <li> *inline* and have it keep
its bullet.  People have to abuse floats just to get a horizontal list
with bullets, because float's not a display value and won't interfere.
 Gah, this actually just means that list-item shouldn't be a display
type at all - all it means currently is "display:block, and generate a
::marker pseudoelement filled by an appropriate counter".

In short: display is all kinds of messed up, it's just not very apparent yet.)

>> If tabs can be separated from cards in the markup, then I think the
>> mechanism *has* to be link-target-based, so that it degrades into
>> links to the appropriate section on the page, which is still sensical
>> and somewhat useful.
>
> Using LABEL, with some small adjustments for the FOR attribute, would also
> allow that separation. Clicking on the label is like clicking on the element
> it either surrounds or is FOR.

Nah, using <label> wouldn't degrade properly.  Without the CSS to
control display based on the :checked state, you'd have a document
with everything laid out, plus a couple of random section labels
bunched together for no good reason.  The fact that there's a <label>
wrapping them isn't obvious, and has no effect on the behavior of the
page.  Links at least provide some useful functionality without the
CSS - they'll direct you to the appropriate tab.

In order for the purely-click-based approach to degrade properly,
you'd have to generate the tabs based off of existing markup within
the cards (generally, a header).  That way you'd have a normal
document in the absence of the appropriate CSS.

> Links are only one thing at a time, so using
> them for tab-panel-showing would not allow a page with more than one set of
> tabs to have a particular tab in the front.

Hm?  I addressed this in my proposal.  Cards are *activated* by links,
but they don't depend on links to *stay* activated.  The CSS engine
would keep track of which card is active in each stack.

> And wouldn't it also cause the
> page to scroll to the tab, whether that was wanted or not?

Yes it would.  This is currently a problem, but Giovanni suggested a
solution in the link behaviors spec.

> I'm not a fan of
> using links in this way, as it really requires a set of in-page links be
> added to the HTML, instead of using naturally occurring structures of the
> page that are already appropriate indicators of the content they represent.

Indeed, it's a weakness of the proposal.  It makes it much less useful
(actually, usually useless) for existing pages, but makes it useful
for when you're designing something that you know you want to use a
tabbed or accordion structure for.  I've got a few glimmers of how to
solve this relatively elegantly, though, allowing both explicit and
implicit tabs in my proposal.

~TJ

Received on Tuesday, 21 April 2009 18:59:22 UTC