W3C home > Mailing lists > Public > www-style@w3.org > April 2009

Re: Tabbed Interfaces in CSS

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 23 Apr 2009 09:16:59 -0500
Message-ID: <dd0fbad0904230716p5665c835qa6d682e9f9756e4e@mail.gmail.com>
To: Giovanni Campagna <scampa.giovanni@gmail.com>
Cc: Brad Kemper <brad.kemper@gmail.com>, www-style list <www-style@w3.org>
On Thu, Apr 23, 2009 at 7:02 AM, Giovanni Campagna
<scampa.giovanni@gmail.com> wrote:
>>> 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!)

I'm not quite sure what you mean here.  Do you mean that most of the
page can't receive focus?  This is true, hm.

> - You cannot use "click", if the user hasn't got a mouse: you need DOMActivate

That's fine.

> - Some elements already have a default action for DOMActivate (buttons, links)

That's fine as well.  If they bubble the event, great.  If not, that's
fine too - don't depend on that to work as a tab.  A test I just
performed shows that links work just fine with this (a radio button
will be activated whether its label is within or wrapped around a
link).

> - 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);"

That's essentially identical to what Brad's asking, as long as it
interacts with the :checked pseudoclass properly.

>>[...]
>>
>>> 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)

That's all that :checked represents as well - a state.  It just
conveniently allows us to define some behavior, similar to how :hover
let us create Suckerfish menus.

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

Can you elaborate on this?

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

Presumably nothing.  Appearance does have the benefit of being
UA-specific, so they can present things however they decide is best
for the platform they're on.  But appearance really has absolutely
nothing to do with this proposal.

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

Why not?

~TJ
Received on Thursday, 23 April 2009 14:17:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 03:46:58 GMT