Re: Tabbed Interfaces in CSS

2009/4/24 Brad Kemper <brad.kemper@gmail.com>:
>
> 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.

UAs should anyway keep track of :checked for every element (even if no
:checked are present in the stylesheet - I may insert them at some
time)

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

Set "user-select: toggle-group(<ident>)" and "user-select:alternate"
=> one property, two values, and the current behavior for the initial
value.

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

As a Mac user that would hate such behavior, you would use an user
stylesheet and an !important declaration.
As a cross-platform author, I would like consistency across platforms
and so would ask (if possible) to have the same behavior everywhere
(including when such behavior is predefined for certain form input I
am trying to emulate without HTML/XForms tags)

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

I said: "nav-index" + *nothing*, so the point I was trying to make was
about the nothing part, ie the inability to choose the clicking
default action for your element (that make arbitrary elements checked)
Really, it sounds weird to me to have a checked textfield, a checked
image or a checked header: what would they mean?
If it is just activation that your following, well...

:nth-activation(na+b) = the element has been activated an na+b number of times

With this, you don't have the backward compatibility problems caused
by reusing :checked.
For further info look at
<https://developer.mozilla.org/en/Issues_Arising_From_Arbitrary-Element_hover>
it is about :hover when it was extended from a to every element - the
same compatibility issue will arise if :checked is propagated from
input[type=checkbox], input[type=radio] to every element.
And we don't want to extend quirks mode further, do we?

Giovanni

Received on Friday, 24 April 2009 23:43:24 UTC