- From: David Wagner <dwagner@kevric.com>
- Date: Mon, 24 Jan 2000 15:15:06 -0600
- To: "'www-html@w3.org'" <www-html@w3.org>
Ah, It took some digging, but I finally found the XHTML 1.1 working draft. I apologize I misunderstood the comments here, and missed the coninuing existance of <applet>. As a developer, I usually find simpler systems are more flexible and robust than complicated ones, and they tend to have longer lives. (ASCII is still around, and in use right here.) I liked the idea of <object> being a generic container for 'stuff it is not reasonable to markup in this document', and especially enjoyed the method of nesting various formats of the same object so the UA can find a displayable one. If the item is that important to understanding the document, I will create the different versions needed so every browser will display something appropriate. (I always wondered why <img> is an empty element with an alt attribute, rather than an element whose content is rendered if the UA cannot display it, thus allowing the use of the one-thousand words the picture is worth, or such methods as eclosing ASCII art in a <pre> element within the <img> element, to approximate a critical diagram.) This same method can be readily applied to the various devices, media, and accessiblility needs proliferating. To continue the previous image example, if I really want to reach everyone, the UA should be able to choose among a vector drawing for hires projectors and other capable devices, high and low-resolution images (depending on user prefs of quality vs. speed), an audio file describing the image for those who can't see the image but do have the bandwidth, a monocolored small bitmap for handhelds, a hires grayscale image or vector drawing for black and white printing, and so on. I realize this overlaps somewhat with stylistic issues, but if there is no method in the markup language to get the resource required for a particular medium and user preference, all the style in the world won't display it, and my message will remain locked in a well-formed strictly-compliant lint-free container. I suppose my only recourse is server-side, to develop XSLT files to generate as many versions of a document as necessary. This is less elegant, and will have to be done carefully to avoid the kind of proxy problems the W3C has encountered with its browser-sensitive stylesheet delivery. I like to keep up with standards development so I know things like this as far in advance as possible. Much of the work I'm doing now won't hit publication (on the web and CD-ROM) for a year or two. Though I have been leaning toward using nested-objects for client-side multimedia selection, I now know it's safest to go with server-side customization, though getting these publications working from a CD-ROM will be a bit more complicated. I do appreciate the discussion on this list. My success depends in part on where the standards are headed, and I just hate to redevelop the same old content over and over again. (Though it does pay the bills. ;) -David
Received on Monday, 24 January 2000 16:19:18 UTC