Re: Tabbed Interfaces in CSS

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

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

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

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

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

~TJ

Received on Tuesday, 21 April 2009 21:52:47 UTC