Re: Tabbed Interfaces in CSS

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

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?

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

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

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

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.

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

> 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

Received on Friday, 24 April 2009 05:20:08 UTC