Re: UI WD (was Re: BeCSS)

From: Matthew Brealey <webmaster@richinstyle.com>
Date: Wed, Aug 16, 2000, 4:58 AM

>> > 4. In addition, in the sample style sheet:
>> >
>> > input[type=checkbox][name],
>> > input[type=radio][name]
>> > {
>> >  toggle-group: attr(name);
>> > }
>> >
>> > is wrong: only radio buttons should have mutually exclusive toggling.
>>
>> Not true.  I have seen checkboxes used this way as well.
>
> Possibly. But:
>
> this is an HTML style sheet, and this doesn't work in HTML: therefore it
> is absolutely wrong

a reasonable point.  yes the base style sheet's intent is to reflect
"typical" HTML presentation.

> in any case using checkboxes in that way is a bad idea and people who do
> it should be ashamed of themselves

not necessarily.  it is a matter of presentational style.  not every
variation is pretty, but certainly there are more "interesting" variations
than various HI design dogmas (guidelines) would have you believe.  our job
is to enable some amount of variation/diversity of interfaces, and allow
some amount of natural selection of better user interfaces over worse ones.

>> > 5. Finally, I am pretty confident that group-reset is superfluous. The
>> > toggle-group and group-reset properties are largely a restatement of the
>> > rules for counters, where the counter-reset property certainly was
>> > necessary (and possible).
>>
>> It is necessary for nested groups (which are possible,
>
> but are they desirable?

Ah, yes.  You can have a group of radio buttons which, have subgroups of
radio buttons inside them as well (think: different presentation of
OPTGROUPs and OPTIONs).

>> > Frame margins
>> > -------------
>> > The "marginwidth" and "marginheight" attributes (equivalent to the CSS
>> > 'padding' property) were originally intended to allow the author to use
>> > HTML to specify frame margins. Now that CSS provides equivalent
>> > functionality, these attributes should collapse with CSS margins. This
>> > means that if CSS margins are specified, the rendered margin is equal to
>> > the larger of the two: the CSS margin and that specified (or implied) on
>> > "marginwidth" and "marginheight".'
>>
>> Or you can treat the CSS specified margin as overriding these presentational
>> attributes, much as 'background-color' overrides 'BGCOLOR'.
>
> The analogy is incorrect. In a frame there are effectively two margins:
> that of the BODY, specified by the proprietary marginwidth/leftmargin,
> etc. attributes (or BODY {margin), and that of the frame. Thus in
> <iframe marginwidth=10> with inside <body marginwidth=10> gives a
> horizontal margin of 20 pixels. The question is whether one should adopt
> HTML's two-margin approach or else collapse or override them.
>
> The two-margin approach is nice in that it allows one to keep a padding
> inside a frame regardless of its content, but it is more of a pain to
> have to keep track of two separate margins.

You have to keep them separate, as they are on different sides of an object
boundary.  But that is easy enough - it is the distinction between the
'margin' property on FRAME vs. the 'margin' property on BODY (or HTML for
that matter).

Tantek

----------------------------------------------------------------------------
Remember to breathe.                        http://www.microsoft.com/mac/ie/

Received on Wednesday, 16 August 2000 09:18:11 UTC