Re: Tabbed Interfaces in CSS

On Apr 24, 2009, at 8:32 AM, Giovanni Campagna wrote:

> 2009/4/24 Brad Kemper <brad.kemper@gmail.com>:
>>
>> On Apr 24, 2009, at 5:40 AM, Giovanni Campagna wrote:
>>
>>> First of all, read User Interface for CSS3 [1]. You'll find in  
>>> section
>>> 5.3.3 a property called "user-select", that defines the selection /
>>> activation behavior for all elements, regardless of event handling
>>> registered on them.
>>> The value "toggle" says that activation (mouse click, enter key  
>>> press)
>>> should toggle the :checked pseudo-class, using the value of
>>> "toggle-group": if the latter is "none", element is a checkbox, else
>>> it is a radiobutton (only for :checked).
>>>
>>> This means that to your proposal you just need to add
>>> "user-select: toggle" in the style for cards
>>> (it may be implied by appearance:card, but I hope no, since it is  
>>> not
>>> implied by appearance:checkbox or appearance:radiobox currently)
>>>
>>> Adding this property would it be a problem for you?
>>> If yes, why?
>>
>> User-select seems like overkill, unless it is genuinely useful  
>> beyond this.
>> A click without a drag should be enough to toggle the radio button
>> click-state.
>
> Ehm... what does "click without a drag" mean? I can click on a radio /
> checkbox button and drag, and it will check it (if I end my mouse
> movement inside the button).

Whatever. I'm kind of liking my iPhone too much, probably. Any mouse- 
up then.

> Besides "user-select" is very useful also outside of "toogle", for
> example if you want to make your links act like push-buttons
> (unselectable).

I don't feel strongly about that, but I don't want it to slow down the  
even more useful radio-button-state or checkbox-state tracking on  
other elements.

> Really, I don't support your ":checked" on any element proposal: I
> author, want to control which elements can be checked and which
> cannot,

What does it matter if some element that you don't style differently  
with 'checked' is keeping track of that state or not? You would  
control if there is a noticeable difference or not between the two  
states. There would be no visual difference unless you set one. You  
would control if it was selectable or not. It would not submit as a  
form element does.

> and "user-select: toggle" is a good way to do it (not the only
> one, sure, but an explicit declaration is necessary)

I just don't see why setting two properties is preferable to setting  
one, when the effect is the same. If the purpose of setting two  
properties is so that you get the "selectable" behavior too, then just  
use the property I suggested to do that. It seems a lot more  
straightforward and intuitive.

> [...]
> Forget "user-input" as well. Just keep:

> "user-select" : control the selection behavior
> "user-focus" : control the focus behavior

As a Mac user, I would really hate it if the author overrode the  
default selection behavior when I tabbed to a text field or something,  
and the text was not selected in a way I was used to. I'm sure there  
are many Windows users that would feel the same way if their text  
fields took on the Mac way of selecting, or otherwise worked in an  
unexpected way.

With tabs or accordions, etc. it is much simpler. All you need is to  
say if it is focusable or not (i.e. with nav-index), and then declare  
an OS-styled outline around it when focused.

> "nav-index" : control the navigation (focus) order
>
> I really prefer them to "nav-index" + nothing. At least the author is
> aware of what is actually happening at his pages.

How is the author unaware of anything? If I explicitly put 'nav- 
index:auto' into my style sheet, it seems pretty clear that I want it  
to be focusable, such as by tabbing to it.

>
>
> Giovanni

Received on Friday, 24 April 2009 16:28:09 UTC