> I seem to be having trouble getting either the html-wg or www-html
> mailing lists to recognize my messages. (I tried sending this to both
> of them, but it doesn't seem to have made it into either of the
> archives I know about and it has generated no feedback.) Since I
> think that some of the points could be useful, rather than wasting
> time hunting down the technical problems it seemed more useful to go
> to the top, as it were. I'd be interested in your response, and (if
> you feel it worthwhile) I'd appreciate it if you could forward this to
> the appropriate list.
You need to subscribe to the lists first. See http://www.w3.org/ for
more details on how to do this.
> After reading through the 3.0 DTD (learning SGML syntax as I went), I
> must say that I am very impressed and quite looking forward to using
> it. I do, however, have a couple of suggestions that I hope you'll
> consider.
> First off, I have a few questions:
> o Where can I find the lists of icons and math symbols referenced
> by the DTD?
These will be included as appendices in the HTML 3.0 Internet Draft.
> o Which ISO standard is referenced for the language tags. I've
> seen a standard for country codes and some informal lists of
> language tags, but none that standardize language x country. Is
> the combination going to be standardized or will a browser have
> to decide if cn_sg should be treated like cn_cn or cn_tw?
I can't remember the standard number right now. Perhaps we should
include a list of these codes in an appendix along with some sample
uses.
> 1) A <FIG> allows <CAPTION>s. since many figures are photographs,
> it would be useful to also have a <CREDIT> tag to identify the
> source of the figure. (Alternatively, this could be an
> attribute on <FIG>, but I see no reason not to allow markup.)
> A browser would probably show in small text under the image or
> at the end of the caption.
Yes I have been toying with this idea myself.
> 2) Browsers are likely to implement inline animation in the future
> (indeed, some may do so already). The <FIG> tag seems ideal for
> this, but it would be useful if it had an attribute that
> identified animation as such so that browsers which display
> inline animation differently from static images (such as by
> displaying controls under them) could do their text flow layout
> (based on WIDTH and HEIGHT) before grabbing the image.
This shouldn't be part of the markup as it can be derived from the
content type of the figure data, e.g. video/quicktime.
> 3) For display of legislation, it would be useful to have tags for
> "text deleted" (<DEL>) and "text inserted" (<INS>). These are
> normally shown as strike through and italicized respectively.
> An alternative would be to have a <SO> tag for strike-through
> text, but this poses a problem for a viewer which cannot display
> strike-through or italics, as a bill is unreadable if the
> deleted, inserted, and constant portions are not displayed
> contrastively. Having special-purpose tags allows them to be
> distinguished.
I had these tags (with different names) in HTML+. Right now 3.0 includes
a character style tag for strike-out, but not the logical tags. This seems
like something we should add.
> 4) For displaying quotations in mail, it would be useful if <BQ>
> could contain an <ATTRIBUTION>. It might also be nice if this
> <ATTRIBUTION> had an attribute which specified whether it was to
> come at the beginning (as is usual in mail and news) or at the
> end (as is common in scholarly quotation).
Once again, a very reasonable idea.
> 5) Often, <IMG>s are used to mimic characters which are not present
> in the viewers character set. It would be useful if such
> characters could be defined as entities within the document via
> something like:
> <ENTITY NAME="new" SRC="/gifs/new.gif" WIDTH=20 HEIGHT=40 SIZE=12pt>
> Then the author could just use "&new;" to refer to this symbol.
> The SIZE attribute is there to say that this is designed to work
> with a 12pt font. If the prevailing point size is much larger
> or smaller than this, the viewer may wish to scale the image
> appropriately.
My view is this is better handled via a new content type for sending one
or more character glyphs as outlines. The ISO entity names are useful for
naming such characters. Watch out for activity in the area of downloadable
fonts in the near future.
> 6) It might be worth considering allowing <FIG SRC=NONE> to allow a
> piece of HTML to float and be flowed around like a figure. In
> this case, you probably want the WIDTH attribute to be mandatory
> (and specified in ems).
This can be achieved by using a table with align=left or align=right,
along with the COLSPEC attribute to specify the width.
> 7) The <NOTE> tag takes a SRC attribute but no ALT attribute. It
> probably should.
Perhaps.
> 8) I don't believe that there's any way for a <MATH> element to
> distinguish between an inline equation and a displayed equation.
> Is it intended that displayed equations be wrapped in <P
> align=center> or should there be an attribute for this on
> <MATH>?
The intention is that you precede the MATH element with a <P> if that
is what is wanted.
> 9) The browser assigns numbers to <LI> elements within <OL>s, which
> is fine. Unfortunately, this makes it hard to refer to an item
> in the text. It would be nice to have a <NUMBER ref=FOO>
> element which would expand to the number assigned to <LI
> id=FOO> (and maybe <FN id=FOO>).
> I realize that this may cause problems with forward references,
> but they should not be insurmountable.
This idea is indeed a good one, but feels a little bit on the complex side
for the initial release of HTML 3.0. Perhaps 3.1?
> 10) Similarly, figure and table <CAPTIONS> and displayed equations
> may also want to have numbering attributes (but the default
> should be that they stay unnumbered). If <NUMBER> is added, it
> should work with these numbers as well.
Naturally. The numbering style will be a matter for style sheets.
The HTML markup will only determine the sequence number itself.
> 11) With the presence of <STYLE>s, it would be useful to have an
> element which does nothing but apply a style. Actually, if it
> took %atts, it could replace <LANG>, which I believe must
> already be used as <LANG lang=fr> (which seems redundant).
This can be done by subclassing one of the existing character emphasis
elements, e.g. <em class=slander>...</em> and matching on em.class = slander
> 12) With multiple bodies, the DTD allows specification of an
> absolute POSITION. Perhaps it would be better to specify a
> ROLE, such as "buttonbar", "warning", "copyright" or "sponsor".
> This would allow the viewer to choose a (user-selectable)
> standard for where to place certain types of ancillary
> information.
I have backed away from this for the initial release of HTML 3.0.
It seems enough to support a simple static banner area for now,
using the subclassing mechanism.
> 13) This may be opening up a can of worms, but it may be useful to
> have elements which are only included if displaying or if
> printing. (Currently the notion that what you see on the screen
> is what you see on the paper often leads to loss of information
> when a page is printed.)
This issue surfaces from time to time on the discussion group. The
general feeling is that we want to encourage people to use a single
form of words suitable for a range of rendering devices (screen, print,
voice, braille, ...).
> 14) There are many times within a form when a particular <INPUT>
> should only be conditionally active. For example:
> <form>
> Browser Type:
> <ul>
> <li><input type=radio name=browser value=netscape>Netscape
> <li><input type=radio name=browser value=mosaic>Mosaic
> <li><input type=radio name=browser value=lynx>Lynx
> <li><input type=radio name=browser value=other>Other:
> <input type=text name=other-browser size=20>
> </ul>
> </form>
> It would be useful if there could be an attribute on the text
> input field which specified that the field should only be active
> if the "Other" button was checked. This could make reference
> either to the name/value pair, or (probably better) to an ID
> attribute on the "Other" button:
> <li><input type=radio name=browser value=other id=OtherB>Other:
> <input type=text name=other-browser size=20 sensitive=OtherB>
> A browser would not have to respect this hint (and so a script
> could not depend on their not being extraneous fields coming
> back), but for browsers which did, the feedback for the user
> would be better.
This is better handled via the more general mechanism of client-side
scripts associated with forms. These are needed for immediate feedback
of inconsistent or badly formed entries and spreadsheet style aggregate
values e.g. on order forms. They would also allow the form to be displayed
in a manner depending on the context, e.g. earlier entries or environment
variables.
Many thanks for your excellent ideas. You may get better feedback
from the group in future if you use shorter more focussed messages.
Best wishes,
-- Dave Raggett <dsr@w3.org> tel: +44 117 922 8046 fax: +44 117 922 8924
Hewlett Packard Laboratories, Filton Road, Bristol BS12 6QZ, United Kingdom