Re: Tabbed Interfaces in CSS

Tab Atkins Jr. wrote:
> (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.)
>   
The 'flow' allows to replace lists horizontally without any problems:

ul { flow:horizontal; padding:0;}
li { padding-left: 2em; width:*; [display:list-item;] }

I would suggest to consider 'display' as an attribute that defines 
requirements of the element to its container.
And the 'flow' as a definition of the way how container does layout of 
its children.
Ideally 'none', 'block', 'inline' and 'inline-block' have to be the only 
values of the 'display'. I would even exclude
'none' from the list and move it into 'visibility' list of values.
I agree: currently 'display' is a mess of different things.

But we already at the point when 'display' cannot be changed (table 
stuff can probably be safely removed if it is not too late).

I do not see how the 'display' is related to tabbed interfaces though. 
Conceptually it is just two sets of elements where something like
:checked in one group is bound with visibility of elements in other 
group. There are too many various way to style tabs and
cards appearance - we'd better not even to try make it fixed in 
display:cards or so.

In general you need to be able to define something like this (pseudocode):

ul .tabs > li
{
   behavior:radio; /* behaves as member of radio group, :checked */
}
ul .tabs > li:not(:checked)
{
   set: $(div.card:nth-child(index)).visibility = collapsed,
}
ul .tabs > li:checked
{
   set: $(div.card:nth-child(index)).visibility = visible,
}

But that is pretty much that CSSS! thing I was talking.

There are many other use cases when CSS would need something like 
event/state handling.
This card *behavioral* thing is one of them, others are animations, 
printing (think about page-start, page-end events)
and may others. As an example think of <input type="slider" min=1, 
max=4> bound with visibility of four different paragraphs.
( See: Internet Options -> Privacy tab in IE). I mean that there are too 
many variations of even "simple" tab/card functionality
to be able to define their behavior and layout in CSS.

--
Andrew Fedoniouk.

http://terrainformatica.com

Received on Tuesday, 21 April 2009 19:53:49 UTC