WD-css3-userint-20000216 comments

User Interface for CSS3 <http://www.w3.org/TR/2000/WD-css
3-userint-20000216>



1.3 Summary of Additions <http://www.w3.org/TR/2000/W
D-css3-userint-20000216#summary>

"The proposal can be briefly summed up by the following 
additions to CSS:"

Change to "The following additions to CSS summarize this proposal."



1.5 Issues <http://www.w3.org/TR/2000/WD-css3-userin
t-20000216#issues>

"1.	Should this proposal attempt to address more of the behavior 
of FRAMESET and FRAME, specifically the ability to 
"share" resizability when elements share a border (i.e. with 
border-collapse for example)?"

No.

"2.	Using "attr()" outside of the content property. In the 
default style sheet additions at the end of this document, one of 
the rules is: SELECT[size] { height: attr(size)em; } in order 
to attempt to have a SELECT element that has a size attribute 
be vertically sized as a multiple of its font-size. Should we 
discuss additional usages of the attr() expression in this proposal?"

No.  The gains are marginal in contrast with the 
hoop-jumping needed to make the notation fit into CSS.

"3.	key-equivalent conflicts. what happens when two or 
more elements have the same key-equivalent? what happens 
when an element has the same key-equivalent as some portion 
of the UAs intrinsic user interface?"

The result depends on the user agent.  In the case of 
multiple elements with identical key-equivalents, I suggest that 
the first element activate.  In the case of conflict with the 
intrinsic user interface, I suggest that the user agent ignore 
the document's key-equivalent.  This at least provides 
consistency and maintains user control.

"4.	Should we add additional pseudo-classes to be able to style 
an element based upon it's modifiability? E.g. :read-only, 
:read-write, :write-only."

Unless somebody has a compelling case, no.

"7.	Do we need to allow more control for the author to 
distinguish between what happens when a user interface element 
is focussed by the user, and when a user interface element 
is activated by the user? ... Any property solutions to this 
issue should resolve what the default value of the property is for 
the SELECT and OPTGROUP elements in order to 
correctly reproduce typical behavior for those elements in 
HTML4 user agents - something like "user-active:select-menu;"."



"8.	Should we include a :hot-key (or similarly named) 
pseudo-element selector which selects the character or 
characters in an element which are the same as any 
key-equivalents on the element?"

Yes.  The choice of which characters constitute the 
pseudo-element should be user agent dependent.  Support for 
this pseudo-element should be optional.

"9.	Should we add selectors for scrollbars? E.g. 
:horizontal-scrollbar, :vertical-scrollbar ?"

No, no, no.  Scrollbar styling is a can of worms best left untouched.


2.1.5 The :indeterminate pseudo-class <http://www.w3.org/T
R/2000/WD-css3-userint-20000216#pseudo-indeterminate>

"Radio and checkbox elements can be toggled by the user, but 
are sometimes in an indeterminate state, neither checked 
nor unchecked. This can be due to an element attribute, or 
DOM manipulation."

I fail to understand.  What attributes or DOM manipulations 
could leave an element in an indeterminate state?



2.2.1 The :selection pseudo-element <http://www.w3.org/T
R/2000/WD-css3-userint-20000216#pseudo-selection>

"This pseudo-element should not be confused with the 
:checked pseudo-class (which used to be named :selected) or 
the :selected pseudo-class in the Selectors Proposal."

The Selectors draft, WD-css3-selectors-20010126, contains 
no ':selected' pseudo-class.  Eliminate the reference.



3.2 @preference <http://www.w3.org/TR/2000/WD-css
3-userint-20000216#at-pref>

"The only property currently defined for the @preference rule 
is "media" "

Are other properties in the works?  If not, let us simplify 
the syntax:

@preference <medium>+;



4.3 font (extensions to CSS2 18.3) <http://www.w3.org/TR/200
0/WD-css3-userint-20000216#font>

"there is a specific fall back mechanism for UAs or platforms 
which do not support all the specific user interface elements."

Yet the font fall-back mechanism is barely described.



4.5 display <http://www.w3.org/TR/2000/WD-css3-userin
t-20000216#display>

"div.field {
 color: fieldText;
 background: field;
 border: fieldBorder;
 font: field;
 display: inline-block;
 user-modify: read-write;
 user-select: text;
}"

Change "border: fieldBorder" to "border: fieldBorder solid".



4.6 content <http://www.w3.org/TR/2000/WD-css3-userin
t-20000216#content>

"New Values:	normal | <uri>"

The <uri> notation is not new; it was in CSS2:12.2.



5.1 resizer - counterpart to overflow: scroll 
<http://www.w3.org/TR/2000/WD-css3-userin
t-20000216#resizer>

"Currently it is possible to control the appearance of the 
scrolling mechanism (if any) on a window using the 
overflow property (overflow: hidden) on the HTML (root) element."

The settings on the root element should affect scrolling 
mechanisms of the box of the root element and should not 
affect scrolling mechanisms of the window.  The fact is that CSS 
has no direct way to influence window widgets (except for 
widgets which are themselves renditions of elements in a 
structured document, as in Mozilla).



5.2.1 Key equivalents: the 'key-equivalent' property 
<http://www.w3.org/TR/2000/WD-css3-userint-20000216#ke
y-equivalent>

"A <key-press-combination> is one or more characters with one 
or more modifier keys separated by dashes ('-')."

There is no provision for the specification of a dash 
(hyphen-minus) as a key.  Further, this syntax is difficult 
to reconcile with the lexing scheme of CSS.  A 
<key-press-combination> will likely come out as a 
haphazard sequence of identifiers, operators, numbers, and 
lone characters.

"The characters must be specified in uppercase or as entities - 
the actual user input for the key-equivalency is case insensitive. 
In addition to characters (representing keys), special or 
modifier keys can also be specified. These are specified in 
all lowercase so as to be distinguished from the 
characters representing keys."

CSS has no "entities"; CSS has character escapes.  
The requirements for uppercase and for lowercase violates 
CSS's principle of internal case insensitivity.

We can eliminate the foregoing problems with 
<key-press-combination> by adopting the following syntax.

<key-press-combination> = [ <string> | attr(<identifier>) | 
<identifier> ]+

Here we decree that the <string> and 'attr()' forms represent 
a corresponding key while the <identifier> form names a 
modifier key.



5.2.2 Tabbing order: the 'tab-index' property 
<http://www.w3.org/TR/2000/WD-css3-userint-20000216#ta
b-index>

"Values: auto | <number> | inherit"

Missing is "attr(<identifier>)", a notation that is used in the 
sample style sheet.



5.3.4.1 Focus selection behavior of the contents of an element 
via keyboard input: the 'user-focus-key' property 
<http://www.w3.org/TR/2000/WD-css3-userin
t-20000216#user-focus-key>

"The purpose of this property is to determine what happens to 
an element when the user focusses it specifically by clicking on 
it with a pointing device."

Should read "The purpose of this property is to determine 
what happens to an element when the user focusses it specifically 
by "tabbing" into it.".



5.3.4.2 Focus selection behavior of the contents of an element 
via pointing device: the 'user-focus-pointer' property 
<http://www.w3.org/TR/2000/WD-css3-userin
t-20000216#user-focus-pointer>

"The purpose of this property is to determine what happens to 
an element when the user focusses it specifically by "tabbing" 
into it."

Should read "The purpose of this property is to determine 
what happens to an element when the user focusses it specifically 
by clicking on it with a pointing device."

Received on Friday, 30 November 2001 22:16:28 UTC