Re: Tabbed Interfaces in CSS

2009/4/21 Andrew Fedoniouk <news@terrainformatica.com>:
> 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.

Flow === display-model
The difference is just the name (but this is another issue, another
thread, another topic)

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

Uhm... we currently have behavioural extensions to CSS, we could
define some "default behaviours" (the same as HTML5 does for form
inputs) and drop all this mess of display:tab, display:card,
display:stack, card-stack, :checked on everything (and no way to
define when checked or not checked)
Using that, you just use

binding: url(about:binding?type=card&stack-name=mystack);

on the cards, and

binding: url(about:binding?type=tab);

on the tabs

Simple, elegant, and working on current browser (Gecko / Trident based only)

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

Bind some XBL2 and you're done.

> --
> Andrew Fedoniouk.
>
> http://terrainformatica.com
>
>
>

Giovanni

Received on Tuesday, 21 April 2009 20:04:12 UTC