- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 9 Mar 2010 10:46:49 -0600
- To: public-i18n-bidi@w3.org
- Message-ID: <dd0fbad1003090846s4808c335ufa61a60bd983c169@mail.gmail.com>
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 UTC