Re: Tabbed Interfaces in CSS

On Tue, Apr 21, 2009 at 11:58 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

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


My point is that complicating the 'display' property and having lots of
magic involved is not as simple as using what we already have: a secondary
state through 'checked' that makes sense for items like tabs with radio
control control behavior desired or any other on/off behavior desired, items
that act as defacto visual identifiers already (such as caption, legend, and
label), and appearance to easily get OS-appropriate tab styles.



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


Making 'display' a catch-all for so many types of things just makes it more
byzantine and complicated, not less. It is not obvious (to me) from the name
which of "role" and "model" is what we have already and which is the new
part, and I don't really want you to explain it to me and ask me to memorize
that. Put the new one into "flow" or something else, and leave "display"
alone.

The thing I proposed is simple and does not require that we completely
rewrite how 'display' works, or even that we solidify how something like
'flow' works. Tabs really have nothing to do with either one.


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


'display:list-item', 'display:table', and 'display:inline' all have
different qualities. Its also impossible to have an item that is block and
inline at the same time, except that with inline-block you can. If there was
a compelling reason to have a bullet on a table, then that would probably be
display value too.

If you did want to make an <li> inline with a bullet, there are certainly
ways to get that effect, such as with '::before' and 'content' (or with
backgrounds if it is an image).


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


Right. Personally, I think list markers should be described as being some
sort of shorthand for generated content. But this seems off-topic. My point
was that all this display-role or whatever is a dependency that complicates
both the tab proposal (and slows down its implementation) and the display
property, and your comments about it really seem to make that point too. My
proposal does not require such sweeping changes.


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


I don't think there is a high demand to make it more complex than it already
is. I think many authors are excited to be able to use 'display-table-cell',
etc. once IE6-7 finally dies a horrible death, and that it is not that bad
to use in practice.


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

But if a person wanted to list a bunch of de facto labels for things at the
top (as you are proposing, but with a requirement that anchors also be
present), then that would be doable too.


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


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


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


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