Re: UI WD

From: Matthew Brealey <webmaster@richinstyle.com>
Date: Wed, May 10, 2000, 11:25 AM

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

I understand - I intended to reply sooner ;-)

<snip>

> element
> The whole of one child element at a time can be selected.
>
> and similarly for 'elements'.

yes, your interpretations are correct, and your suggestion of rewording the
value descriptions is a good one.

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

"entire" seems redundant with "as a whole" - but other than that, yes, the
wording can be improved.

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

This is very close, however needs a slight modification.

"Only the element's contents as a whole can be selected."

There is a fine distinction (at least visually, and perhaps otherwise)
between an 'element as a whole' and the 'element's contents as a whole'.
(e.g. some might consider the border of an element as part of the element,
but certainly an element's border is not part of its contents.)

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

Agreed.

> 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

_USER_ selectability

>(selecting
> elements is suited to selectors;

nice pun. heh.

> 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}?

because the interaction/relationship that is described is _among_ those
child elements and not particular to any one of them in particular.  Thus,
being among the children, the property belongs to the parent.

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

Actually, the element itself has no control over that, rather, its parent
controls whether or not the element is selectable in its parents content
model.

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

Not true.  They themselves will be selected.  However, were you to try to
select their contents you wouldn't be able to.

The first sentence of the definition of 'user-select:none' helps make this
clearer:

 "None of the element's content can 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,

Correction: The whole of the element's _content_ 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.

Clicking anywhere inside ELEM results in no selection due to the
user-select:none.  However, clicking anywhere inside ELEMENT results in the
entirety of

 Some <ELEM>text</ELEM>

being selected due to the user-select:all.

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

It seems the central confusion here is the applicability of the user-select
property.

It applies to the _inside_ of an element, not to the element as whole, nor
to how the element behaves from the outside.

Hence, setting the user-select property on an element has _no_ affect on its
selectability from the outside.

> Finally, for the generated menu how do we specify that each item is
> selected by hovering over it?

I think this depends upon the user interface conventions for the specific
platform, as for some it is when each item is :active and for others, when
it is :hover.

> It appears that this is not specified, but
> it is certainly fundamental to the nature of the menu.

I would like to specify it, but not in such a way as to contradict the
conventions for the platform.

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

Popular platforms have several methods of selection, as you have described.
And all of these methods can be used to select the various different
chunks/content-models.

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

<snip>

An interesting idea.  I am not convinced that it is necessary nor
necessarily desirable, as it may limit the selectability of an element to a
particular method, which may harm accessibility - e.g. 'drag' would prevent
keyboard selection via some arrow-key and shift-key combination.

> Incidentally, the changes I propose are entirely compatible with current
> implementations; AFAICT, only user-select: none is currently being used.

Interesting.  I wasn't even aware of any current implementations.  Which
implementation are you referring to?

> [note that the proposal (for
> user-focus) uses the term 'shortcut', which is incorrect;

Good catch - thanks.  Yes, there are keyboard and file 'shortcuts', and
'short-hand' properties.  Clearly when using both terms in the same document
it was easy to mix-up their usages.

> as is
> 'Initial: auto' - the initial value is not defined for shorthand
> properties;

Another good catch.

> 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]

This is not entirely correct.  It is intentional that only one value can be
set on the user-focus property.  If there are additional input methods
beyond pointer and key, the user-focus property covers those as well.

From css3-userint definition of user-focus:

"This property serves as both a shortcut property that sets the values of
the individual user-focus-key and user-focus-pointer properties, and also
serves to determine what happens for any other input methods not covered by
user-focus-key and user-focus-pointer."

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

The :checked rules are unnecessary because the :before { content: checkbox }
is a state dependent rule and handles the :checked case.

<snip>

> Appendix A: other issues
>
> 1. how can one specify that an element has the focus already?

This is a challenging problem to solve, as you have to deal with either
document-wide single focus issues, and/or multi-focus handling.  And even
system-wide focus issues, which brings in multiple-window handling etc. - a
whole slew of issues we have not yet begun to solve in CSS.

> (not focussed, as used in the spec, because focused
> is the more common spelling).

Sounds reasonable.  I found two occurrences of focussed and changed them to
focused.

> 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?

Not sure - let me think about that one.

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

I agree there may be issues.  I think we need some level of experimental
implementation before we can really proceed though.  If something is
missing, it is not entirely clear what is.

> An issue I mentioned previously
> is matching the menu to the UI - should it be pop-up or pull-down?

Is this strictly an appearance issue, or are there functional differences in
your opinion?

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

That, at least, is handled by key-equivalent.

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

I believe 'user-select:text' handles this.

> 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? */}

I believe I have the necessary declarations in the current draft I am
working on.

> 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?

Example?

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

Mine too.  Though maybe its the thinned oxygen on the plane.

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

Interesting.

> Appendix B: sample style sheet
>
> /* I might send one in later */

Cool. Eagerly awaiting...

> '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'
<... and more grammatical tweaks>

yup.

In general I'd like to nail all the functional aspects first before doing
grammatical tweaks/edits, which may get tossed when functional aspects are
changed.

Thanks for the feedback,

Tantek

----------------------------------------------------------------------------
Single-serving sugar, single-serving cream. http://www.microsoft.com/mac/ie/

Received on Wednesday, 16 August 2000 04:12:07 UTC