RE: So, what's left?

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