W3C home > Mailing lists > Public > public-i18n-bidi@w3.org > January to March 2010

Fwd: Re: FPWD of Additional Requirements for Bidi in HTML

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 9 Mar 2010 10:46:49 -0600
Message-ID: <dd0fbad1003090846s4808c335ufa61a60bd983c169@mail.gmail.com>
To: public-i18n-bidi@w3.org
Forwarded from the public-html list at Ishida's request.

---------- Forwarded message ----------
From: "Tab Atkins Jr." <jackalmage@gmail.com>
Date: Mar 6, 2010 10:00 PM
Subject: Re: FPWD of Additional Requirements for Bidi in HTML
To: "Richard Ishida" <ishida@w3.org>

On Fri, Mar 5, 2010 at 5:29 AM, Richard Ishida <ishida@w3.org> wrote: > HTML
folks, > > Just to let ...
I'll comment on a few things anyway.  ^_^

Section 2.1: I strongly support this.  I've had to deal with
mixed-direction text in a translations webapp, and it's a huge pain
for precisely the reasons you cite in the document.  Being able to
specify a direction and ensure that it *only* works on the enclosed
element would be very useful.

Section 2.2: I highly doubt exposing the estimation algorithm to the
author is useful here.  I am 100% certain that virtually no author
will understand the significant differences between them, and be able
to provide an informed decision on the appropriate value.
Auto-detection is good (especially when combined with @bdi to limit
the damage), but all you should have to do is say 'auto'.

Section 2.1 and 2.3: I don't understand the reason why the attributes
accept "yes" and "no" values.  They both appear to be fully binary,
and so should use the standard idioms for binary attributes - lack of
the attribute is false, presence is true, valid values are the empty
string and the name of the attribute (though any value triggers 'true'
behavior).

Section 2.4: I like the idea, dislike the execution.  First of all,
the 'yes' value is entirely unnecessary and probably *harmful* to add.
 This feature is intended as a bidi feature; the 'yes' value as
currently specced will transform it into a general
image-transformation feature, and it *will* be abused as such.  That
is not what we want.  I also feel like the values are somewhat
backwards.  With text you specify dir=ltr to indicate that the text
itself is ltr.  On the other hand, hflip=ltr indicates that the image
is rtl in nature (and thus should be flipped when embedded in ltr
text).  The meaning of the attribute should be inverted so that it
indicates the directionality of the image instead, with values of
'none' (default), 'ltr', and 'rtl' (this likely requires a new name
for the attribute, maybe @imgdir?).

Section 3.10: This is definitely a CSS issue, not an HTML one.  Bring
this up with the CSSWG, please.  The proposal sounds like it should be
acceptable.

~TJ
Received on Tuesday, 9 March 2010 16:47:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 9 March 2010 16:47:27 GMT