Re: Tabbed Interfaces in CSS

Replying to two people at once...

On Apr 23, 2009, at 10:19 PM, Tab Atkins Jr. wrote:

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

Well, not with CSS 2.1, but we are talking about new ideas and new  
properties, and I don't think such a  thing would be impossible.

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

If you mean that successively inward elements could not conceptually  
each have a focus, I disagree. I've seen it done with frames and  
iframes, where the outer frame element can be tabbed to, and then the  
next tab key press takes you to a field within it.

I am not suggesting every element in the radio-grouped element should  
each be focusable. But I don't see why adding a "nav-index"[1] value  
to an element, for instance, couldn't make it focusable. Its simple,  
and it can imply intent.

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

I agree that clicking is a first class way to change the "clicked"  
state, and that ideally we would also want a way to do that through  
keyboard focusing. The simplest way I can think of would be to add a  
nav-index to the element that could be focused. If someone wants to  
describe that later with a more complex behavior binding property,  
then fine. I'm for simple authoring solutions though, and binding  
seems like a whole new interface.


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

Yes, I did, more or less. Not that different from all the event  
bubbling and state tracking that goes on with hovering.

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

I agree.

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

That's how I see it too. Even :hover has a similar memory, as it only  
changes when you cross the elements border and go from being inside it  
to outside it (or vice versa). When you are not moving the mouse, the  
state is maintained, in the same way that :checked is maintained when  
you are not clicking on something (or not using keyboard to switch its  
state).


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

Oh, sure, you could probably achieve something like a select control  
or file upload control (for one OS) by using multiple backgrounds and  
lots of generated content. But those weren't  on your list of 'only  
"color", "font", "cursor", "margin", "padding", "border", "outline"  
and "text-decoration". So I don't know what point you are trying to  
make. That list is the list of things that get overridden by  
appearance, not a limit on what visual style an appearance can present.

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

That's fine for you, but I agree that tab appearances would be useful  
to many authors, and that it would require several different parts  
(front/selected, back/unselected, versions for each side and top and  
bottom, a field behind the tabs appearance, and an appearance for the  
box that is shown.

>>>>>> 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
> :checked."

Exactly. Some earlier version of a superficially similar property  
really has little bearing on this.

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

[1] http://www.w3.org/TR/2004/CR-css3-ui-20040511/#nav-index

Received on Friday, 24 April 2009 06:46:03 UTC