Re: Cougar DTD - bidi

Hello everybody,

I got the message below from Jonathan Rosenne. I'm not on the list,
so please cc me separately if you think it is needed.

> At 20:10 02/05/97 -0400, Dave Raggett wrote:
> >> Also, the DIR and LANG attributes were deleted for the ADDRESS,
> >> IMG, DIR, FORM, HEAD, HTML, IMG, LISTING, MENU, PLAINTEXT, XMP. 
> >
> >This is still under discussion. Some of these elements are
> >deprecated e.g. LISTING, PLAINTEXT and XMP, along with DIR and MENU.
> >The document language is set by the HTTP Content-Language header or
> >the corresponding META/HTTP-EQUIV element. Avoiding LANG on HEAD and
> >HTML avoids the need for a conflict resolution procedure. As for
> >the other elements, its still to early to say what the consensus
> >will be in the HTML working group.

I fully agree with Jonathan. In addition to his arguments, I would
like to provide the following:

There is a difference between HTTP Content-Language and LANG
on HTML. HTTP Content-Language may be multiple-valued, e.g.
in the case of a document containing a message in both French
and English. LANG, on the other hand, is never multiple-valued.
It defines the "base" language of the document, which is the
language of everything that is not separately marked.
Having LANG on HTML allows for consistent inheritance. Having
it on all the other things, but not on HTML makes implementations
more difficult rather than easier. There is no need for a conflict
resolution procedure, LANG on HTML just overwrites Content-Language
as LANG on BODY overwrites LANG on HTML, and so on. Simple inheritance.
Similar things apply to FORM. It would be strange that one would
have to specify each containing element of a FORM to be in a
particular language when it is the whole FORM that is in this
language.
Also, for IMG, LANG may apply to text contained in the image.

In general, it is much easier to have these attributes even on
elements where at first sight, they seem not strictly to be needed.
Adding them later if it is found that they are indeed needed is
a pain. Having an attribute with no visible effects on an element
is not a big problem, as long as the "no visible effects" is
a natural thing to do in this combination.

Hope this helps,	Martin Du"rst.

Received on Wednesday, 7 May 1997 08:52:41 UTC