- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Fri, 01 Aug 2003 04:52:50 +0200
- To: tantekc@microsoft.com
- Cc: www-archive@w3.org
Hi,
These are my last call comments on the CSS3 Basic Unter Interface
Module <http://www.w3.org/TR/2003/WD-css3-ui-20030703>. I got the
strange feeling that I am not a member of the target audience or I am
just clueless. On the other hand, I expect less clueful people than me
to read the draft. The most important thing for a second last call
working draft or a candidate recommendation would be examples, at least
one for each new selector and each new property. I would have proposed
new text and new examples if I knew better how to interpret the draft.
I hope these comments are notheless useful and help to improve the
draft.
Please note that questions and "I do not understand"s are requests for
clarification in the draft. Sometimes a satisfactory clarification could
be as simple as stating that the specification does not define
<whatever>.
* Abstract
http://www.w3.org/2001/06/manual/#Abstract says that the abstract
should be written for a non-technical audience. The current abstract
is however extremly technical.
* Status of this document
See http://www.w3.org/mid/a0600182fbb3b692c9c4e@%5B10.0.1.2%5D
* Changes
If this section is kept in the next version of this document this
should be a non-normative appendix.
* 3. User Interface Selectors
None of the 13 new selectors have an example. Each selector should at
least have one example. It would be neat to have a more complex
example at the end of the section that demonstrates how various
selectors could be used together.
* 3.1. User interface states: pseudo-classes
The draft uses SELECT to mean the <select> element in HTML and
[SELECT] to mean a reference to the css3-selectors candidate
recommendation. This is rather confusing. A better name for the
reference would be [CSS3SELECTORS] or something similar.
...
Specifically, these new states (except for :default) are provided as
a way to style elements which are in the respective states as
defined by XForms [XFORMS10].
...
Up to this point XForms were not mentioned, the draft merely talks
about HTML 4. Is the draft meant to provide properties to style
XForms? Then it should say so in the abstract/status/introduction.
* 3.1.2. :valid and :invalid
...
An element is :valid or :invalid when it is, respectively, valid or
invalid with respect to the bound instance data constraints. An
element which lacks data validity semantics is neither :valid nor
:invalid. This is different from an element which otherwise has no
constraints. Such an element would always be :valid.
...
I don't understand the difference between lack of data validity
semantics and an element "which otherwise has no constraints". The
term "data validity semantics" is already confusing as neither css3-ui
nor XForms define a term close to it. Logically, an element either has
a notion of validity in which case the element can be either :valid or
:invalid depending on whether it matches the constraints or it does
not have a notion of validity in which case it either neither :valid
nor :invalid or always :valid. The draft says it's neither then. So
what's this about? There should be examples which demonstrate each
case.
3.1.3. :in-range and :out-of-range
...
The :in-range and :out-of-range pseudo-classes apply only to
elements that have range limitations. An element is :in-range or
:out-of-range when the value that the element is bound to is in
range or out of range of the visual representation of the element
respectively. E.g. a
...
Range of the visual representation? So this does not apply to aural
media or what?
...
slider element with a value of 11 on a slider that only represents
the values from 1-10 is :out-of-range. In summary: an element is
:out-of-range when it does not accurately reflect the state of the
model.
...
What model?
Is an element :out-of-range :invalid?
* 3.1.4. :required and :optional
...
A form element is :required or :optional if a value for it is,
respectively, required or optional before the form it belongs to is
submitted. Elements that are not form elements are neither required
nor optional. This spec does not defined what is a form element.
...
s/spec/specification/
I do not understand "before the form it belongs to is submitted". Are
elements :required or :optional before I hit the submit button? While
I press the submit button? After I've pressed the submit button? If
there are two forms in the document do :required and :optional apply
to form elements of both forms?
* 3.2. User interface element fragments: pseudo-elements
Are any of these pseudo-elements meant to be used in combination with
other pseudo-elements in this module or in other modules?
* 3.2.1. ::value
...
A form element may contain both a label for its data value, and the
data value itself. For such elements, the ::value pseudo-element
selects the representation of just the data value itself, in order
to style its appearance.
...
What if the markup language does not allow labeling form elements?
What if it does but the author did not specify a label? How is this
pseudo-element different from
xf|value { ... }
?
* 3.2.2. ::choices
I do not understand the need for this pseudo-element. In XForms you
have
<select>
<label />
<choices>
<item>
<label />
<value />
</item>
<item>
<label />
<value />
</item>
...
To select the choices one can easily use the element type name
selector
xf|choices { ... }
or probably
xf|choices > xf|item { ... }
or
xf|choices > xf|item::before { ... }
depending on what this pseudo-element is about.
...
A list of radio buttons can also be selected with the ::choices
pseudo, and the currently chosen radio button can be selected with
the ::value pseudo.
...
s/pseudo/pseudo-element/
I am lost here. ::value is said to select the representation of the
data value of some form element but nothing is said about the
currently chosen form element. Does ::value only apply to selected
data value representation?
* 3.2.3. ::repeat-item
...
The ::repeat-item pseudo-element represents a single item from a
repeating sequence. Its position is as a parent to all the elements
in a single repeating item. Each ::repeat-item is associated with a
particular instance data node, and is affected by the model item
properties (e.g. 'relevant') found there, as the related style
properties will cascade to the child elements.
...
I guess there is a missing reference to XForms in section 3.2.,
otherwise this model item property speak does not make much sense.
I do not understand what this pseudo-element selects. I would expect
foo::repeat-item
to select all foo element's repeat-item part but what is the
repeat-item part of an element? The prose says ::repeat-item selects a
single item from a repeating sequence. Which item? The first? The
last?
3.2.4. ::repeat-index
...
The ::repeat-index pseudo-element represents the current item of a
repeating sequence. Its position is as a parent of all the elements
in the index repeating item (and as a child to the ::repeat-item
pseudo-element), thus any style declarations applying to this
pseudo-element override those on the parent ::repeat-item.
...
I understand "current item" better than the "single item" of
::repeat-item and I understand the part on overriding declarations,
but I do not understand much more of this pseudo-element, especially
the term "index repeating item". What's this "index" about?
* 4.1. The 'appearance' property
I do not understand why this property does not apply to static media,
I think it is quite common to print forms with checkboxes and text
areas.
...
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. However, color
is not the only property for which native form elements have a
default.
...
s/values/keywords/
...
This document introduces the 'appearance' property. The 'appearance'
property simultaneously affects color, font, background, padding,
border, and margin (note: and perhaps others).
When the appearance property is specified, the value indicates not
only color, but all other aspects (font, background, padding,
border, and margin, etc.) that are determined by the look of
standard user interface elements on the system. Individual
properties such as 'background-color' or 'border-style' are still
given values taken from the system, which can be independently
varied.
...
s/and margin (note: and perhaps others)/margin and perhaps others/
It's odd that the various affected aspects are mentioned twice here.
I do not understand the last sentence. I understand that it is
intended that I can use
button { appearance: button }
button { border-color: green }
to get a button with green borders but I have trouble to understand
what "are still given values taken from the system" means. Does this
mean that setting appearance also sets color for example? That is, if
my system button color is green and
button { appearance: button }
is applied, the computed value for 'color' would be some green just if
I had specified
button {
color: green;
background: ...;
margin: ...;
padding: ...;
...
}
? If that's the case appearance has a major security issue, since I
would expect
foo { appearance: desktop }
to set
foo { background-image: url(file:///e:/winnt/...desktop-image.bmp) }
and it'd be much easier for an attacker to crack my system or steal
files if he knows the location of my system directory.
...
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:
...
The draft neither restates any of those lists nor are they referenced.
In fact, HTML does not have a list of "form elements" but rather has
"form controls". I do not understand how these lists and concepts
yield in the following that list of user interface elements.
Surprisingly none of those keywords is explained. I have for various
keywords no idea how those could render or are different from each
other. I also have trouble to understand the grouping. In Windows GUI
design almost anything is a window including buttons, menubars, menus,
etc.
I have no idea how appearance:hyperlink would look like on my system,
hyperlinks on the desktop have a different style than hyperlinks in
the Explorer and those are still different from hyperlinks in my
browser which are again different from the hyperlink styles used in
the Windows help system. I'd claim there is no system default style
for hyperlinks. Is it then the user agent default? My user agent
defaults for hyperlinks have colors but no background colors,
hyperlink-container { background-color: blue; color: black }
hyperlink { appearance: hyperlink }
is likely to get unreadable. How does css3-ui deal with this
situation? What are user agents or authors supposed to do to prevent
illegibility?
The prose for appearance does not state whether it only
affects properties for the element or also pseudo-classes,
pseudo-elements, etc. What's inside scope, what is outside? Does it
affect child elements? In which way?
Why are "info" and "message-box" "renamed"?
What is an "outline-tree"? Is this like Tree View Controls in Windows
GUI? Does it render lines linking the elements? Does the author have
control over it? Collapsed? Expanded? Are there CSS modules providing
useful properties?
What is a "list-menu"? Is this like List View Controls in Windows GUI?
Those ain't menus to me.
What is the difference between a pull-down-menu and a pop-up-menu?
What is 'field'? Is this more like <textarea> or more like <input> or
what? The sample style sheet implies it's like both but their
appearance is not even similar to me.
What color would I get if
element { color: green; appearance: normal }
is specified?
I am sorry but the description of the cursor property which has rather
small impact on rendering is twice as long as the description of the
appearance property which is said to have major impact on rendering.
There should be more definitions, more descriptions, some examples and
some sample renderings.
...
All UAs are expected to support rendering the appearance of the five
generic user interface elements: icon, window, button, menu and
field. If a UA or platform does not support a specific user
interface element (e.g. dialog), it may apply the values for the
respective generic user interface element (e.g. window).
...
s/UA/user agent/
Wrt conformance, what does "are expected" mean? What's the alternative
to the "may" in the last sentence? Ignore the property? Why is this
not a MUST or at least a SHOULD? How may a user agent not support
specific user interface elements if the operating system does? Is
appearance than optional for css3-ui conformance even if appearance
would be implementable on the user agents target platform?
How would I use this property to style a typical context menu like
+-----------------+
| Undo |
| Redo |
+-----------------+
| Cut |
| Copy |
| Paste |
+-----------------+
| Find |
| Find next |
+-----------------+
How to style the separators for example? If I assign "key-equivalent"s
to all the entries, how would I make the user agent to highlight e.g.
the 'u' in 'undo'?
* 4.2. System fonts
This font property is confusing. In CSS Level 2.0, 2.1 and css3-fonts
font: status-bar
is inherited and applies to e.g. the print media type, in css3-ui it
is not inherited and does not apply to print. If this is intentional,
there should be a description how a user agent is supposed to
implement both, css3-ui and css3-fonts.
In css3-ui the initial value is 'normal' which is not a legal value
according to the value grammar. The prose says all appearance keywords
are added, appearance:normal however is not. If this is intentional
the prose should say that it is omitted and either css3-fonts is added
as normative reference or the initial value must be changed.
...
The computed values for system font values are simply the value
keywords themselves.
...
Change "computed values" to "... value" or replace all with "specified
value". It's never been obvious to me that the computed value of
font: status-bar
is "status-bar" while the computed value of
font: normal
is undefined but I guess that's the intention and should be clarified
in css3-fonts.
I wonder why it doesn't just say
New values: foo | bar | baz
adds css3-fonts to the normative dependencies and keeps other fields
of the property database just as in css3-fonts. It'd be much less
confusing.
I do not think that all these new keywords for font add much value to
CSS. Using Windows 2000, all fonts I am able to configure are
typically set to either Tahoma or Microsoft Sans Serif (8pt) depending
on your theme preferences. Under my preferences all keywords would be
equivalent to
font-size: 8pt;
font-family: Microsoft Sans Serif;
Even if they were different, I can hardly think of a situation where I
would like to style something with the font settings of a button that
is no button. If there are great and important use cases, I would like
to read about them in the specification.
...
CSS2 introduced system font values as values for the shorthand
'font' property which have the effect of setting all the elemental
'font-*' properties.
...
Change "system font values" to "system font keywords" or "system
fonts".
Why is the "icon" keyword a link to the "icon" property?
The draft says, 'message-box' is included for compatbility with CSS
Level 2.0, the css3-fonts module doesn't. What does "for
compatibility" mean? Is this keyword deprecated and may be removed
from future specifications?
field
The specific font used in forms text fields (input or output).
s/forms/form/, no?
I do not understand why it is
font: status-bar
but
font: menubar
'menubar' should rather be 'menu-bar'. 'message-box' vs. 'checkbox' is
also odd.
* 8.1. 'cursor' property
...
Computed value:
If there are one or more <uri> values specified, and the UA finds
a <uri> that it is able to support (due to format, resource
availability etc.), then the computed value is that URI, fully
qualified, with optional <x> and <y> coordinates. If no such
supported <uri> value is found, or if none were specified, then
the computed value is the specified keyword value, or 'auto' if no
keyword value is specified.
...
Per the current grammar it is not possible to specify no keyword
value.
...
<uri>
The user agent retrieves the cursor from the resource designated
by the URI. If the user agent cannot handle the first cursor of a
...
With respect to conformance, what does "retrieves" mean? For example,
if the user agent performs a HTTP HEAD for the specified resource and
the server answers with a Content-Type the user agent does not
support, must the user agent still retrieve the resource? If the URI
ends in .png and the user agent does not support image/png resources,
may it ignore the resource even if it really is a image/svg+xml cursor
which the user agent supports? what steps must be performed to
determine whether a cursor resource can be handled? What if the
resource cannot be retrieved (unsupported protocol, offline browsing,
404, etc.)? It's probably up to the Values module to specify the
details here, currently however it only says "User agents may vary in
how they handle URIs that designate unavailable or inapplicable
resources" which would strictly speaking allow the user agent to
display a "broken cursor" cursor rather than choosing the next
specified cursor... Further, the term "URI" is inaccurate as e.g.
<http://www.example.org/cursor.svg#cursor> is a URI *reference* but no
URI in RFC 2396 terminology although the intention is to support such
references.
...
list of cursors, it should attempt to handle the second, etc. If
the user agent cannot handle any user-defined cursor, it must use
the generic cursor at the end of the list. The optional <x> and
...
There isn't necessarily a generic cursor at the end of the list,
"auto" is also permitted. I am actually a bit surprised "auto" is
allowed there, it'd make more sense to me if the value grammar was
something like "... | auto | inherit" and the generic cursor is
optional and if ommited and none of the url() cursors are supported,
auto is assumed. This would allow to specify
cursor: url(l33t.png);
and the user agent would choose what fits best in the current context
if l33t.png is unavailable. If authors are required to specify a
generic cursor they will likely choose a less appropriate one,
probably "default". It's rather unlikely that authors want to specify
a different cursor than "auto" (or what the user agent would choose
for "auto"), isn't it? It would of course be incompatible with CSS
2.0/2.1...
Why is using the first url() a MUST but the second/third/etc. url()
only a SHOULD? This seems to be inconsistent.
The value grammar requires <x> and <y>, if those are optional (as the
prose indicates) the grammar must be changed.
<dt>ns-resize | ew-resize | nesw-resize | nwse-resize
Missing <strong />.
...
default
The platform-dependent default cursor. Often rendered as an arrow.
...
Is there no better name for this keyword? To me, the default cursor
for a :link element is a 'pointer' not some kind of an arrow.
...
cell
Indicates that a cell or set of cells may be selected. Often
rendered as a thick plus-sign with a dot in the middle.
...
I've never seen this cursor with a dot in the middle. And if I did,
I'd probably mixed it up with something similar to 'all-scroll'...
...
vertical-text
Indicates vertical-text that may be selected. Often rendered as a
horizontal I-beam
...
s/beam/bar/? add a full-stop.
I miss a keyword to specify no cursor at all, i.e. "none" or "hidden",
I've seen some requests for the ability to hide the cursor for example
in presentation scenarios. The typical advise is to create an invisble
cursor image which shoudn't be necessary. Users or user agents that
like to avoid rendering invisible cursors can more easily ignore
cursor: none
than testing whether the external resource might yield in an invisible
cursor (consider an animated cursor with a long lasting invisible
second frame).
Please sort the <dl> in alphabetic order (except "auto" which should
precede the generic cusor keywords).
...
The UA may treat inapplicable values as 'auto'. E.g. on platforms
that do not have a concept of a 'context-menu' cursor, the UA may
render 'default' or whatever is appropriate.
...
With respect to conformance, what does "inapplicable" mean? If a user
agent supports PNG cursors with abitrary dimensions, may it treat a
1600x1200px PNG cursor as "inapplicable"? May it treat
a[href] { cursor: wait }
as "inapplicable"? Is "inapplicable" any different from "unsupported"?
* 8.2.1. Keyboard equivalents: the 'key-equivalent' property
That's IMHO a very bad name, common terminology would be "hotkey" or
"shortcut", this sounds more like "key aspect" and one wonders how an
element can be equivalent to a key. One gets used to the name after
some time but I think it's name is not obvious to casual authors.
Alternatives could go along
keyboard-shortcut
shortcut-key
activator-shortcut
keyboard-binding
accelerator-keys
shortcut
hotkey
...
...
Value: none | (<key-press-combination> )+ |
<system-key-equivalent> | list-item-marker | inherit
...
Round brackets are not allowed in the value grammar definition in CSS
Level 2.0.
...
Key-equivalents are active in a document only if an element inside
the document has the focus (e.g. this can include the <body>
element). This also applies to documents inside frames. The frame
must first acquire the focus before key-equivalents for any of the
elements of its document can be active.
...
Giving focus to a frame does not automatically give focus to an
element inside the document contained in the frame. I'd prefer to
omit frame discussion and describe this in terms of *:focus.
I do not understand the need for accesskey-attr(<attribute>), there is
attr() isn't it? Where is <attribute> defined and how does <attribute>
cope with namespaces?
...
One or more <key-press-combination>s separated by spaces. The user
agent is supposed to use all <key-press-combination>s which it finds
in the list which it and the platform is capable of supporting. In
some ways this is similar to the list of font families in the
font-family property.
...
Please avoid using symbols as words, "<key-press-combination>s" is
hard to translate into other languages.
...
A <key-press-combination> is one or more characters with one or more
...
"characters" is a link to HTML 4.01, this makes HTML 4.01 a normative
reference to the specification but it is not even listed as an
informative reference. I disagree that <key-press-combination> is a
character according to the definition in HTML 4.01. Please take care
that if this specification uses the term "character" it uses it in
accordance with the specification requirements in
<http://www.w3.org/TR/charmod/>.
...
modifier keys separated by dashes ('-'). Each character must be
specified in uppercase or as an escaped character (character entity)
...
Character Entity? ö and such? I do not understand why
"characters" must be specified in uppercase if it's case-insensitive.
May I use lowercase characters when using escapes?
...
- 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. The
...
And who needs that? Maybe authors should accept this as some
convention but I do not see a specific reason for user agent
requirements here.
I have trouble to understand various keys, for example fcn, rcl, snd,
bs, clr, sto, sysrq, and namemenu. Has this particular part of the
specification been reviewed by I18N and/or DI Activity?
All these key symbols should really be inside an additional <dl>.
I would prefer if various shortcuts are separated by commas just as in
cursor or font-family.
I whish I could use in my user style sheet to allow some shortcuts but
disallow others. All I can do to prevent unexpected user agent
behaivour is to disallow any change to "key-equivalent".
* 5.2. 'icon' property
Does this property not have an "inherit" value? It's odd that all
properties but icon list inherit as a value.
Why is the comma opertator not used to list multiple <uri> values just
like in e.g. the cursor property?
...
(<uri>)+
...
Why are these '(' ')'?
I think that p { display:icon } is a rather bad example, especially
for user style sheets.
* 5.3. 'box-sizing' property
I remember some discussion about adding margin-box and/or padding-box.
Has this been considered?
* 8.2.3. Directional focus navigation: the 'nav-up', 'nav-right',
'nav-down', 'nav-left' properties
This is more about expressing relationships between resources than
about presentation of or interaction with content. It seems like this
is reinventing <a rel=next ...> and <a rel=prev ...>, something like
<div id=prev><p>...</p><p><a rel=next href='#next'>next</a></p></div>
<div id=next><p>...</p><p><a rel=prev href='#prev'>prev</a></p></div>
#prev:focus a { key-equivalent: down }
#next:focus a { key-equivalent: up }
or whatever.
...
auto
The user agent automatically determines which element to navigate
the focus to in response to directional navigational input.
...
I have no idea how this should or could be implemented.
...
<target-name>
The <target-name> parameter indicates the target frame for the
focus navigation. It is a string and it cannot start with the
underscore "_" character. If the specified target frame does not
exist, the parameter will be treated as an empty string. The
keyword 'root' indicates that the user agent should target the
full window.
...
A string? Why not an identifier?
...
User agents for devices with keyboards with arrow keys may respond
to the four directional arrow keys (up arrow, right arrow, down
arrow, left arrow) by navigating the focus according to four
respective nav-* directional navigation properties (nav-up,
nav-right, nav-down, nav-left).
...
They may, so this is an optional feature? I don't want web site
authors to break keyboard scrolling in my browser. This property
is open to all kinds of abuse not to mention WAI issues. The draft
does not say anything about the purpose of the property or potential
use cases so what problem is this meant to solve? If there is no
compelling need for this property I suggest to remove it.
* Appendix A. Additions to the Base Style Sheet for HTML4
textarea,
...
{
...
white-space: nowrap;
...
}
...
textarea,
...
{
...
white-space:normal;
}
What user agent uses white-space: normal for <textarea>? I am pretty
sure that white-space:pre is much closer to current user agent
behaivour.
* Normative References
Reference to css3-color and XForms 1.0 were already outdated on
publication of this working draft.
* misc
* missing reference to RFC 2119
* some notes are "Note. ..." in green color, some are "Note: " in
black color. If there is no semantic difference between these kinds
of notes there should be a difference in style
* examples!
* examples!
* examples!
regards.
Received on Thursday, 31 July 2003 22:53:15 UTC