Re: Tabbed Interfaces in CSS

On Apr 24, 2009, at 9:35 AM, Giovanni Campagna wrote:

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

I don't understand your point. First you say you "don't support your  
":checked" on any element ". Then you say "UAs should anyway keep  
track of :checked for every element", which seems to be the opposite  
point of view.


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

So it is just a matter of syntax now?

user-select: toggle-group(<ident>) = radio-group:<ident>

and

user-select:alternate = ?? toggle ?? = radio-group:none

With the way I have the syntax, the item that receives the focus does  
not have to be the same as the item whose checked-state is being  
tracked (thanks to event propagation). I consider this an advantage.  
The fieldset can be the repository of the state information, and its  
children styled accordingly, but only the legend need receive the focus:

legend: nav-index:auto;

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

That seems like an unreasonable burden to foist on so many people,  
just because they expect their computer to behave according to its OS  
standards.

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

As an author, I think there are many good reasons for having visual  
styles that do not match the OS defaults for UI items (for branding,  
for emphasis, for other design reasons), although there are certainly  
those who would disagree even with that. The argument to change  
expected UI behavior is much weaker, and is likely to frustrate much  
more than it helps. As for emulating form inputs, I would rather form  
inputs just became much more consistently stylable, so that you  
wouldn't need to re-invent them.


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

Its a difference that makes no difference. If an arbitrary element is  
checked, but there is absolutely no evidence of it until you actually  
decide to style based on that, then how does it matter? If later, when  
actions can be reliably bound to arbitrary elements, then I would  
fully expect that to be able override the default action. But really,  
we are only talking about the state of the item (checked or not), not  
the action that can look at that state (or not).

> Really, it sounds weird to me to have a checked textfield,

Not much to me, so I probably wouldn't style anything based on that.

> a checked
> image

It could mean that you want to draw a border around it when it is  
clicked on, or remove the border when it is clicked again (or when  
another item of the same group is clicked if it was part of a group).  
What does it mean to have a hovered-over image?

> or a checked header: what would they mean?

It could mean "show the small explanation text in the span within this  
header". It could mean nothing more than "this is the header you  
clicked on."

> If it is just activation that your following, well...
>
> :nth-activation(na+b) = the element has been activated an na+b  
> number of times

Ick.

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

That's not about quirks or bugs, its about authors specifying  
something in their CSS that they might not actually want, or being  
sloppy with their HTML. I certainly don't want to restrict CSS to only  
those properties that authors cannot do ugly things with.