Re: Tabbed Interfaces in CSS

On Fri, Apr 24, 2009 at 10:51 AM, Giovanni Campagna <
scampa.giovanni@gmail.com> wrote:

> 2009/4/24 Brad Kemper <brad.kemper@gmail.com>:
> >[...]
> >
> >> 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.
>
> Actually, the first sentence is the result of the second: "I don't
> support your proposal because the UA would have to keep track etc."


I see. I wouldn't think that would be burdensome on the UA, but perhaps an
implementer can chime in about that.


> > [...]
> >
> > 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;
>
> There is one difference: the initial value (toggle in your proposal,
> text in mine and old User Interface for CSS3)


OK. And I am saying that being able to select text and being able to change
the checked-state on mouse-up do not need to be mutually exclusive. And so
'user-select' just complicates the grammar by forcing functional notation
instead of simple property:value. I like the simplicity of my syntax better,
and don't find the marginal benefits of having a 'user-select' property
instead to be worthwhile.


> > [...]
> >
> >
> >> 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.
>
> Well, if you don't like "user-select" you don't have to use it.


Its not that. Its that I don't think authors should use it to change the
behavior that users expect from their UI elements. People have expectations
of what should happen when they tab to a text field or pop-up menu, and any
author that screws with that is more likely than not just going to annoy or
slow down the user.



> >> 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.
>
> <input> is not as flexible as <span> in the content model


Agreed. That should be improved.


> > [...]
> >
> >> 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,
> >
> > Not much to me, so I probably wouldn't style anything based on that.
>
> But you would still have one.


I am not totally opposed to exempting form elements, since they already have
well-defined behavior and user expectations for how they should work.


> >> 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?
>
> An image with a pointing device over.


Hover = an image with a pointing device over
Checked = an image that's been put into a secondary state

So? I don't find one more meaningful than the other.


> It is different: you cannot
> check an image (you can activate, hover, select, but not check it)


Not now. But with my proposal you *could* check an image, because "checked"
just means that it is in a secondary state, and the author can use that
capability for whatever he wants. If an author might find it useful to have
an image display differently based on clicks to it or to its group-mates, or
to be able to query that secondary state via JavaScript, then I see no
reason to stand in the way. I think it could be very useful, even to someone
who wanted to "emulate [a certain form input] without HTML/XForms tags".


> > 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.
>
> This is just more syntax. The core of the proposal is yours. If you
> don't like it, it means that something is fundamentally wrong within
> it.


What I dislike about ':nth-activation(na+b)' has nothing to do with what I
proposed. I dislike it because it is longer, uglier, and more obtuse. And
because it only deals with checkbox-like state-tracking and not
radio-button-like state-tracking.


> >> 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.
>
> According to CSS2.1, to Selectors Level 3, to CSS3 Basic User
> Interface, to XForms1.1, to HTML5
> you can write
> :checked
>
> and expect it equal to
> xht|input[type=checkbox]:checked, xht|input[type=radio]:checked,
> xf|select1[appearance=full] > item:checked, xf|select[appearance=full]
> > item:checked


As it does today, no?


> Your proposal breaks this (without changing any of those
> specifications, that either CRs, LCWDs or WDs produced in different
> WGs)


I would not suggest that authors style based on naked or universal selector
after my proposal is implemented, any more than I would before its
implemented. But if they wanted to draw a blue outline around everything
that was in a checked state, then that would do it.

Even so, I can see the argument for exempting regular form controls from the
effects of 'radio-group'.