UI WD

[This was intended to be a short message....]

I don't think the user-select property is quite correct. In particular
three values:

element
One element at a time may be selected.
elements
One or more elements at a time may be selected.
all
Only the entire contents as a whole can be selected.

It took me quite a while to work out what 'element' and 'elements' mean
- these descriptions aren't of much assistance, and indeed I only
managed to work out what they meant from their use in the sample style
sheet [not, I think, 'base style sheet', as stated in the proposal]. It
appeared to me that they meant that one/one or more of the whole of a
descendant element(s) can be selected. But I soon realised that this was
not correct either:

<menu id="likeSelect" style="user-select: element">
<option>
Some text <span>and some text</span>
</option>
<option>
Some text <span>and some text</span>
</option>
</menu>

Clearly here it is not meant that SPAN should be selectable, and so by
induction we find that the intended meaning is:

element
The whole of one child element at a time can be selected.

and similarly for 'elements'.

The next problem I see is that the description of the 'all' value is
grammatically incorrect - it does not follow from the preceding
definitions: the intended meaning is:

'Only the entire contents of the element as a whole can be selected.'

The text omits the subject of the sentence ('the element'), which is
fine in general in this situation; however, the subject is implied by
the context (which, as we have seen, is 'child elements', not 'the
element'). In this case because the subject of the preceding sentences
is not clear, in fact the reverse tends to happen; I found that because
the meaning of 'element' and 'elements' was not clear I read on and
found that the next paragraph required that the context be the element
itself, which served to further obfuscate the previous definitions.

Having duly clarified the previous definitions, the 'all' definition
should instead be:

'Only the element as a whole can be selected.'

In addition, to use 'may' in 'One element at a time may be selected.' is
wrong (as it is in 'elements' too); correct would be 'can'.

However, there are bigger problems with the 'element' and 'elements'
values. A clear definition reveals that the values are specifying the
selectability of descendant (specifically child) elements (selecting
elements is suited to selectors; selecting boxes more to properties).
This strikes me as strange: we do not have child-color: red, so why
should we have these values (alternatively MENU > * {user-select:
all-exclusive /* This value means that the whole of the element can be
selected, but that it is the only thing that can then be selected */}
rather than MENU {user-select: element}? 

The larger problem is that by specifying the selectability of child
elements using the parent elements we are left with no way of specifying
that of the element itself; for example, for SELECT elements we need to
be able to specify that the element is not itself selectable (has
user-select: none), but have no way of doing so.

A wider issue is that of the effect of user-select: none on descendant
elements. Clearly the case of P {user-select: text} where P contains
user-select: none elements is simple - they just won't be selected. But
for 'element', 'elements' and 'all' there is a real issue:

Given that 'all' is defined by the requirement that only the whole of
the element can be selected, it would perhaps seem that <ELEMENT
style="user-select: all">Some <ELEM style="user-select:
none">text</ELEM></ELEMENT> cannot be selected. But I do not think that
this is so (ELEMENT certainly should be selectable). Under the
definition I propose, this is catered for, since the element as a whole
is selected, whereas under the present definition it is not, because it
requires that the whole of the contents be selected. Further, however, I
would suggest that a note to the effect that ELEMENT in this example is
selectable would be useful.

Secondly, what of MENU {user-select: element} OPTION {user-select:
none}? This is a cognate case: as explained, 'element' is almost the
same as 'all'. One could say that where the two collide OPTION wins, but
that in the case of <menu><option style="user-select: element">Text<span
style="user-select: none">text</span></option></menu> the SPAN can be
selected for the same reason as before.

Finally, for the generated menu how do we specify that each item is
selected by hovering over it? It appears that this is not specified, but
it is certainly fundamental to the nature of the menu. The problem is
that implicit in user-select is the concept of actual selection; e.g.,
clicking the mouse and dragging it, and as a result the proposal does
not address the issue of 'What is selection', which would be fine were
it not for the fact that the proposal uses several different concepts of
selection: the click and drag concept ('text'), the hover concept
('element' and 'elements'), the click concept ('toggle'), and the ?
concept ('all' - it depends on what you want this to mean.)

Consequently I propose a user-select-method property:

'user-select-method'

	Values: drag | click | hover | hover-key | inherit
	Initial: drag
	Applies to: all elements
	Inherited: no
	Percentages: n/a
	Media: interactive

This property specifies the process necessary for selection of the
element's content. 

drag
	This value means that the process necessary for selection of content is
the process in the UI corresponding to clicking the mouse and dragging
it to select an area of content. There is no requirement that this
actually be a dragging process; it is simply the process (or processes)
in the OS corresponding to this standard.

click
	This value means that the process necessary for selecting content is
the process corresponding to a single mouse click.

hover
	This value means that the process necessary for selecting content is
that corresponding to hovering over the element.

hover-key
	This value means that the processes necessary for selecting content are
those corresponding to hovering over the element or using the up and
down keys to select between elements (typically used for menus).

This property combines with the user-select-content property; for
example, P {user-select-content: all; user-select-method: hover}
specifies that hovering over a P element will select it. Similarly,
SELECT {user-select-method: hover; user-select-content: none} OPTION
{user-select-content: all} specifies the content selection method of
SELECT menus (note incidentally that specifying user-select-method:
hover on the OPTION would have the same effect).

Note that the effect of each value will vary with the situation. For
example, with user-select-content: text; and user-select-method: hover,
hovering over the element will select only one glyph at a time, whereas
with user-select-content: all, hovering over the element will select the
whole of the element. If an element has user-select-content: none, it
does not matter what value this property is sent.

The meaning of each value might depend on the situation. For example,
for for content with user-modify: read-write, it is typical to allow
shift+arrow keys to select content, and therefore the meaning of 'drag'
varies.
</end>

Incidentally, the changes I propose are entirely compatible with current
implementations; AFAICT, only user-select: none is currently being used.
And a user-select-content property, precisely equivalent to the current
user-select property. 

Plus:

user-select, a shorthand property [note that the proposal (for
user-focus) uses the term 'shortcut', which is incorrect; as is
'Initial: auto' - the initial value is not defined for shorthand
properties; as is defining values rather than using <'user-focus-key'>;
as is the terms in which it is defined - it should be:
[<user-focus>]{1,2} | inherit
, where if one is specified the other is given the same value (and they
are applied in the order pointer, key); as is Inherited: yes - it should
be 'no'; inheritance is via the longhand properties]

corresponding to these two properties:

'user-select'
	Values: [<'user-select-method'> | <'user-select-content'>] | inherit
	Initial: not defined for shorthand properties
	Applies to: all elements
	Inherited: no
	Percentages: n/a
	Media: interactive

And now it occurs to me that 'toggle' is redundant (and the current
proposal doesn't work for checkboxes or radio buttons at all, because
the sample style sheet doesn't include :checked). In fact the rôle for
which it is employed is one that is covered by the toggle-group
property. In terms of selection it is the same as user-select-content:
none. E.g.,

INPUT[type=checkbox] {content: checkbox}

INPUT[type=checkbox]:checked {content: checkbox-on}

But how do we decide whether the checkbox is checked? The proposal does
not address it, except, perhaps, through incorrect use of user-select:
toggle to mean that selecting it makes it checked (the user-select
property specifies whether or not (and how) the element can be selected,
not whether it can become checked). To achieve this there should be a
user-checked property:

'user-checked'
	Values: click | never | inherit
	Initial: never
	Applies to: all elements
	Inherited: no
	Percentages: n/a
	Media: interactive 

This property specifies whether the element can become checked. It is
used to allow 'sticky' changes to an element.

never
	the element cannot become checked; the :checked pseudo-class therefore
does not apply.
click
	clicking (or the equivalent) on an unchecked element makes it checked;
clicking on a checked element makes it unchecked,

If this property is set to 'click', clicking (or the equivalent;
typically the 'space' key is equivalent to a single click whereas the
'enter' key is equivalent to a double click) on the element makes it
checked. Whether an element is checked or not implies nothing about the
rendering of the element; however, its use is in such selectors as
INPUT[type=checkbox] {content:  checkbox-off}
INPUT[type=checkbox][checked] {content: checkbox-on} [should there be
:unchecked?].
</end>

[I use 'click' to allow future user events to be added; are any
immediately necessary?]

and a checked property:

'checked'
	Values: yes | no | inherit
	Initial: no
	Applies to: all elements
	Inherited: no
	Percentages: n/a
	Media: interactive 

The use of this property is to specify whether an element is checked by
default. For example, [checked] {checked: yes}

Note that the checked property has no effect unless user-checked is set
to click.

yes
	the element is checked
no
	the element is not checked

The 'checkedness' is affected by the toggle-group property in that a
property might become unchecked because the toggle-group means that
making one element 'checked' makes another one unchecked.

The checked property should be ignored on the :checked and :unchecked
pseudo-classes.
</end>

Afterword:

It seems to me that attr() is nicer than eval(attr()), so why not allow
both; the latter for cases where you wish to manipulate the result, or
where you want to use expressions of the form [title]:tooltip {content:
eval(attr(href)); content: eval(attr(title))}.

Appendix A: other issues

1. how can one specify that an element has the focus already? I propose
a focused property (not focussed, as used in the spec, because focused
is the more common spelling). As with checked, this would take values
yes or no. Is this necessary? Does the focus() method provide sufficient
functionality? Is this an area that CSS should deal with?

2. I still see problems with menus and CSS: serious problems exist here
as to how the element is selected - mouse activity is no problem, but
keyboard activity presents difficulties. An issue I mentioned previously
is matching the menu to the UI - should it be pop-up or pull-down?
Related to this is the key that pulls the menu down. If it's pop-up, it
is the up arrow, if pull-down it is the down arrow.

3. A 'select-here' value for <user-focus> is required (placing the text
insertion bar where the mouse is clicked).

4. The sample style sheet needs many more declarations (see Appendix B).
For example:

INPUT[type=text], INPUT {user-focus: select-here select-all /* Should
there be select-all-after and similar values; i.e., because the text
insertion bar is still there? Or is this just left to the UA? */} 

5. Issue 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? E.g.
you could style the hot-key for any enabled user interface element with
the following: :enabled:hot-key{text-decoration:underline}' What's wrong
with content selectors?

6. There are some outstanding issues relating to activation of elements:
should the activated element retain the focus? I propose a active-focus
property. This specifies whether the element gets the focus when
activated, and takes values of yes or no.

7. There are big problems relating to menus and keyboard activity, but
my head is starting to hurt :-( [*].

8. Finer control over pointers is needed to address even the rendering
of HTML pages, let alone the rather more possibility of building proper
windows and dialogue boxes using CSS properties (is this intended?). For
example, under normal circumstances the pointer type is dependent on the
element that it is hovering over, but when a SELECT menu is active, this
doesn't apply. Should this behaviour associated with the generation of a
menu, or should there be a specific means of controlling it (there are
other pointer issues, such as the fact that the pointer will vary
depending on where it is; e.g., in a word processor the pointer in the
left margin (of a left-to-right document) will change it, and also make
user-select: all)?

* I am starting to err on the side of automatic menu generation to cope
with the issues (e.g., different ways of doing menus, system-specific
menus; keyboard selection issues, etc.)

Appendix B: sample style sheet

/* I might send one in later */

Appendix C: miscellaneous grammatical errors

Section 2.1 of CSS1 and Chapter 18 of CSS2 introduced several user
interface related pseudo-classes.

Passim: use of 'which' as the restrictive (defining) relative pronoun,
whereas only 'that' is correct: 

The purpose of the :enabled pseudo-class is to allow authors to
customize the look of user interface elements which are enabled - which
the user can select/activate in some fashion (e.g. clicking on a button
with a mouse).

the first 'which' should be 'that'

The :checked pseudo-class only applies to elements which are
user-input:enabled or disabled. 

Should be 'that'

Although the :selection pseudo-element is dynamic in nature, and is
altered by user action, it is reasonable to expect that when a UA
rerenders to a static medium (such as a printed page) which was
originally rendered to a dynamic medium (like screen), the UA may wish
to transfer the current :selection state to that other medium, and have
all the appropriate formatting and rendering take effect as well. This
is not required - UAs may omit the :selection pseudo-element for static
media.

'which was' should be 'that which was'

'may' (which _only_ means 'is permitted to') should be 'might' in the
first case.

There is significant demand to be able to author content specifically
for this "mode" of interaction which can best be described as another
medium - presentation

'which' should be ', which' in non-restrictive (adjectival) clauses.

Presentation is different from projection, in that it does not imply
that it is rendered on a significantly larger screen (projection
typically does). 

The comma before 'in that' is redundant.

For example, content which was designed to be rendered as a presentation

'which' should be 'that'

'@ rule' is also used in several places instead of 'at-rule'

'If a UA supports more than one medium in the list, it should by default
use the first medium in the list which it supports.'

should be 'that it supports'

'CSS2 introduced the concept of system colors which is a set of values
that allows authors to specify colors in a manner that integrates them
into the user's graphic environment.'

'which is' should be ', which is'

'The proposal also recognizes that there may be other, platform specific
system colors which UAs may implement in order to permit authors to take
full advantage of the capabilities of that particular platform.'

the first 'may' should be 'might'; 'platform specific' should be
'platform-specific'; 'which' should be ', which'; 

'In addition, when the appropriate values are specified on the
'background' or 'border' shortcut properties, they behave similar to the
System Font values, in that, the value indicates'

'In addition, ' should be excised, because 'In addition' implies that
that the paragraph follows on from the previous paragraph, which it does
not.

The comma after 'in that' is also redundant.

'The list of CSS2 System Colors, the list of HTML4 form elements, and
the concept of a dialog window and an icon give us the following grouped
by category list of user interface elements:'

'list of user interface elements grouped by category' is more elegant.

'Each of these user interface elements has a number of subcomponents,
each of which is typically a different color in today's modern desktop
graphical user interfaces: background, text, and border which correspond
precisely to the CSS properties 'background', 'color', and 'border'.'

'which correspond' should be ', which correspond'.

'The following combinations of user interface element with subcomponent'

'subcomponent' should be 'subcomponents'.

'The CSS UI proposal defines a number of pseudo-classes or states for
user interface elements: enabled, disabled, active, and hover.'

What about focused?

'here are already applications which render their user interface
elements differently even when the user is simply hovering over them, as
such, it is not too great a leap to infer that future system standard
user interface elements may also render differently in the hover state.'

'which' should be 'that'

', as such, ' should be '; as such,'

'may' should be 'might'

'The above list of 42 system colors are expected to be rendered
differently depending on the user interface state of the element. This
provides the author a simple and straight-forward mechanism for building
user interface elements without having to construct rules for each
possible state.'

subject and verb keep changing in number; 'list' is singular, 'are' is
plural, 'This' is singular. It should be 'The 42 system colors are ....
These provide'

'straight-forward' is not hyphenated

However, to enable the author to define their own rules 

to use 'their' as singular impersonal is incorrect; 'his' is correct.

'However, to enable the author to define their own rules for the look of
specific states, for each of the above state independent colors'

the comma before 'for each' is redundant.

'Not all UAs or platforms may be able to support all 210 colors, so we
explicitly specify a series of fallback steps:'

'may' should be 'will'

'The color of the specific element as specified, e.g.
ActiveDefaultButtonBorder
The color of the generic element, e.g. ActiveButtonBorder
The state independent version, e.g. ButtonBorder'

', e.g.' should be preceded by ';' and followed by ','. E.g., '; e.g.,'
(equivalent to '; for example,')

'An example of a very simple UA on a 1-bit video (black & white only)
platform might for example, map all enabled border and text colors to
black, and all background colors to white. '

'for example,' should be 'might, for example,'; ', and' should be 'and'

'As with the extended system colors documented above, there is a
specific fall back mechanism for UAs or platforms which do not support
all the specific user interface elements.

The font of the specific element, e.g. dialog
The font of the generic element, e.g. window'

'which' should be 'that'; '.' should be ':' and ', e.g.' should be ';
e.g.,'.

Just as with the system colors, UAs are expected to support rendering at
a minimum the five generic system fonts:

PS. Even this doesn't go anywhere near resolving all the UI issues. And
I wouldn't like to implement it all.

PPS. Note that the 'all-exclusive' value is not in fact necessary; after
splitting the user-select property I see that user-select: hover-key all
does the trick because hovering is mutually exclusive.