On 4/19/2010 9:47 AM, Julia C. Miller wrote:
In order for a "paradigm shift" to happen at DP, PG has to define what is and is not acceptable in the HTML and spell it out so that DP can put it into practice. I took another look at the PG HTML FAQ and it does not say anything that might be used as a guide to improving HTML output.
The odds of this happening are about equivalent to that of having porcine aviators; Mr. Hart is diametrically opposed to standards of any kind for PG. However, PG creating an HTML standard is in fact unnecessary. According to Mr. Hart (although somewhat disputed by Mr. Haines) PG will accept just about anything it is given. Thus, DP could establish its own HTML guidelines with the assurance that they would be acceptable to PG. Non-conforming HTML could still make its way into the PG corpus from other sources, but at least the DP work-product would be consistent.
It would also be extremely helpful to have a way to preview the different output formats so we can test our finished HTML and make sure it works properly not only as HTML but also as the source for the other formats.
This could be so difficult as to be nigh on impossible. For example, as most here know, the ".epub" format is actually just a zip file containing (among other things) the XHTML version of the document. How that document is displayed does not rely at all on the nature of the document's markup, but almost exclusively on the capabilities of reading device's software. The .epub readers based on JavaScript (such as Monocle) will probably display the text with as much richness as the hosting browser software would, whereas standalone .epub readers (such as µBook) will only display what the software designers felt was important, and probably will not support CSS at all. No one viewer can tell you if the markup is satisfactory, because with .epub the markup is only part of the story. On the other hand, if DP were to establish HTML guidelines and requirements (requirements for a baseline, guidelines for enhancements) I would be happy to code up a program which would test for conformance to those guidelines. I couldn't give you a picture, but I could give you a thousand words.
I (for one) am happy to modify the way I do things -- as long as someone explains what should/shouldn't be done and why. I am not a computer professional (and neither are many or most of the PPers at DP) and don't have the time or background to track down the current thinking on how to code HTML. But I don't have a problem modifying my practices to end up with a better end product.
Adding HTML markup to a document (or modifying that which is already there) is nowhere near as difficult as many would have you believe. Check out http://web.archive.org/web/20080327044926/gutenberg.hwg.org/tutorials.html and http://www.dysfunctionals.org/~networker/HTMLeBooks.html. But you are correct, having a document like one of these which is DP-sanctioned would simplify a PPers life dramatically.
Perhaps some of the time that is spent ranting about DP's work flow and DP's output could be better put to use creating more informative FAQs or even guidelines that DPers can use to create output that fits into the current thinking about acceptable HTML and/or other formats.
Many have tried (among them Mr. Hutchinson and Mr. Perathoner). But without organizational buy-in those FAQs and guidelines will go nowhere--fast. Unfortunately, there appears to be no one left at DP with the clout to say, "this is our first draft of HTML guidelines. Comments and discussion is welcome, but by the end of the year some sort of guidelines /will/ be adopted." As near as I can tell, the ranters rant not because DP's work flows are, shall we say, sub-optimal, or because the FAQs and guidelines have not been written, but because none of the Powers That Be at DP seem to be willing to do anything about it. These kinds of decisions cannot be made by consensus. Somebody needs to step up to the plate. Mr. Adcock seems to still have enough respect for DP that he believes it can be improved. I do not. I would love for someone to prove me wrong.