>You gents are assuming that there will be certain browsers that need
>certain fallback markup, and want to complexify FIG in order to supply
>the fallback markup. Aside from the likely transitory nature of such
>a situation, this is bad design. Where do you stop? Why not do this
>for math, tables, anything not handled right by *some* browser? What
>would we be left with when all browsers handle FIG correctly?
[...]
After considering the arguments against using FIG for embedding with
alternatives, I agree that giving FIG the ability to contain other FIGs is
probably not a good idea. This should be handled using either a full SGML
browser or, better yet, browser-server negotiation.
IMGs inside FIGs, however, give HTML 2 browsers (which will still exist for
quite some time, in my opinion) the ability to display something usable in
place of an HTML 3 FIG.
>Better to keep it simple, which is one of the few agreed upon design
>criteria, and leave FIGTEXT as text only.
I disagree. the FIG|IMG exclusion on FIG should be changed to exclude FIG only.
>However, the issue will get chewed over all over again once someone
>writes an Internet-Draft for FIG; I believe Dave Raggett may be working
>on one.
>
>For really complex interactions of markup and browser you probably
>want a browser with a proper API and the ability to take an arbitrary
>DTD. Check out Panorama.
I use Panorama, it seems like a nice SGML browser. In fact, I highly
recommend it for anyone who wants to check web pages against the HTML DTDs,
especially if they are testing modified version of the DTD (i.e., allowing
IMG in FIGs). The only file you'll need that's not available from one of the
HTML 3 mirrors is the Extended Latin character set.
Lots of fun, if you have MS Windows.