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

Thanks a lot for the great comments!

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

This is indeed an issue that has been raised by many people, and the primary
reason that we have left it open whether to expose two different algorithms.

There is, of course, the option of offering just one algorithm. However, I
see no easy way to reach a consensus on which one.

One possibility that I have already suggested in a reply to fantasai's
message is to unify first-strong and word-count under the disguise of giving
the page author control over how much of the content is scanned (the
"auto[0-9]*" scheme, see in a previous message for details). However,
response has not been overly enthusiastic.

I would like to suggest another possibility. Perhaps it would be more
palatable to have just dir="auto", but to also introduce another attribute,
autodirtype (or perhaps autodirmethod). Its values would be either
"first-strong" or "word-count". It would have a default, and the value one
sets on an element would be inherited by its descendants. The advantages of
this over dir="ltr|rtl|word-count|first-strong" are:

- Most users would not be faced with making an uninformed choice. They would
just use dir="auto" (and would get the default method, whatever it is).
- The advanced users who don't like the default could set it just once on
<body> (without applying dir="auto" to <body> itself).

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

Well, the difference is that  sometimes bdi *is* turned on by default (when
dir="auto", and if 3.1 is adopted, on <br>), so explicitly turning it off
will be something that people will sometimes need to do. The problem is that
I think that few people who wind up writing HTML documents know how to
explicitly turn off the attributes using the standard approach (bdi=""). And
bdi="no" is a lot harder to misunderstand than bdi="".  But, in the end,
this is an issue for HTML syntax gurus - which I am not.

> 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 am not sure I understand what would constitute abuse of hflip=yes, and
why. It seems to be generally useful. A completely LTR and bidi-unaware page
may need to use both left- and right-arrows or some other pair of mirror
images, and using hflip=yes beats maintaining a separate image. And it seems
funny to have an attribute with a "no" value, but no "yes" value.

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

- Inverting the meaning indeed requires renaming the attribute. hflip="rtl"
at least to me begs to be interpreted as "flip horizontally when in rtl".
- The effects of imgdir (or whetever name is chosen for the inverted
meaning) are less obvious. Stating that someone is a COBOL programmer does
not necessarily mean that they need to switch to Java.
- If we do go the imgdir way, I guess the third value (and default) would
have to be "neutral".

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

Assuming that the CSS folks don't shoot holes in this, I am not sure I
understand why it is not (also) an HTML issue. Would there be anything wrong
with the HTML spec stating that the dir of an <li> does not apply to the
positioning of the <li>'s marker?

Aharon


On Tue, Mar 9, 2010 at 6:46 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> 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 Wednesday, 17 March 2010 15:58:40 UTC