WD-css3-ui-20020802 comments

Following are comments on the CSS3 module: Basic User Interface,
<http://www.w3.org/TR/2002/WD-css3-ui-20020802>.


2. Dependencies on other modules


"The following CSS3 modules depend on this CSS3 module:"

The List module should be repeated here.



4.1. The 'appearance' property


The 'appearance' property is actually a shorthand, setting all
properties (maybe excepting the positioning properties).  This
fact should be noted as such.


"Name: appearance
Value: normal | icon | window | document | workspace | desktop
       | tooltip | dialog | button | default-button | hyperlink
       | menu | pull-down-menu | pop-up-menu | list-menu
       | field | inherit
Initial: normal
Applies to: all elements
Inherited: no
Percentages: N/A
Media: interactive"


The applicable media are "visual", not "interactive".  If I go
to print, there still exists a notion of system window and of
its appearance.



5.1. 'content' property value additions


"<uri>
Replace the contents of the element with the contents of the URI
specified."

This description is too spare.  For instance, what happens when
the included content is plain text?  Is the included content to
be treated as though it had occurred in the document stream?  Is
the included content to appear embedded as a separate object?



6.1. Additional values for 'display' property


"icon
The element is replaced in its entirety by the resource
referenced by its 'icon' property, and treated as a replaced
element, visually formatted as an inline-block."

This is quite limiting.  The suggestion [1], by Bert Bos,
promoting any number of states for any element, is far more
worthy of exploration and inclusion.



6.2. 'icon' property


"Value:  auto | (<uri>)+"

I would like the list of alternatives to use the comma as
separator.  I recognize that operator semantics in the general
sense, apart from particular property definitions, are poorly
defined.  Nonetheless, it seems that comma delimits alternatives
(as in 'font-family') while whitespace delimits coexisting,
cohabiting, or contemporaneous things.


"A user could simply add a rule such as:
p { display:icon }
which would then render an icon in place of each paragraph."

The rule would also place consecutive paragraphs on a line with
each other, which the example leaves unstated.  Was this fact
recognized?



6.3. 'box-sizing' property


The 'box-sizing' property hinders multi-level style sheets. 
Consider the following rule set.

element {
  width: 25em;
  padding: 2em;
  border: solid 1em;
  box-sizing: border-box;
  }

In a CSS3 implementation, that is fine.  Implementations of
lower levels, however, will get a width that is more than 120%
what was desired.

I repeat now a suggestion that I once made: let's incorporate
the 'box-sizing' functionality into the 'width' and 'height'
properties themselves by means of an added keyword term in the
values.  The definitions follow.

Name: width
New values: [ <length> | <percentage> ] border-box
..

Name: height
New values: [ <length> | <percentage> ] border-box
..

To rework the preceding example in the new scheme, one would do
as follows.

element {
  width: 19em;
  width: 25em border-box;
  padding: 2em;
  border: solid 1em;
  }



7.5. 'outline-offset' property


"However, it is possible to offset the outline and draw it
beyond the border edge."

It is also possible, given that negative values are not
prohibited, to draw an outline within the border edge.  This
should be noted.



8.1. Overflow properties


"This specification recasts the 'overflow' property as a
shorthand property which sets the 'overflow-x' and 'overflow-y'
elemental properties."

I think that we should take a consistent approach to
horizontal/vertical control.  Either delegate elemental
properties to each axis or allow a pair of terms in the value
for a single property.  The latter is the approach taken with
'background-position', 'background-spacing' (in draft),
'border-spacing', 'resizer' (in this draft), and 'size'.  To
take the latter approach with element overflow, we could use the
following definition:

Name: overflow
New values: [ visible | hidden | scroll | auto ]
            [ visible | hidden | scroll | auto ]

This approach precludes inheritance for a lone axis.



9.1. 'cursor' property


Lacking here are the details of when the computed 'cursor' takes
effect.  If it depends on user agent, say as much.  I would
suggest that 'cursor' is effective while in ':hover' state,
however the user agent determines that.



9.2.1. Keyboard equivalents: the 'key-equivalent' property


The grammars are problematic.  The stricture on case is anathema
to the tenets of CSS.  And what if I want to indicate
hyphen-minus as a key?  Do I write "\-"?  Is a CSS processor
really going to distinguish between that and "-"?

Then there is the issue of special keys.  While I recognize the
need for interoperability, which the current specification
achieves through enumeration and definitions, I also recognize
the need for extensibility.  I suggest allowing extension
keywords to identify special keys not included explicitly.  Then
it will be the task of a separate registry to keep current
definitions for the special keys in use.

So I propose a simpler, more robust definition.  Let's use
strings to represent the characters that correspond to normal
keys, let's keep keywords for special keys, let's use whitespace
as the <key> separator, and let's use the comma as the
<key-press-combination> separator.  Incidentally, this makes
dealing with the "space" key more intuitive: it's simply " ". 
Grammars follows.

Value: none
       | <key-press-combination> [, <key-press-combination>]+
       | <system-key-equivalent>
       | list-item-marker

<key-press-combination> = <key>+
<key> = <string> | <special-key> | attr(<identifier>)
<special-key> = <modifier-key> | <function-key> | <navigation-key>
                | <edit-key> | <misc-key> | <extension-key>
..
<extension-key> = <identifier>

I made another change: the 'accesskey-attr()' notation is
shortened to the standard 'attr()' notation.  I do not
understand why the new notation was introduced; no explanation
is given.

Each of the special key keywords needs a prose definition; don't
worry, the definitions can be brief.

Should we include a mechanism to refer to keys by position
rather than by related characters or funtions?  For example,
should we allow 'key-22' or 'key(22)' to refer to a particular
position on the keyboard?


"<system-key-equivalent>
The author can also specify the system key-equivalent for a
particular command on that platform."

What happens when a system has no notion of the operation
referenced in a declared <system-key-equivalent>?  Is the
declaration ignored?  In that case, alternatives to the
<system-key-equivalent> should be allowed:

Value: none
       | <key-press-combination> [, <key-press-combination>]+
       | <system-key-equivalent> [, <key-press-combination>]+
       | list-item-marker

I want to note for the future that <system-key-equivalent>
should compute to <key-press-combination>.


"list-item-marker
Use the computed list item marker as the key equivalent."

What happens if the computed list item marker is a keyword like
'disc' or 'square'?  Is the 'list-item-marker' value then
equivalent to 'none'?



9.2.2. Sequential navigation order: the 'nav-index' property


"<number>
The number (which is non-zero and positive) indicates the
sequential navigation order for the element."

The notation <number> should be <integer>, yes?

To better model the HTML4 behavior, values of zero should be
allowed as specifying navigation after all positive indices.

We should add a value, 'none', to specify that the element
should not participate in navigation.


"Those elements that support the nav-index property"

What does it mean for an element to "support" a property?


"Those elements that do not support the nav-index property or
support it and assign it a value of 'auto' are navigated next."

'Auto' should compute to an <integer> or to 'none'.



Appendix A. Additions to the Base Style Sheet for HTML4


"input[type=reset]
{
/* default content of HTML4 input type=reset button */
 content: "Reset";
}

input[type=submit]
{
 appearance: default-button;
 content: "Submit";
}"

The selectors should have ":lang(en)" appended to indicate
English usage.


"select[size]:active
{
/* active SELECT with size>1 - appearance of active list */
 display: inline-block;
}"

Should this rule set have a 'line-height' declaration?


"img, object, applet, embed, iframe, frame, frameset
{
 display:inline-block;
}"

This fails to provide the expected behavior for frames.



Property index


Properties modified by this specification but for the most part
defined elsewhere should be in a separate table.  This allows a
distinction between "Values" and "New values".



[1]  Bert Bos.
"Re: list-style-type idea".
19 September 2002.
<mid:200209190441.04092.bert@w3.org> /
<http://lists.w3.org/Archives/Public/www-style/2002Sep/0147.html>.

Received on Monday, 7 October 2002 17:11:59 UTC