W3C home > Mailing lists > Public > www-style@w3.org > August 2003

Re: I18n review of CSS3 Basic UI

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 13 Aug 2003 08:32:41 +0000 (UTC)
To: Richard Ishida <ishida@w3.org>
Cc: "www-style@w3.org" <www-style@w3.org>, "'i18n'" <w3c-i18n-ig@w3.org>, Bert Bos <Bert.Bos@sophia.inria.fr>, Tantek Çelik <tantek@cs.stanford.edu>
Message-ID: <Pine.LNX.4.56.0308130755030.14872@dhalsim.dreamhost.com>

On Tue, 12 Aug 2003, Richard Ishida wrote:
> http://www.w3.org/International/2003/css3basicui/css3basicui-feedback.html

This isn't an official reply from the working group, but since our Editor
for the UI specification is on holiday, I thought I'd give you a quick
reply to some of your comments:

> 1: 8.1 pointer: we assume that directional mirroring of the pointer
> for middle eastern platforms is taken care of by the platform
> itself?

The system-defined cursor types may be rendered as the OS wishes. Note
that the 'pointer' type is typically rendered like a hand; you are
probably referring to the 'default' type which renders like an arrow
on most platforms.

Cursors specified as URIs would not be mirrored.

I don't think anything needs to be added to the spec for this, as the
spec already implies the above.

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

I am not sure what you mean.

> 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

This spec does not define the events related to 'key-equivalent'. A
future draft from the working group currently in development will
probably cover this. (The intention is that this UI spec can be
implemented in a resource-limited, DOM-free environment, while a
separate spec will define the DOM and dynamic aspects.)

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

I will let Tantek reply to these issues.

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

This should indeed be defined. It is the wrong syntax, too. Probably
an editorial oversight.

FYI it should be:

   attr(<attribute>, key-equivalent);

...or some such, and results in the specified attribute being parsed
as a key-equivalent value.

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

I will let Tantek reply to these issues.

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

nmstart will be defined in the CSS3 Syntax module. It incluse most
(all?) characters above U+000FF.

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

I will let Tantek reply to this issue.

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

I imagine that UA-discretion should be allowed. This may also be good
feedback for the CSS3 Lists or CSS3 Generated and Replaced Content
modules; maybe they should define exactly what 'list-item-marker'
matches or means.

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

They are available in the latest CSS3 Lists module:


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

In theory it extends CSS3. The reason for the ambiguity is that the
relevant modules that it is extending don't yet exist. In practice,
some of the values and properties mentioned in this spec will
eventually be transferred to more approriate specifications when they
reach the WD stage.

In the meantime, you may assume that this module extends CSS2.

(CSS2.1 is merely a revision of CSS2 (albeit a substantial one).)

> 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

I will let Tantek reply to these issues.

Thanks for your feedback!

Ian Hickson                                      )\._.,--....,'``.    fL
"meow"                                          /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 13 August 2003 04:30:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:08 UTC