W3C home > Mailing lists > Public > www-style@w3.org > May 2004

Re: I18n review of CSS3 Basic UI

From: Chris Lilley <chris@w3.org>
Date: Wed, 5 May 2004 20:56:45 +0200
Message-ID: <1811876267.20040505205645@w3.org>
To: (wrong string) Çelik <tantek@cs.stanford.edu>
Cc: Richard Ishida <ishida@w3.org>, Ian Hickson <ian@hixie.ch>, www-style@w3.org, 'i18n' <w3c-i18n-ig@w3.org>, 'Bert Bos' <Bert.Bos@sophia.inria.fr>

On Wednesday, May 5, 2004, 8:00:17 AM, Tantek wrote:


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

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


TÇ> Agreed.  Note that the draft specifically does not mention which direction
TÇ> 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.

TÇ> Agreed.

Just checking - so is it desirable for a cursor specified as a URI to
be mirrored, from an internationalisation perspective?

And would this be based on the directionality of the primary language
of the document or would the cursor flipback and forth while passing
over a set of nested bidi embeddings?


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

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

Again, is this desirable for the uri based ones as well? If I have a
fancy I beam-like cursor (with a text cursor fallback of course) is it
desirable that it rotate for vertical text? (I assume yes)


>>>> Please clarify the relationship between particular Unicode
>>> characters 
>>>> and key codes.

Isn't that already defined in DOM 3 Events,and can just be referred to
(even for a DOM-less implementation, it would use the same
definition).


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

DOM 3 Events already covers this case


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

I would be interested to read that disassembly, is it available?



-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group
Received on Wednesday, 5 May 2004 14:56:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:29 GMT