- From: Tantek Çelik <tantek@cs.stanford.edu>
- Date: Sat, 10 Apr 2004 23:48:22 -0700
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- Cc: <www-style@w3.org>
On 7/31/03 10:20 PM, "Bjoern Hoehrmann" <derhoermi@gmx.net> wrote:
>
> Hi,
>
> My comments can be found at
>
> http://lists.w3.org/Archives/Public/www-archive/2003Jul/0036.html
>
> regards.
>
From that URL:
> -----Original Message-----
> From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net]
> Sent: Thursday, July 31, 2003 7:53 PM
> To: Tantek Celik
> Cc: www-archive@w3.org
> Subject: [css3-ui] Last Call Comments on 3 July 2003 draft
>
>
> 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.
Understood.
> 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.
Agreed. That is reasonable. We will seek to add informative examples as
you requested, although for the sake of brevity, some examples may combine
one or more new selectors and/or one or more new properties where
appropriate.
> 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.
Agreed.
The Abstract will be rewritten to be more friendly, and the current Abstract
will be moved to a technical "Overview" section.
> * Status of this document
>
> See http://www.w3.org/mid/a0600182fbb3b692c9c4e@%5B10.0.1.2%5D
Note that informative profiles will be added to the CR draft, reflecting
known/expected/acceptable sets of features to be interoperably implemented.
> * Changes
>
> If this section is kept in the next version of this document this
> should be a non-normative appendix.
Agreed.
> * 3. User Interface Selectors
>
> None of the 13 new selectors have an example. Each selector should at
> least have one example.
Agreed.
> 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.
Agreed.
> * 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.
Agreed, this can be confusing. I have instead changed the references to the
SELECT element to specifically refer to HTML4 <code><SELECT></code>.
The [SELECT] reference to Selectors has already been used across CSS3
specifications and thus makes sense to keep as is.
> ...
> 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.
Disagreed. This is false.
XForms is mentioned in section 2:
"The following work is related to the CSS3 Module Basic User Interface
working draft.
* XForms [XFORMS10] "
> Is the draft meant to provide properties to style
> XForms? Then it should say so in the abstract/status/introduction.
Agreed.
>
> * 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.
Agreed.
> 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?
Agreed. It does apply to other media, and that will be clarified in the CR.
> ...
> 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?
Agreed. That sentence (starting with "In summary") was unclear (as you
indicated) out of context, and was redundant with what was already said, so
it is being removed.
> Is an element :out-of-range :invalid?
No.
> * 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/
Agreed.
> 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?
Yes. After.
> If
> there are two forms in the document do :required and :optional apply
> to form elements of both forms?
Yes.
> * 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?
No. pseudo-elements may only appear at the end of a selector (see
http://w3.org/TR/css3-selectors ).
> * 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 { ... }
>
> ?
If a form element consists of only a value, without a label, then yes,
::value would select the entirety of that form element.
> * 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.
Sometimes.
You can also have choices that are generated rather than enumerated.
::choices is necessary for the case where there isn't an explicit <item>
element for each choice, and also where there isn't an explicit <choices>
parent that groups all the <item>s.
> ...
> 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/
Agreed. Good catch.
> 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?
The selected or chosen form element *is* the value for menu or list for
example. Thus it makes sense and ::value selects it.
> * 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.
Agreed, there should be a reference to the proper XForms section there.
> 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.
Disagreed. It does not say "selects a single item".
> Which item? The first? The
> last?
A generated common parent of them. "Its position is as a parent to all the
elements in a single repeating item." This is so that inheriting properties
set on the ::repeat-item will inherit to the children (the items
themselves).
> 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?
Whichever is the 'current' item of a set of repeating items, according to
the user's perspective.
> * 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/
Agreed.
> ...
> 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.
Agreed. Yes, that was noticed and is being fixed.
> 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?
Yes.
> 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: ...;
> ...
> }
Yes.
> ? 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.
Disagreed. No, there is no security issue because the used values of color,
background etc. are not defined in the DOM, and even if they were, the used
values would be something symbolic like 'system-default', which would mean
something respectively different for each such property that was affected.
I will make a note of this so that implementations do not unintentionally
expose this information.
> ...
> 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.
Agreed. Hyperlink references have been added for those lists.
> In fact, HTML does not have a list of "form elements" but rather has
> "form controls".
Agreed. I will make the appropriate edits.
> 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.
Disagreed. No, in Windows GUI *coding*, those widgets all have a window
from a *programming* point of view. From a user's point of view obviously
they are not all windows since they cannot be arbitrarily moved around and
layered.
> I have no idea how appearance:hyperlink would look like on my system,
It is up to your 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.
Disagreed. Implementers have not found this to be the case. In the cases
you mention, the system has a default style for hyperlinks which is
customized slightly in some applications.
> 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?
It is up to each system how the system sets its preferences for hyperlink
appearance. The user agent should simply use the system's settings.
Authors can make an element appear as a hyperlink (including background and
foreground colors) by setting the property appearance:hyperlink.
> 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?
It affects the element on which it is set.
> Does it
> affect child elements? In which way?
The 'appearance' property itself is not inherited, though some of the
properties it affects (like 'color') may be inherited.
> Why are "info" and "message-box" "renamed"?
Because they were either too generic or did not follow typical user
interface naming conventions.
> What is an "outline-tree"? Is this like Tree View Controls in Windows
> GUI?
Yes.
> Does it render lines linking the elements?
That is dependent on the default outline-tree styling for the platform.
> Does the author have
> control over it? Collapsed? Expanded? Are there CSS modules providing
> useful properties?
The property setting display:none can achieve a collapsed like effect.
> What is a "list-menu"? Is this like List View Controls in Windows GUI?
> Those ain't menus to me.
A 'list-menu' is like a SELECT list.
> What is the difference between a pull-down-menu and a pop-up-menu?
The menus in a menu bar a pull-down-menus, and pop-up-menus are like SELECT
popus.
> What is 'field'? Is this more like <textarea> or more like <input> or
> what
Yes, <input> and <textarea> are both fields, with only minor differences
(number of lines (height), wrapping, scrolling).
> The sample style sheet implies it's like both but their
> appearance is not even similar to me.
In typical implementations they are very similar.
> What color would I get if
>
> element { color: green; appearance: normal }
>
> is specified?
green.
> 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.
Agreed that some more defining/describing text and examples would be useful
for the 'appearance' property.
> ...
> 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/
Agreed.
> Wrt conformance, what does "are expected" mean?
Agreed. It means "conforming user agents must", and text will be changed to
clarify this.
> What's the alternative
> to the "may" in the last sentence?
The first part of the sentence, that is properly implementing the values.
> Ignore the property?
No. Unless the user agent does not support the property at all.
> Why is this
> not a MUST or at least a SHOULD?
Because it is an alternative to the first part of the sentence. A user
agent MUST do one alternative or the other.
> How may a user agent not support
> specific user interface elements if the operating system does?
Perhaps it is limited by memory or perhaps it is in a small window, perhaps
it cannot depend on the user interface elements being supported by the
operating system and therefore it chooses to support only those that are
always there. There can be any number of reasons, and implementation
experience will tell us how necessary such an allowance is.
> Is
> appearance than optional for css3-ui conformance even if appearance
> would be implementable on the user agents target platform?
Yes, and this is perhaps true of any property in CSS3.
> How would I use this property to style a typical context menu like
>
> +-----------------+
> | Undo |
> | Redo |
> +-----------------+
> | Cut |
> | Copy |
> | Paste |
> +-----------------+
> | Find |
> | Find next |
> +-----------------+
>
First you would need to mark it up properly, and then you would use the
appropriate appearance value that you wanted.
> How to style the separators for example?
Perhaps with borders.
> 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'?
'key-equivalent' has been deemed too problematic as specified and is being
sent back to the drawing board to be redesigned.
> * 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.
Agreed. These differences were not intentional and are errors that will be
corrected.
Good catch.
> In css3-ui the initial value is 'normal' which is not a legal value
> according to the value grammar.
Agreed. That is also an error. The initial value is unchanged from
CSS2.1/3fonts.
> 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.
Agreed, 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.
Agreed. This change/clarification is no longer necessary when 'normal' is
removed from the initial value.
> I wonder why it doesn't just say
>
> New values: foo | bar | baz
Because some of the values are not new. Some of the values were already in
CSS2(.1).
> 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.
Agreed but with CSS2.1. The other fields will be made consistent with
CSS2.1
> 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.
Different systems have different levels of capability and richness. Such "I
can't think of a reason" arguments are insufficient to argue against a
feature.
The primary reason for the new keywords on the 'font' property is to be
consistent with the appearance property, instead of having two different
sets of user interface keywords for indicating system default styling.
> ...
> 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".
Agreed.
> Why is the "icon" keyword a link to the "icon" property?
Agreed. I am not sure, that is perhaps an accidental effect of the
post-processing script that the working group will have to look into.
> 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?
Agreed. You're right, the wording is confusing and unclear and should be
removed.
> field
> The specific font used in forms text fields (input or output).
>
> s/forms/form/, no?
Agreed.
> 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.
Disagreed. Both menubar and checkbox are typically single words in UI
literature and thus are not hyphenated.
> * 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.
Agreed. That is correct. Thus the ", or 'auto'..." will be removed.
> ...
> <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?
This wording is the same as in CSS2(.1).
> 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?
No, it seems reasonable that a HEAD request would be sufficient in that
case.
> 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?
Note that file extensions are not normative for determining type
information, and that all SVG user agents are required to support PNG.
> what steps must be performed to
> determine whether a cursor resource can be handled?
I suppose that is left deliberately vague.
> What if the
> resource cannot be retrieved (unsupported protocol, offline browsing,
> 404, etc.)?
Then, as it says, the next resource in the list should be attempted.
> It's probably up to the Values module to specify the
> details here,
Disagreed. No it is not. CSS3-UI does not normatively reference the Values
module because it is not far enough along.
> 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...
Disagreed. This is false since the Values module is not normatively
referenced, and the spec says:
"If the user agent cannot handle the first cursor of a list of cursors, it
should attempt to handle the second, etc."
Obviously the user agent cannot handle unavailable or inapplicable resources
and thus it should attempt to handle the following resource etc.
> 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.
Disagreed. This is an attempt to invent confusion where there isn't any.
The same use of URI is present in both the CSS2(.1) and SVG descriptions of
the 'cursor' property.
> ...
> 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.
Disagreed. 'auto' is a generic cursor.
> 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.
Disagreed.
There is no need to change the syntax in this regard, as it can be done like
this:
cursor: url(l33t.png), auto;
> If authors are required to specify a
> generic cursor they will likely choose a less appropriate one,
> probably "default".
Disagreed. Unlikely. They are more likely to choose 'auto'.
> 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...
Agreed, it would be incompatible with CSS2(.1), and therefore this change is
rejected.
> Why is using the first url() a MUST but the second/third/etc. url()
> only a SHOULD? This seems to be inconsistent.
Agreed, that SHOULD should be a MUST.
> The value grammar requires <x> and <y>, if those are optional (as the
> prose indicates) the grammar must be changed.
Agreed. '?' inserted after the closing bracket trailing the 'y' value.
> <dt>ns-resize | ew-resize | nesw-resize | nwse-resize
>
> Missing <strong />.
Agreed. Good catch.
> 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.
Disagreed. 'default' is a *platform* default cursor. Not a "per element"
default.
> ...
> 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'...
Here is one that I found on the web:
http://alt.cc/tnw/gr/cps.gif
Various spreadsheet programs on various platforms have used a cursor for
like this to indicate cell selectability.
> ...
> vertical-text
>
> Indicates vertical-text that may be selected. Often rendered as a
> horizontal I-beam
> ...
>
> s/beam/bar/?
Disagreed, I-beam is the correct term.
> add a full-stop.
Agreed.
> 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).
Agreed. Excellent suggestion.
> Please sort the <dl> in alphabetic order (except "auto" which should
> precede the generic cusor keywords).
Agreed partially.
There are so many cursors that I'm not sure that it makes sense to
alphabetically sort them all.
However, there enough values as to be confusing without some sort of
organization. I think it makes more sense to group them logically and then
use an alphabetical order within when appropriate.
> ...
> 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"?
It may.
> May it treat
>
> a[href] { cursor: wait }
>
> as "inapplicable"? Is "inapplicable" any different from "unsupported"?
Agreed. There is no difference. I'll change "inapplicable" to
"unsupported" to make it clearer.
> * 8.2.1. Keyboard equivalents: the 'key-equivalent' property
[key-equivalent related comments deleted]
Due to other Last Call feedback (including some of your feedback) the
'key-equivalent' property has been found to be too problematic to take to CR
without *major* changes. Therefore it is being dropped from CSS3 UI.
There is still a need for key-equivalent like functionality, and I encourage
you to contribute to the discussion when a revised design is proposed.
> * 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.
Agreed. I will add the 'inherit' value.
> Why is the comma opertator not used to list multiple <uri> values just
> like in e.g. the cursor property?
Agreed. I will change it to use the comma operator to list multiple <uri>
values.
> ...
> (<uri>)+
> ...
>
> Why are these '(' ')'?
Agreed, that is an error. I will fix this as part of editing the grammar of
the <uri> value to be a comma delimited list of one or more URIs.
> I think that p { display:icon } is a rather bad example, especially
> for user style sheets.
Agreed. It will be removed.
> * 5.3. 'box-sizing' property
>
> I remember some discussion about adding margin-box and/or padding-box.
> Has this been considered?
It has been considered and rejected due to the lack of a practical use cases
as compared to border-box and content-box.
> * 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.
Disagreed. This is about expressing a *presentational* relationship between
*enabled* (i.e. focusable) elements. Since the relationship is
presentational (two dimensional directions), it makes sense to capture this
in the same place as the rest of the presentation, namely, the style sheet.
> It seems like this
> is reinventing <a rel=next ...> and <a rel=prev ...>, something like
Disagreed. Directional focus navigation has nothing to do with rel="next"
and rel="prev", which are document-to-document relationships.
> <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.
Disagreed. The problem with using key-equivalent for this is that for each
focusable item there are potentially *four* different destinations to change
the focus to based on the navigation direction. Thus the example you gave
does not work for the purposes intended.
> ...
> 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.
Disagreed. There are already several implementations of possible "auto"
behavior for directional focus navigation, for example, the original WebTV
set-top-box which was introduced many many years ago.
> ...
> <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?
So as to not confuse keywords vs. names.
> ...
> 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?
Agreed that this is more confusing than it should be.
The feature is optional only so far as any CSS feature is optional.
I will reword the paragraph into a normative section (which does not define
the specific keys), and an informative paragraph which mentions the
possibility of using the arrow keys.
> 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.
Agreed. I will add a note about user agents allowing configuration of
directional navigation keys.
> 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.
Disagreed.
There has been a compelling need for this feature for quite some time.
There are various TV related standards that have attempted their own version
of it (e.g. DVB-HTML).
DVD navigation interfaces are also built with this kind of knowledge (how to
navigate the "focus" around a DVD interface, using the directional
navigation buttons on a typical DVD remote).
>
> * 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.
Agreed. white-space pre is closer to current user agent behavior for
<textarea>. Even closer is the CSS2.1 value white-space:pre-wrap.
Also, this entire appendix is informative and will be labeled as such.
> * Normative References
>
> Reference to css3-color and XForms 1.0 were already outdated on
> publication of this working draft.
Agreed. This will be fixed.
> * misc
>
> * missing reference to RFC 2119
Agreed. I will add an explicit conformance section.
> * 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
Agreed. They should all be marked up in the same manner such that the same
informative note styling is applied.
> * examples!
> * examples!
> * examples!
Agreed. Agreed. Agreed.
>
> regards.
Much thanks for such a thorough and comprehensive review. As you can see
(from having read this far in this response), there are numerous
improvements being made to the CSS3-UI Candidate Recommendation draft as a
direct consequence of this feedback.
Tantek Çelik
editor, CSS3 Basic UI module
Received on Sunday, 11 April 2004 02:48:28 UTC