Re: I18n review of CSS3 Basic UI

Hello Richard,


I believe we discussed and resolved any of these issues that were
outstanding when we met face-to-face at the recent W3C all group meeting in
Mandelieu, however I couldn't find an email trail of those discussions, so I
wanted to make sure it was captured at least here.


In summary, I believe all your comments were accepted, and some (in
particular relating to key-equivalent) pointed out flaws serious enough to
cause reconsideration (dropping) of that feature for CSS3-UI.


In particular:


On 8/14/03 5:26 AM, "Richard Ishida" <ishida@w3.org> wrote:

> Hello Ian,
> 
> Thanks for these unofficial answers.
> 
> See some additions below...
> 
> RI
> 
> ============
> Richard Ishida
> W3C
> 
> tel: +44 1753 480 292
> http://www.w3.org/People/Ishida/
> http://www.w3.org/International/
> http://www.w3.org/International/geo/
> 
> See the W3C Internationalization FAQ page
> http://www.w3.org/International/questions.html
> 
> 
> 
>> -----Original Message-----
>> From: Ian Hickson [mailto:ian@hixie.ch]
>> Sent: 13 August 2003 09:33
>> To: Richard Ishida
>> Cc: www-style@w3.org; 'i18n'; Bert Bos; Tantek Çelik
>> Subject: Re: I18n review of CSS3 Basic UI
>> 
>> 
>> 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.
> 
> 
> 
> You are correct - I meant default.


Agreed.  Note that the draft specifically does not mention which direction
the 'default' cursor points.


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

Agreed.


>>> 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.
> 
> 
> 
> We have 'text' which may, as an example, be rendered as a vertical
> I-beam.  'vertical-text', in a similar scenario may be rendered as a
> horizontal I-beam. The difference is related to the direction of the
> text, but the direction of the text can be changed by altering the
> writing-mode or block-progression properties.  Note also that vertical
> text commonly includes short runs of horizontal text (tate chuu yoko).
> (Especially since I think that setting these latter properties is the
> only way to achieve vertical text) could we not automatically align the
> I-beam/cursor with those properties, rather than forcing the designer to
> change the cursor manually each time?

Agreed.  As we discussed at the plenary meeting, the 'text' cursor should be
able to automatically  change direction based on the text/context.


>>> 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.
> 
> 
> Looking at the current nmstart definition, I'm thinking it may be
> simpler for the reader to state what the characters that must be
> escaped.  At any rate, I would suggest a link or pointer to the location
> of the definition.
> 
> 
> 
>> 
>> 
>>> 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:
>> 
>  http://www.w3.org/TR/css3-lists/#non-repeating

Comments certainly accepted.

And as discussed in Mandelieu, due to the your and many other folks'
excellent disassembly of the key-equivalent feature and its flaws, it is
being dropped from the CSS3-UI CR and being sent back to the drawing board
as it were.



Ian wrote:

> Richard wrote:
>
>> 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).)

Since CSS2.1 is now a CR, CSS3-UI CR will be updated accordingly to refer to
it.


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

Agreed.  The terminology will be clarified more, there will be better
definition of terms/references, and more pictorial examples.


> Thanks for your feedback!

Agreed.

Thank you and the whole i18n-ig as well again for your and the opportunity
to resolve the issues during the recent Mandelieu plenary.

Your input and feedback has certainly improved the CSS3-UI CR draft.

Regards,

Tantek Çelik
editor, CSS3 Basic UI module

Received on Wednesday, 5 May 2004 01:59:45 UTC