- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Tue, 21 Apr 2009 14:55:03 -0700
- To: Giovanni Campagna <scampa.giovanni@gmail.com>
- Cc: Andrew Fedoniouk <news@terrainformatica.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
- Message-ID: <7e1f93760904211455y5ee6899ekb9cc39c3eac4230b@mail.gmail.com>
On Tue, Apr 21, 2009 at 1:03 PM, Giovanni Campagna < scampa.giovanni@gmail.com> wrote: > > 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) Ah, I see that this is what Tab was referencing in his earlier e-mail. I believe I did mention some ways to define when checked or not, but here you go: - If an element was not part of a radio group (such as with 'radio-group:mytabs'), then it would have checkbox behavior, defaulting to not checked and then alternating with each click on it. - If it was part of a radio group, then by default the first of that group (in source-code order) would would be checked and the others unchecked, until clicking on one of the others causes the first one to be unchecked (just like radio buttons, in other words). - The default could be changed via a property (for example, as I wrote before, 'fieldset:nth-of-type(2) { default-checked:checked; }'. - If the markup language allowed it, it could be set by a "checked" attribute on the element. > 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) Interesting. I wasn't aware of that (maybe because I use Webkit?). In any event, this binding can also describe some built in default behavior too, right? So it is not necessarily incompatible with my proposal. > > There are many other use cases when CSS would need something like > > event/state handling. > But the tab behavior I've described would not depend on it. > > 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. > Not so much to cover common cases. > > > Bind some XBL2 and you're done. > > > -- > > Andrew Fedoniouk. > > > > http://terrainformatica.com > > > > > > > > Giovanni >
Received on Tuesday, 21 April 2009 21:55:44 UTC