- From: Matthew Brealey <webmaster@richinstyle.com>
- Date: Tue, 02 May 2000 15:02:29 -0700
- To: www-style@w3.org
- Message-ID: <390F5075.70D2@richinstyle.com>
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: input[type=checkbox][name], input[type=radio][name] { 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 http://RichInStyle.com. 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