- From: Mike Batchelor <mikebat@clark.net>
- Date: Fri, 4 Aug 1995 08:54:57 -0400 (EDT)
- To: www-html@www10.w3.org
Michael Johnson once wrote... > > Ping wrote: > >The rest of my message concerning <FIG> content proposes that the content > >of FIG be treated as HTML to be rendered as a figure when SRC is not > >specified. This is aimed at increasing orthogonality. > > > >How do you feel about this? > > I'm not quite sure what you mean by "rendered as a figure". The intent of FIG > content now is that it should be rendered in place of the SRC when the latter > is unavailable. I guess it would not hurt to expand this notion to allow the > SRC to be omitted entirely so that the content is always rendered. > > When you say "rendered as a figure" though what exactly do you mean? I have > been thinking about the idea of paying attention to the width attribute when > I render the content of a FIG, falling back on normal processing if WIDTH is > not specified. I would then flow text around the formatted content. Is this > the sort of behavior that you mean? That's what I would like to see. A <fig> with a SRC represents some item that is not part of the text flow, but should be set aside, perhaps enclosed within a box, and have the surrounding text flow around it. I don't see why this should change if the <fig> doesn't have a SRC. The <fig> then contains textual data that is separate from the surrounding text flow. And that textual data could certainly contain <img>. Here's an example of how this would be useful: <fig align=right width=40en height=10en> <caption>We have two versions for you!</caption> <ul> <li><img src="html2.gif">Select this for <a href="index.html">HTML v2</a>. <li><img src="html3.gif">Select this for <a href="index.html3">HTML v3</a>. </ul> </fig> <h1>Welcome to XYZ Inc.'s Web site</h1> We are pleased to offer, blah blah blah blah <p> Contact us at <address> blah blah blah</address> (and so on). This would then have the short list with caption aligned to the right margin, and the following <h1> and paragraph would flow around it. I suppose the same effect could be achieved using a borderless table with headings, but sometimes, a table isn't appropriate, but a figure is. > Someone who wants to write simple pages doesn't have to use the extra new tags. > But people who want to write documents that can be searched by a sophisticated > search engine need the power of these tags. > > Some have proposed using the CLASS attribute of EM to replace those tags. My > opinion is that this is an abuse of the CLASS attribute. I infer from the > IETF draft and comments in the DTD that CLASS exists purely to allow elements > to be subclassed for the purposes of presentation. I do not think that Dave > intended CLASS to be used to dynamically define new semantic markup, nor do I > think it would be a good idea to use it for this. Oh but that's *exactly* what class is for! It extends HTML in the same sort of way that classes extend C++. Why shouldn't HTML authors be able to declare new classes, too? Style sheets are merely one application of the class attribute. There are potentially hundreds more. Imagine a robot that combs the web for new class attributes, and uses them to build a thesaurus of classes that is referenced by other indexing robots, to improve the quality of the indexing. The possibilities are endless. -- %%%%%% mikebat@clark.net %%%%%% http://www.clark.net/pub/mikebat/ %%%%%%
Received on Friday, 4 August 1995 08:55:00 UTC