Re: Tabbed Interfaces in CSS

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

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

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

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

>>>> You need some way to
>>>> attach behavior (BECSS)
>>>
>>> Not if the UA does it for me, as it does with those other events that change
>>> what CSS rules select.
>>
>> The UA cannot do it for you, not for every element at least. That
>> would cause a lot of problems.
>
> Can you elaborate on this?

See above: you cannot focus (and thus you cannot check) every element on a page.

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

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

> ~TJ
>

Giovanni

Received on Thursday, 23 April 2009 15:16:22 UTC