Hi Peter, > There really are not many elements needed. The ones I use in my HTML approach > are more or less only <em>, <strong> and <code>. Headers, byline and such does > not really need markup because they are easily identified and the layout > person > can easily see them and manually set correct style (if needed). > > Using a suitable CSS-file the author can preview the file using his web > browser. > No special program needed, just a text editor and a web browser. I like that > minimalistic approach:-)
at first glance, using HTML seems not a bad idea, and I know of at least workflow which is built on HTML. The problem, however, is that you would have to insert (1) markup elements manually (text editor), (2) use a text based HTML editor like Quanta, or (3) a WYSIWIG HTML editor. (1) and (2) wouldn't be any advantage over a publisher defined markup. As with (3) I know of only one WYSIWG software with w3c compliant HTML output: NVU. I don't expect NVU to be installed in many production environments. Moreover, authors would have to learn a new piece of software, which is regarded as counterproductive, no matter what the long term advantages may be. But reality is even more unpleasant. If you tell the authors: "We need HTML", they will use their word processor, because, "Hey, my $WORD_PROCESSOR_OF_CHOICE can save to html". OK, sometimes you have to explain how to save to another than the default format, but that's another story. But the HTML output of most word processors is a horrible mess. Worse, as most authors use or have to use M$ Word, you will receive HTML files which are almost unusable. Have you ever looked at "Word HTML" files? They are filled with uncessary tags, especially designed for Internet Explorer and for seamless editing in Word. In the end you need a Get Text plugin which has to clean up the code, strip all unnecessary tags and to check if the code is valid (closing tags etc.). And even then, chances are good, that something goes wrong. Which brings us back to square one ... Christoph
