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

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. How can this be expressed in
CSS? I propose an active-duration property, which would take the values
'activate' or 'persist' (or some better values); the former means
:active lasts as long as the activation period; the latter until the
user selects or clicks upon something else.

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

4. In addition, in the sample style sheet:

 toggle-group: attr(name);

is wrong: only radio buttons should have mutually exclusive toggling.

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

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.

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

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

* Would it be useful (or appropriate) for CSS to

Please visit Featuring:
MySite - offer your users customizable styles.
AlwaysWork style - style sheets that always work.
Browser bug table covering all of CSS2 with links to full descriptions.
Lists of more than 1000 browser bugs, plus demonstrations of each.
Websafe Colorizer - view all foreground colors with all backgrounds. 
CSS2, CSS1 and HTML4 tutorials.
CSS masterclass - how to write better style sheets.
CSS2 test suite with 5000++ tests and 300+ test pages.

Received on Tuesday, 2 May 2000 09:57:54 UTC