Re: Tabbed Interfaces in CSS

On Tue, Apr 21, 2009 at 2:52 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> (The whole display discussion is *really* tangential at this point,
> since my proposal doesn't use display at all (the old approach in
> Advanced Layout did), so I'll split it out into a new conversation.)
>
> On Tue, Apr 21, 2009 at 4:35 PM, Brad Kemper <brad.kemper@gmail.com>
> wrote:
> >> >> 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.
> >
> > It would be an authoring option for those who really want to be able to
> > write them all in one place, since there seemed to be a desire for that
> on
> > this list. I prefer that they either wrap the item they are assoicated
> with
> > (technically a no-no, since they are by default inlilne HTML elements),
> or
> > are inside the item they are assoicated with (near the top), or that
> > headlines, captions, or legends (etc.) be used instead, since they would
> > naturally exist in existing layouts, in places where they label the
> > content.
>
> Can you give a markup example of exactly what you're proposing?  I'm
> really not understanding what structure you're trying to hint at here.


Three fieldsets, each with a legend, could become a 3-tab panel using the
css example I provided earlier, with the  css changes I proposed earlier.
Did that not make it onto the mailing list?


> >> 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.
> >
> > I believe I've already suggested that as a pretty natural way of turning
> > content into tabs.
>
> Suggested what?  What I just said isn't a way of turning content into
> tabs; I just said that you'd have to have *some* way of turning
> content into tabs if you want to unobtrusively add tab functionality
> to the page.


I wrote an e-mail this morning in which I suggested how you could generate
tabs from existing markup, with only some small changes to the styling
language required. I gave an example involving fieldsets with legends, but
also mentioned that it could be accomplished similarly via tables with
captions or div/sections with headlines. It looks like this e-mail was sent
to the list...

So the answer to 'what' in your question of 'suggested what' (in regard to
my 'suggested that') is that 'you'd have to generate the tabs based off of
existing markup within the cards (generally, a header).' And my e-mail from
this morning was 'the way' that I suggested.

>> > 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.
> >
> > Sorry, I guess I missed that you were adding more magic there. But then
> > there is no way to make one of the tabs other than the first as a
> default,
> > other than by changing the URL to the page? And even then, only one of
> the
> > sets of tabs could have a default?
>
> Right now, yes.  Is it important that a different tab than the first
> show as a default?


Sometimes. Yes. Absolutely. Not as important, perhaps, but certainly
desirable.


> (I think your proposal would do this by making @checked a global
> attribute, right?  You'd need to change HTML for that.)


See my last e-mail in response to Giovanni. I'm not above asking for a small
change to HTML, but I don't require it.


> >> > 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 didn't see that, and still can't find it in skimming through what he
> > posted. Another dependency on a different spec?
>
> "Another" dependency?  I don't believe I currently rely on any other
> spec.  And the dependency only exists if (1) the author decides that
> the scrolling behavior is inappropriate, and (2) we don't just fold
> the anti-scrolling magic directly into this proposal.
>

One propopsal for tabs requires display-roles and display-models, which is a
big can of worms. Yours requires a link behaviors spec to prevent unwanted
scrolling (or that people find it acceptable for clicking on a tab would
scroll the page). Mine has neither of these requirements, but just extends
an existing pseudo-class to more elements, and adds a couple properties to
indicate radio groups and for defaults.