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

Re: Tabbed Interfaces in CSS

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 24 Apr 2009 00:19:27 -0500
Message-ID: <dd0fbad0904232219hd0691e7j3b21300bfbed4512@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 10:15 AM, Giovanni Campagna
<scampa.giovanni@gmail.com> wrote:
> 2009/4/23 Tab Atkins Jr. <jackalmage@gmail.com>:
>> 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.
> Not that most of the page can't receive focus, rather that you cannot
> focus <html>, then <body>, then <div>, then <header>, then <h1>, then
> <h2>, then <section>, then <p>, then <span>, then <a>, then <b>, etc.
> (assuming a minimal example markup of
> <html><body><div>
> <header><h1>main header</h1><h2>secondary header</h2></header>
> <section><p>content <span>that is <a>linked and <b>important <!-- add
> here --></b></a></span></p></section>
> </div></body></html>
> )
> In order for Brad proposal to work, I need to focus the elements to
> get them checked (and I need to focus them all, because I may check
> them all!)

For keyboard navigation, sure, that's a problem.  With mouse-based
navigation it's not, though.

Can we patch this, perhaps in a loosely-coupled way?  That is, does it
seem feasible to push the proposal as being mouse-based, and then in a
later module which introduces "binding", add the 'focus' behavior to
elements for proper keyboard navigation?

>>> - 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).
> Default actions cannot stop the event propagation (or scripts will
> start complaining a lot about events not firing)

O...kay?  I didn't say anything at all about that.

>>> - 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.
> I like using the :checked pseudoclass.
> But with binding, only certain elements have the ability to receive,
> or really to process, events generated by keyboard, mouse or
> touchscreen, and to dispatch the associate DOMActivate, that in turn
> sets :checked.
> Brad instead says that every click should dispatch a DOMActivate, and
> every DOMActivate should set a :checked.

Yup, Brad does say that.  Click events, as they bubble through the
DOM, switch :checked states.  I'm not big on the details of the event
model, but presumably activating focusable elements would do the same
thing, in whatever way that is possible.

>>>>> 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.
> Probably you're right. Yet I'm not sure that :checked is the same as
> :hover (or :active)

Well, can you say why it's different?  :hover is a state that changes
solely on the position of the mouse as it moves across the screen,
while :active is a state that is received *while* you are clicking on
an element.  :checked is just like an :active with memory.

>>>>> 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.
> Well, we surely need to extend "appearance:tab" to something more
> useful for tabbed layout.
> And since this is developing into a proposal for an Advanced User
> Interface Module...

We surely don't need to do anything of the sort.  Getting something
useful out of the appearance property may be a bonus, but it's one
that is not at all necessary.  I know that UA-default tabs are likely
going to be far too ugly for use in any of my projects, so I'll be
using custom styling.

>>>>> 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?
> Toggle-group only says that the element belongs to the group. It does
> not say what happens to it and to the other element when it is
> focused, activated, clicked, etc.

Ah, okay, so you don't like toggle-group specifically because of it's
particular details (or rather, lack of them).  That doesn't seem to
have any bearing on radio-group (even if it gets named toggle-group).
radio-group would just say, "Whenever an element is made :checked, if
it has a string value for radio-group, then any other elements with
the same string value for radio-group are made to no longer match

> If this should be specified with binding, then you can pass parameters
> to the binding, you don't need a new property.
> Really, I don't like many properties in 5.3 - 5.4 of
> <http://www.w3.org/TR/2000/WD-css3-userint-20000216>, that in fact
> were dropped in css3-ui
> So either we complete that proposal with 1.5.7 of the same draft and
> add user-activate, user-focus, user-modify, toggle-group etc.
> or we simply say that all the behavior is out of CSS scope, and shall
> be attached with binding.

Or we just define it simply for now (based on mouse clicks, and
activation of focusable elements), and let binding fix the
accessibility issues afterwards.

Received on Friday, 24 April 2009 05:20:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:26 UTC