LISTSERV mailing list manager LISTSERV 15.5

Help for HTML-WG Archives


HTML-WG Archives

HTML-WG Archives


View:

Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font

Options:

Join or Leave HTML-WG
Reply | Post New Message
Search Archives


Subject: Re: Draft on the i18n of HTML
From: Martin J Duerst <[log in to unmask]>
Reply-To:[log in to unmask]
Date:Mon, 21 Aug 95 14:12:20 EDT
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (68 lines)



>Ad 2.2: As suggested, inline bitmaps can be used for characters
>outside the ISO-10646 repertoire, but there are some symbols that are
>better handled by (SDATA) entities. See e.g., the HTML3 DTD for a list
>of common WWW icons (or see
><http://www.let.rug.nl/~bert/WWWicn/Sample.html>).

Bert - Thanks for the hint.
Do you suggest that we propose using SDATA for such characters in
general? Is this possible with an arbitrary browser, or will this become
possible for HTML3 browsers? Or does that need a browser with generic
SGML capability, or some general extensions of our version of the DTD
to make this possible?
Or do you just suggest that we add a notice, so that somebody that might
look for a "Folder" icon among the dingbats section of ISO 10646 may
become aware that these things are handled differently?
In general, icons _are_ different from characters. Icons mainly stay alone,
or in 2D spacial relation to each other. Characters mainly are used sequentially
in a text. The SDATA mechanism may be a general mechanism to save resources.
The proposal to use small images, i.e. icons, to represent missing characters
is only of technical nature. If it can be improved by using SDATA, why not.
But we should not get characters and icons confused. The kind of characters
we are speaking about in most cases will be under study or avaiting approval
for inclusion in ISO 10646. For icons on the other hand, no such thing is planned.
There might be some icon-like "characters" in ISO 10646, but the main reason
for this is backward compatibility.
Also, with respect to efficiency, missing characters may be downloaded
many times for the same document, but we can assume that this is avoided
by caching mechanisms. In contrast to the WWW icons, these characters will
not be widely used on many documents, and so their preloading (as what
I interpret the SDATA mechanism) at every site is not necessary.

>Ad 3: The LANG element has no meaning apart from what its attributes
>provide. There was some discussion of a similar generic element in the
>context of style sheets. To avoid adding two such elements, I suggest
>either:
>
> 1. merge them into a single MARK, PHRASE, whatever; or
> 2. make the LANG attribute of LANG #required.

Again, thanks for the hint. I also proposed something similar in our
internal discussion and recently in this group, because there might
be a BIDI element with similar problems. I suggested STRETCH
as a name, I guess I would prefer MARK. Phrase in my oppinion
could be too much related to actual phrases or clauses in a text,
which is not the direct intention.

>Ad 3.2: It seems to me that the entities &lre; and &lretag; have
>exactly the same effect (as does <BIDI LTR>). Why do you need both
>SDATA entities and elements?
I assume James Clark has shown how this has to be done. At the
moment, the discussion is more on how the markup should look
like than whether we also need character entities (which I assume
from the discussion there is consensus that we can do without).

>Ad 5.1: forms-data is a *sequence* of pair-lists, is that correct?
>Likewise for complex-value: shouldn't it contain just one pair-list?

This is Francois's area. Please wait for a comment until he is back.

>Ad 7.1: (This is really a criticism of the HTML 2.0 DTD, I guess):

Dan, could you give a comment/suggestion here?

Regards,	Martin.



Back to: Top of Message | Previous Page | Main HTML-WG Page

Permalink



LISTSERV.HEANET.IE

CataList Email List Search Powered by the LISTSERV Email List Manager