Re: titledir

On Fri, Sep 3, 2010 at 6:01 AM, Aharon (Vladimir) Lanin
<aharon@google.com> wrote:
>> As far as I know, the longdesc attribute points to a URL, and
>> therefore is not subject to the same considerations as the title
>> attribute.
> You have a point. And given that no browser actually supports longdesc, it's
> best to simply not mention it.

Agreed.

>> The alt attribute, as applied to images, _can_ potentially
>> be subject to the same concern [as the title attribute], IMO.
>> However, I think in order to
>> determine the direction of the alternate text, I think it should be
>> safe to specify that user agents are supposed to use the value of the
>> dir attribute on the img element (or its computed CSS direction).
> It is indeed the intent to propose, for both alt and title, that their
> direction should be specified by the element's computed direction (which can
> be set by its dir attribute). However, for title, we are proposing a way to
> override it with titledir because it is not unreasonable to want an
> opposite-direction title on an element.

I agree with all of the above.

> Although obviously nothing prevents
> an author from doing the same in alt, I don't think that it is a good idea
> for the author to do that, and so I don't think that we should encourage it
> by giving a way to specify it.

Hmm, I'm still not sure why you don't think it's a good idea for an
Author to do that.  Let me give an example.  Let's consider the case
where in an RTL page, I want to show a European address (which should
be written in LTR) on a map as a static image displayed using an img
tag.  In order to support the users who have turned image display off,
for example, I may put the address as the alternate text for the
image.  But the address will be displayed in RTL mode, which is not
what I intend.  I don't see what's different about this use case
compared to the one you suggested for supporting @titledir for @title.

>> Furthermore, I don't see why we need to explicitly specify that the
>> titledir attribute should not have a CSS equivalent.
>
> Do you think it needs a CSS equivalent?

No, but I also don't see why we should specify that there should not
be a CSS equivalent, provided that the CSS WG can come up with a good
reason why there needs to be one.

--
Ehsan
<http://ehsanakhgari.org/>

Received on Friday, 3 September 2010 16:22:20 UTC