Comments on http://www.w3.org/TR/2003/WD-css3-ui-20030703 provided by Richard Ishida on behalf of the I18N WG.
Item | Section | Our comment | Response | Further comments | RT |
---|---|---|---|---|---|
1 | 8.1 | pointer: we assume that directional mirroring of the pointer for middle eastern platforms is taken care of by the platform itself? | |||
2 | 8.1 | vertical text: shouldn't this happen automatically based on the direction of the text? Note that scripting can be used to alter the direction (see eg. at http://people.w3.org/rishida/scripts/samples/japanese.html - only works on IE). Even if styling is changed manually (eg. for translation) seems a pain to have to remember to switch the cursor too. | |||
3 | 8.2.1 | key-press-combination: If you have not already done so, please cross-check this against DOM events to ensure maximum coherence | |||
4 | 8.2.1 | key-press-combination: "Each character must be specified in upper case"
Why do you not allow a distinction between upper and lower case characters? What does the shift + key combination signify for, say, an English keyboard? Note that in a case insensitive approach, some language specific special casing will need to be taken into account, such as no single letter UC form of ß (goes to SS); same for French œ (OE); Turkish i, etc. Please clarify the relationship between particular Unicode characters and key codes. |
|||
5 | 8.2.1 | key-press-combination: "Each character must be specified in upper case"
Does this signifies a possible issue with languages that do not distinguish between upper and lower case versions but that nonetheless use the shift key to access additional characters. |
|||
6 | 8.2.1 | character [CN]
What does this mean? |
|||
7 | 8.2.1 | accesskey-attr(<attribute>)
We guess that this means you use the key defined by the attribute cited (eg. HTML's accesskey), but we don't see it defined. |
|||
8 | 8.2.1 | We think you have omitted the alt-graph key. Very common and regularly used on many keyboards. | |||
9 | 8.2.1 | Presumably 'caps' stands for 'capslock'? (Note that this is used like a shift or alt key for keyboards such as Hebrew - to access Latin keys - and Swiss German - to access additional keys) | |||
10 | 8.2.1 | Have you considered how someone using an IME (eg. for Japanese) would specify characters? Are there issues there? | |||
11 | 8.2.1 | non nmstart characters
It might be helpful to define nmstart - for example, we wonder if it covers letters from the non-ASCII Latin range and non-Latin scripts. (We would definitely hope you do not to have to escape all cyrillic, arabic, etc. characters.) |
|||
12 | 8.2.1 | I would suggest that you add an example that shows a sequence of three keys pressed simultaneously - this is quite common in non-English keyboards. | |||
13 | 8.2.1 | list-item-marker
For cjk numbers (often used in Japanese or Chinese) and Roman numerals, will the user be able to hit a european digit? If the key presses are case insensitive, will both a and A trigger the first item in an upper-roman list-style-type, etc? |
|||
14 | 8.2.1 |
[Note also in passing that it is very common in Japan to use circled numbers or diamond shaped numbers for list-style-types, but these don't appear to be available] |
|||
15 | general | One gets the impression that conformance to the specification involves conformance to an earlier version of
CSS as well. For example 5.1 display. It was not clear to us the extent of this dependency, and we also noted that this spec refers sometimes to the
CSS2 and sometimes tot he CSS2.1 specification. Are there issues where these latter two diverge?
Alternatively, is the dependency in 5.1 actually to another CSS3 module? If so, it may help to identify that module in 5.1. |
|||
16 | general | We are not sure that everybody will always understand the concepts and terms in the specification in the same way. We feel that the spec should be improved in a number of ways, which include the following. Better clarification of terminology, definition of terms, references to definitions/explanations of terms. We also feel that it would help a lot to include more pictorial examples. For example, the example in 5.2 adds little as is, but would add much if it showed one possible outcome of the rule. | |||
17 | 4.1 | para 2 and para 3 are very repetitious |
$Id: css3basicui-feedback.html,v 1.7 2003/08/12 18:38:59 rishida Exp $