Re: Tabbed Interfaces in CSS

2009/4/22 Brad Kemper <brad.kemper@gmail.com>:
>
> On Apr 22, 2009, at 6:18 AM, Giovanni Campagna wrote:
>
>> We are leaking from Tabbed Layout into Advanced User Interface,
>> Behavioural Extensions to CSS, CSS Object Model, Selectors Level 4...
>>
>> 2009/4/22 Brad Kemper <brad.kemper@gmail.com>:
>>>>
>>> Slightly modified from the first time I sent it:
>>>
>>> fieldset { radio-group:mytabs; appearance:tab-card; display:inline-block;
>>> position:absolute; left:0; }
>>> fieldset:not(:checked) { appearance:none; z-index:-1; }
>>> fieldset:not(:checked) * { display:none; }
>>> fieldset:not(:checked) legend { appearance: tab-top-back;
>>> display:inline-block; }
>>> fieldset:checked legend { appearance: tab-top-front;
>>> display:inline-block; }
>>>
>>> See below for an explanation of each line and how it would affect the
>>> rendering...
>>>
>>>> and what would be the expected
>>>> rendering?  (I ask for this again just to ensure that I am absolutely
>>>> comprehending your proposal properly.  I had the advantage of starting
>>>> a thread with a formal proposal; yours developed somewhat organically
>>>> within the thread.)  Make sure that there's a way to distinguish the
>>>> active tab as well.
>>>
>>> fieldset { radio-group:mytabs; appearance:tab-card; display:inline-block;
>>> position:absolute; left:0; }
>>> This first rule says that both fieldsets in your example are part of the
>>> same radio group, given the identifier of "mytabs", and that they should
>>> have the OS appearance for the display area of a tabbed display (an
>>> author
>>> could specify their own style instead of using appearance if he wished).
>>> By
>>> putting these into a radio group, the UA should track the "checked" state
>>> of
>>> each one according to radio-button standards, not according to check-box
>>> standards. By default, the first fieldset ("foo") has a "checked" state,
>>> and
>>> any others ("bar") do not. The absolute positioning and the inline-block
>>> display makes all the fieldsets appear at the same x/y coordinates.
>>
>> Ehm... the fact is that the tracking of :checked state (according to
>> Selectors Level 3) depends only on the markup language. And neither
>> HTML4 nor HTML5 (nor XHTML1.0 / 1.1 / 2) define :checked for fieldset
>> (actually, for everything outside input[type="checkbox"] and
>> input[type="radio"]).
>
> This proposal, like all proposals, would require some change to specs and
> adoption by implementors.
>
>> So you need to define how the element is
>> checked.
>
> See the four bullet points near the top of the e-mail I sent to you and the
> list yesterday at 2:55 Pacific Time, which was in direct response to your
> allegation that there was "no way to define when checked or not checked."

That will not work:

- You cannot make any CSS box focusable (any block, any line, any
table, any cell, anything!)
- You cannot use "click", if the user hasn't got a mouse: you need DOMActivate
- Some elements already have a default action for DOMActivate (buttons, links)
- All elements already have a default action for click (selection) and
some have also for keydown / keyup (all input when a default button is
present, textareas and contentEditable sections)
- Dispatching arbitrary DOMActivate would break existing pages (also
because they usually preventDefault() for links)

I really don't see why your so concerned with the ability to set
:checked on all elements, when that is feasible on certain selected
elements with the appropriate binding.
Again, I'm not asking for JS or XBL2, I'm asking for
"binding:url(about:checkable?set=my-ident);"

>[...]
>
>> This represent the behavior (event handling).
>
> So does clicking on radio buttons and checkboxes, or hovering over a link.

If you look at the rendering section of HTML5, the behavior for radio
/ checkboxes is defined in terms of UA bindings.
:hover is only for pointing devices (actually, only for mice) and
represent a state, rather than a behavior (the user *is* hovering the
element, it does not *do* anything)

>> You need some way to
>> attach behavior (BECSS)
>
> Not if the UA does it for me, as it does with those other events that change
> what CSS rules select.

The UA cannot do it for you, not for every element at least. That
would cause a lot of problems.

>> and to change the pseudo-classes that apply to
>> an element (CSSOM).
>> "appearance", per Basic User Interface, includes only "color", "font",
>> "cursor", "margin", "padding", "border", "outline" and
>> "text-decoration":
>
> Typical OS appearances may replace those properties, but they also add to
> them and create appearances that are often not achievable by setting CSS on
> a single element.

Uhm... what cannot you achieve with those properties, the background
and borders properties, some pseudo-elements and generated content?
("appearance" may be extended to other properties, the Basic UI says)

>> no "binding", no "xml-events", no "onclick", no
>> "behavior", no "left", not even "width", "height" or "display".
>> But, if we can define a value for "appearance", we can safely define a
>> set of keywords or UAs native URIs for "binding". You don't even need
>> "radio-group" (formerly "toggle-group").
>
> I proposed radio-group as an indicator that the item was part of a radio
> grouping and would have the state tracking that radio buttons have. If there
> was something already called "toggle-group" to do the same thing, then fine.
> I was proposing that as something for Selectors or for HTML, not Appearance.
> I would want it to work even if Appearance was not used to style the tabs.

"toggle-group" was in User Interface for CSS, superseded by CSS Basic
User Interface. I definetely don't hope it will make into CSS again.

Giovanni

Received on Thursday, 23 April 2009 12:03:25 UTC