Is it really that common for these attributes to have directions that differ from the element's contents?

Note that you can't set the language of the attribute text separately either. Or, indeed, any other metadata. For example, you can't use <ruby> with attribute text, or emphasise it, etc.

It is common enough for 'alt' to have been commented negatively on for a long time. The problem with 'alt' (and 'title') is that they refer to some content that itself might not be "directional". Consider:

<img src="somePhoto.jpg" height="200" width="200" alt="TFEL-OT-THGIR description">

"somePhoto.jpg" doesn't really have a text direction. We don't want any mirroring-type behavior. We want to set the alt text direction because the surrounding context may not match direction, since it isn't that unusual to have the value of the 'alt' attribute filled in at runtime. 

A more extreme example might be:

<p dir="rtl">some arabic
 
   <img src="ObamaPhoto.jpg" alt="Barack Obama" title="Mixed English and Arabic" />

even more arabic
</p>

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: Just use dir="". That's the right attribute to use in that case as far as I can tell.

If you think the spec should show this as an example I'm happy to add one. Grab me on IRC and we can figure something out. (I don't speak Arabic or Hebrew so I'll need help with that.)

Reopening the bug for two reasons:

1. Besides asking for titledir and altdir, the bug asks for the spec to explicitly say that by default, the title and alt values are displayed in the element's computed direction. This has not been addressed before rejecting the bug. As explained in the full proposal, although currently all major browsers seem to do this, it has not always been the case. It is not currently obvious from the spec and that should be changed.

2. There are cases when the title or alt needs to have one direction, while the element needs another. Here is an example for title, from the FPWD (http://www.w3.org/TR/html-bidi/#title-and-alt), that accidentally got left out of the editor's draft:

An RTL web page displays an LTR address (e.g. for a location in Europe), with a tooltip on the address element saying "ADDRESS" in the page's language. The tooltip thus needs to be RTL (i.e. titledir=rtl) while the element needs to be LTR (dir=ltr).

For such cases, we want titledir and altdir.

I can add the requested clarification, but for future reference, it's strongly preferred for each bug to cover a single problem (and not a single solution).

Regarding the second issue in comment 4, you can do that today by just having two nested elements, one outer one with the dir="" and title="" attributes, and one inner one with the dir="" attribute and text. Given that it's already possible, and that this is a rather rare case, I do not think it's appropriate to add an entire new feature for this use case. New features are expensive.

(In reply to comment #5)
> Regarding the second issue in comment 4, you can do that today by just having
> two nested elements, one outer one with the dir="" and title="" attributes, and
> one inner one with the dir="" attribute and text. Given that it's already
> possible, and that this is a rather rare case, 

My understanding is that, while it indeed is a rare case for people using ltr scripts, it is much more common for people using rtl scripts, because text in Arabic, Hebrew, Urdu, etc commonly mixes in Latin or other ltr text. Note that it only takes a comma (eg. in a list), period (eg. Inc.), parentheses (eg. an abbreviation), or other simple punctuation to make things turn out badly. It's not only for bidirectional text. I can think of several examples quite easily.

For instance, suppose you want to put a title attribute on some text that I just found on one of the W3C Office pages like this (upper case = Arabic):

... <a href="http://..." title="Moroccan Internet Society (MISOC)">MOROCCAN INTERNET SOCIETY</a> ...

You would currently see the following, where the [ ] indicates a tooltip:

[(Moroccan Internet Society (MISOC]
     ...YTEICOS TENRETNI NACCOROM...

Which of course looks badly broken. To make that look right you'd have to resort to kludge code that I think is time consuming, error prone, and so plainly a hack that it must feel a bit like a slap in the face to the many millions of people who use rtl scripts:

... <span title="Moroccan Internet Society (MISOC)" dir=ltr><a href="http://..." dir=rtl>MOROCCAN INTERNET SOCIETY</a></span> ...

After a few cases of that you also get pretty fed up that HTML doesn't just do this cleanly.

I don't think adding a dirtitle="" attribute is doing it "cleanly". :-)

Why can't the author just use Unicode bidi formatting characters in cases like that? That seems like a far cleaner and more explicit way of doing things.

We generally claim that we want people to use markup instead of the Unicode bidi controls. And we've gone out of our way to provide a 'dir' attribute on just about anything that might require it. So it seems like a strange oversight to have one place in which the author must explicitly provide the invisible and otherwise deprecated control characters.

What's more, the title and alt attributes are often rendered using native controls (such as tooltips) rather than in the page render space controlled by the user agent. It isn't clear if the Unicode controls will always have the desired affect there (some API might need to be called or the controls might even show as 'tofu' empty box glyphs).

You're correct that we don't provide the other modifications, such as styling or language, that might occasionally be useful. But generally an unadorned string can be rendered legibly by the user-agent with such additional cruft. However, bidi is different (see examples above).

Finally, attributes, like much else, are scriptable or dynamically generated. Attribute values are much easier to assign when appropriate than it is to add Unicode bidi controls on the fly.

I don't think new titledir="" and altdir="" attributes are particularly more elegant than just requiring people to use an extra wrapper element.  Is there any reason other than aesthetics to not use <span title="ltr" dir="ltr"><a dir="rtl" ...>ltr</a></span> or whatever?  That requires no extra work by current or future HTML implementers, and is usable by authors today instead of in the distant future.  This doesn't seem like a big enough problem to add new attributes for.

I agree with comment 9. Comment 8 is predicated on the assumption that we should continue to discourage the use of bidi formatting characters, to the point of discouraging them even in attributes where there is no alternative. Why? Even if we add titledir="", we still won't be giving authors the ability to mix different languages, such as in a comma-separated list of english words in a hebrew sentence (where the commas end up on the wrong side of the english words).

I don't think using invisible characters should be mandated in cases where we can reasonably avoid it.  They're extremely confusing and hard to work with -- you can argue this is just a tooling issue, but it's a ubiquitous one and I don't think it's likely to change anytime soon (since most software isn't used for dealing with mixed directionality much).  In some cases we need them, like for <title> and attribute values and other things that have to be plaintext, but we shouldn't require them in other cases if possible.

In this case, though, you can already solve the problem without the proposed attributes and without invisible characters, albeit a bit clumsily.

Internet Explorer (at least some versions) has entities for certain bidi formatting characters. Maybe we should consider adding those? Though I suppose that would be a separate bug.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale:

I don't think that having an attribute for each freeform text attribute to specify its direction (and presumably another to specify its language) is a scalable solution or particularly good language design.

I don't see why we'd discourage people from using bidi formatting characters in freeform (markup-free) text. Bidi named character references seem reasonable to me (but file another bug if you want them). I don't really follow why you'd need to dynamically change the direction of an "alt" attribute or why doing so is easier with an attribute than using bidi formatting characters. Also, with regard to using the latter, they don't have to be invisible if we use character references (named or numeric).

The problem described also seems already solvable using nested elements.

In conclusion, I maintain that the conclusion drawn in comment 3 still holds.

(In reply to comment #12)
> Internet Explorer (at least some versions) has entities for certain bidi
> formatting characters. Maybe we should consider adding those? Though I suppose
> that would be a separate bug.

I don't think I would want named entities for LRE, RLE, LRO, RLO, or PDF, since it would seem to stamp their use in HTML generally as kosher.

(In reply to comment #13)
> I don't think that having an attribute for each freeform text attribute to
> specify its direction (and presumably another to specify its language) is a
> scalable solution or particularly good language design.

Granted. Which is why it would have been better to make all freeform text attributes elements instead, but it's a little late for that.

> I don't see why we'd discourage people from using bidi formatting characters in
> freeform (markup-free) text.

Some of the reasons for discouraging formatting characters whereever HTML allows mark-up are explained in bug 10809, comment 31.

Obviously, we can not and do not discourage their use in places where mark-up is not allowed, such as these attributes, but that does not mean that they are truly a good solution.

1. Users (especially not very technical ones) are very good at making balancing mistakes with the formatting characters. They are even better at letting them go out of balance when they edit the text later.

2. Browsers usually let the underlying platform handle the tooltip text in a native control. Many platforms, however, display them inappropriately if support for "complex scripts" has not been enabled, and by default it isn't. As a result, browsers often wind up displaying these characters inappropriately on LTR systems. (As you have indicated in the discussion on bug 10816 leading to its rejection, browsers can not even be accused of violating any spec, e.g. the Default Ignorable Code Points requirement of the Unicode Standard, since the bug is in the underlying OS, not in the browser.) As a result, one has to be very careful about using formatting characters in title and alt, i.e. not to use them to declare the direction of a pure LTR title, since doing so will help on the RTL systems, but do harm on many LTR systems.

> Bidi named character references seem reasonable to
> me (but file another bug if you want them).

As indicated above, I do not want them.

> I don't really follow why you'd
> need to dynamically change the direction of an "alt" attribute

Nor do I - did I seem to suggest that somewhere?

> or why doing so
> is easier with an attribute than using bidi formatting characters.

See above. In brief, using bidi formatting characters is a nightmare.

> The problem described also seems already solvable using nested elements.

For title, this is true, but a little-known workaround. For alt, the workaround does not work, since the alt needs to be specified on an <img>, not on a <span> around it. On the other hand, setting the alt's direction directly on the img's dir attribute currently does not seem to have any effect except the desired one for the alt, but this is not entirely obvious, and is also a workaround.

As indicated above though, I do see your point about this change not being particularly good language design.

(In reply to comment #5)
> (In reply to comment #4)
> > Besides asking for titledir and altdir, the bug asks for the spec to
> > explicitly say that by default, the title and alt values are displayed in the
> > element's computed direction.
> I can add the requested clarification.

For the record, this was done in the scope of fixing bug 10819 as diff <http://html5.org/tools/web-apps-tracker?from=5636&to=5637>.

(In reply to comment #15)
> Granted. Which is why it would have been better to make all freeform text
> attributes elements instead, but it's a little late for that.

This seems like it would be pretty hard to do for something like title="".

> For title, this is true, but a little-known workaround. For alt, the workaround
> does not work, since the alt needs to be specified on an <img>, not on a <span>
> around it. On the other hand, setting the alt's direction directly on the img's
> dir attribute currently does not seem to have any effect except the desired one
> for the alt, but this is not entirely obvious, and is also a workaround.

It seems to me like the workarounds are logical enough that they're better overall than trying to add new direction attributes for every single attribute that accepts plaintext.