Re: UI WD

Tantek Celik wrote:
> 
> 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 ;-)

That's ok. I've got messages from months ago in my 'todo' folder (and it
didn't help when I hit the reset button with my foot halfway through
replying to this :-().

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

Not my words.

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

True. But these subtleties aren't really highlighted in the current
draft. Elucidating examples for each would be nice. Or, preferably,
simplification of the whole draft (this has come full circle: when I
first considered this issue, I initially wen
 
> >(selecting
> > elements is suited to selectors;
> 
> nice pun. heh.

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

Possibly. I'll think about this again when the next draft is published.
 
> > 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 not clear enough for one as feeble as me.
 
> > 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.

Ok. But that's not terribly clear. A whole lot of extra explanation in
the doc would be nice. 

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

Examples/explanations in the draft please.

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

It certainly is. There is no way for a browser to guess, given a
primitive element, the appropriate selection process. 

> nor
> necessarily desirable, as it may limit the selectability of an element to a
> particular method,  which may harm accessibility 

Limitations are always necessary. To give an example, I installed the
wrong mouse driver on my Linux installation, which meant that everything
was effectively user-select-method: hover. Suffice to say I ended up
accidentally installing the wrong keyboard map, which meant I couldn't
use the system, and had to reboot with a rescue disk and restore
everything to normal: without the limitations my system was broken.

Without the functionality of this property, operating systems would not
work.

> - e.g. 'drag' would prevent
> keyboard selection via some arrow-key and shift-key combination.

OS already limit this. For example, to select a file an OS might require
you to click it, whereas hovering over it would be insufficient. This is
fundamental. There are not necessarily accessibility issues here.
 
> > 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?

That of Mozilla:

http://lxr.mozilla.org/seamonkey/source/layout/base/public/nsStyleConsts.h#80

(note that inclusion here is not conclusive evidence of support; see the
rest of the source if you're interested.)
 
> > [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.  

Or even 'shorthand'. Incidentally, on matters of pedantry, CSS-2/CSS-1
is not hyphenated; I was previously labouring under this
misapprehension, having never bothered to check, but if you actually
check you will find that the correct spelling is CSS2, and not CSS-2 as
you use.

> > 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.
 
Yes I see.

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

[see below.] Don't allow people to create their own GUI. Don't give
yourself a headache. Just use standard system components.
 
> > 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?

[later]
 
> > 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.

See previous post; this is a focused element behaviour issue, cf. a
'hotkey' issue.
 
> > 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.

[later].
 
> > 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.

I await it eagerly.

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

Did I correct myself subsequently? I thought so. It was a long time ago
however. 

I was misreading the CSS selectors draft, and was under the
misapprehension that one could select content.

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

Really?

But I do think so. Why? Two reasons:

creating controls from a primitive element inevitably means that people
will be forced to use things that aren't platform-familiar, which is
*bad* *bad* *bad*. One would not dream of hand-coding system controls
when creating an application, and to suggest that a web page or (horror
of horrors) a 'web application' should do so is bizarre.

there are quite a few issues that don't seem to be satisfactorily
resolved.

See http://www.iarchitect.com/mshame.htm for more UI issues.

> > Appendix B: sample style sheet
> >
> > /* I might send one in later */
> 
> Cool. Eagerly awaiting...
 
Oh yes. I'd have more time to spend on such delights if it wasn't for my
colleagues all desserting me (mmm: apple pie) for sunnier climes. Darn
them.

PS. I am not happy with the whole selection/focus situation, but am too
lazy to think about it at present. Will probably consider at some future
date.

-----------------------------------
Please visit http://RichInStyle.com. Featuring:
MySite: customizable styles.         AlwaysWork style 
Browser bug table covering all CSS2 with links to descriptions.
Lists of > 1000 browser bugs         Websafe Colorizer 
CSS2, CSS1 and HTML4 tutorials.      CSS masterclass 
CSS2 test suite: 5000++ tests and 300+ test pages.

Received on Wednesday, 16 August 2000 07:38:53 UTC