W3C home > Mailing lists > Public > www-style@w3.org > April 2009

Re: Tabbed Interfaces in CSS

From: Giovanni Campagna <scampa.giovanni@gmail.com>
Date: Fri, 24 Apr 2009 19:51:11 +0200
Message-ID: <65307430904241051i61899278p565cf5e7c23383d7@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
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

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

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

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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:35 UTC