Re: Tabbed Interfaces in CSS

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

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

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

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

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

>> 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. It is different: you cannot
check an image (you can activate, hover, select, but not check it)

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

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

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

Giovanni

Received on Friday, 24 April 2009 18:16:12 UTC