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

On Wed, Mar 17, 2010 at 8:47 AM, Aharon (Vladimir) Lanin
<aharon@google.com> wrote:
> 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).

If we have to expose the algorithm at all, I like this one.  I'm still
dubious that it's useful to do this, but at least this hides the
algorithm from people who don't care about it, and reduces the need to
specify the algorithm multiple times.

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

I'd rather have bdi *never* be on by default, and maintain standard
binary attribute processing.  As well, bdi="" does not turn off a
binary attribute (in fact, it turns it on, since now the attribute
exists).  It may turn off attributes using some alternate scheme, but
there should be a good reason for doing that.

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

Oh, certainly, the ability to manipulate images like that *is* useful.
 But it's not a bidi issue.  There is no possible bidi-related
justification for unilaterally horizontally-flipping an image.  Image
manipulation at that level is not the purview of bidi, or even HTML.
CSS is a likely appropriate place for it.

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

Yeah, agreed.  I don't like the name being procedural in this nature;
it should be more declarative, like the dir attribute is.

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

I don't understand your analogy.  I agree that, taken by itself,
@imgdir may be slightly harder to understand.  Taken with @dir,
though, I find it easier.  You're declaring the directionality of the
image, similar to how you do with text.

> - If we do go the imgdir way, I guess the third value (and default) would
> have to be "neutral".

The default should be no attribute, which makes images act like
normal.  We don't need an explicit third value for this.

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

Yes, because the positioning of the list marker is a styling issue,
and thus CSS's responsibility.  HTML can then recommend a default
browser styling, but it cannot change *how* CSS does stuff.  Right now
there is no explicit control in CSS for which side the list marker is
on; any change to how it is displayed must be made at the spec level.

~TJ

Received on Saturday, 20 March 2010 00:46:36 UTC