Re: UI WD (was Re: BeCSS)

From: Matthew Brealey <webmaster@richinstyle.com>
Date: Tue, May 2, 2000, 3:02 PM

> 1. The cursor names should be without hyphens for consistency -
> contextmenu, not context-menu.

The whole hyphenation issue has been raised to higher level, since it is a
cross-working group issue.  The Hypertext Coordination Group (HCG) is
looking into this.

For now, I will leave the cursor names with hyphens, because that is the
direction it seems most are leaning.

> 2. For activatable elements, the :active period is not the same as the
> CSS definition of :active in most UAs. For example, once buttons have
> been 'pressed', they should have an outline. This persists until any
> other part of the document is clicked on.

The outline you are seeing is expressing :focus.

> 3. I would also question this:
>
> 'For replaced elements the content which replaces the element determines
> the user-select, which is why this property does not apply. For example,
> the user-select of an IFRAME is determined by the selection style of the
> HTML document inside.'
>
> Although this is certainly true for content replaced by stylable
> documents, it is not true for example for P {content: "Hello"}, where
> the replaced content does not specify anything about the user-select of
> the P element. In fact, user-select should apply to all elements; the
> IFRAME example is something of a red herring since the HTML document
> inside implicitly overrides the user-select anyway (in the same way as
> specifying FRAME {color: red} has no effect because the HTML element
> inside the FRAME is the root of the document tree and therefore cannot
> be styled by any previous elements). (Typically replaced elements such
> as images will have user-select: none, but this a style sheet setting,
> not an implict one).

Good point.  "overrides" is more accurate.  I have changed the text
accordingly.

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

> 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, however unlikely)

> If the property does survive, I would suggest that something be done
> about the following paragraph, which is almost incomprehensible:
>
> 'The self-nesting is based on the principle that every element that has
> a 'group-reset' for a group X, creates a fresh group X, the scope of
> which is the element, its preceding siblings, and all the descendants of
> the element and its preceding siblings.'
>
> It appears to repeat itself: 'the scope ... is ... its preceding
> siblings ... and its preceding siblings'. (The second reference should
> be 'following siblings'.) The reading I have always taken of this (in
> CSS2) is 'Counter-reset only affects sibling and descendant elements' (I
> also don't think affecting 'preceding siblings' makes any sense, because
> preceding siblings cannot be affected anyway; 'following siblings' is
> the correct phrase), or even 'Counter-reset doesn't affect ancestor
> elements'. Replacing this paragraph with one that is more clear and with
> an example would be beneficial. Although incidentally I would be
> interested what real-world example could be provided.

The text was copied from the CSS-2 description for counter-reset, which, I
didn't want to deviate from, to avoid implying any different functionality.

> 6. It would also, I think, be useful for the UI WD to make some
> statement on styling FRAMEs and IFRAMEs (given that they aren't styled
> by CSS in current UAs):
>
> 'Although it is not possible to affect the styling of the contents of
> frames or inline frames (the FRAME and IFRAME elements in HTML), since
> any styles would be overridden as HTML (present in all HTML documents)
> is the root of the document tree, and therefore cannot inherit or be
> affected by any styles specified on the FRAME or IFRAME element, it is
> possible to style the frames themselves. For example, the scrolling
> attribute and its attributes is functionally equivalent to the overflow
> property. Similarly the "height" and "width" attributes of IFRAME are
> equivalent to the CSS properties of the same name.
>
> The exception to this is that because CSS does not use the same syntax
> as HTML for frames, no equivalent to FRAMESET's attributes exists
> (although equivalent functionality can be achieved using fixed
> positioning [*]).

Yes, this would be a worthy endeavor, to make sure that are able to fully
style the presentational functionality of FRAME,FRAMESET,IFRAME using CSS2
and CSS3 UI.

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

Tantek

----------------------------------------------------------------------------
Can I get the icon in cornflower blue? Absolutely.     microsoft.com/mac/ie/

Received on Wednesday, 16 August 2000 04:12:08 UTC