On Tue, February 7, 2012 4:28 pm, don kretz wrote:
Lots of facets to this lesson - minimal markup is best.
Yes.
It's the same reason TEI looks nearly reasonable with no markup.
Not necessarily, but at this point complete accuracy on this point is not very relevant.
A lot of the refactoring from old DP html to portable html is going go be just taking things out and remarking a few things syntactically (like chapter headings).
And removing the internal style sheet and adding a link to a generic .css file.
Rather than inline style, you could also have just changed it to:
<chapter_heading>Chapter 1</chapter_heading>
Or <h3 class="chapter">Chapter 1</h3>. But you obviously know that.
and added to your stylesheet: chapter_heading { display: block; plus the other css stuff to match <h2>, or anything more to your taste }
/* Center first three headers */ h1, h2, h3 {text-align:center; font-weight: bold } /* Put a little extra before chapter breaks */ h3.chapter { margin-top: 2em; margin-bottom: 1em; page-break-before: always; font-size: larger }
and you would have exactly the same appearance, with greater granularity of control over all the chapter headings. And if you change the css for whatever reason, you run no risk of unintentionally messing up all the other stuff someone has called "<h2>".
Now we're getting to the nub of the issue. The rule I derive from what you have said is: For every document the document structure and the document presentation need to be segregated. This segregation should be accomplished in such a way that the document presentation can be changed without significantly changing the document structure. [little snip]
In the title page there's a poem. The poem resides in a table, all its own, otherwise the table is serving no purpose.
I think that was my rule #4: <table> may only be used for tabular data, never for display/presentation.
I have simplified it down to:
<poem> <attribution>poet</attribution> </poem>
(which, yes, is 100% equivalent to <div class="poem"> and <div class="attribution">, but it's simpler, and displays just as well;
One man's opinion, with which I happen not to agree...
and both can be mapped properly to any other markup that understands poems and attributions.)
Or you could have simplified it down to: <poetry> <by>poet</by> <verse>....</verse> </poetry> Which brings me to the point I have been trying to emphasize over the past several weeks. If we're planning to be able to swap out presentation, we have to use the same elements (tags) with the same attributes for the same purpose across all documents. <div class="poem"> or <poem> or <poetry> are all acceptable to me, but /there can be only one/! The less generic an element is (<poem> as opposed to <div class="poem">), the easier it is to programmatically validate markup. For example, if <poem> is permitted by the DTD, XMLLint or Jing will object if it encounters <poetry>; but it would /not/ object if it encounters <div class="poetry">. This does not mean we couldn't develop a tool to validate that all <div>s must be classified, or to check that the classification values are in the set of allowed values for the element; but an existing DTD or RelaxNG validator is not going to catch those problems. But none of these tools can check to be sure that valid tags are applied correctly. The problem with a presentational focus is that a contributor will use a valid tag incorrectly. For example, pretend that the <poem> tag, by default, is assigned a display type of "pre" and a monospaced font. Now pretend we have a book that has a quoted telegram as part of the text. A contributor may be tempted to mark the telegram as <poem> because it has the desired default presentation, even though the semantics are incorrect. (In HTML, the correct tag would be <tt>). I believe that volunteers are completely capable of marking <poem> and <tt> correctly, but only if there is a simple document that says, "<poem> may only be used for poetry. Don't use it for things that aren't poetry just because it looks right. Other options may be <tt>, ..., etc. If you aren't sure, post a message to the PP group." To summarize: Presentational markup (aka Cascading Style Sheets) and structural markup should be segregated into separate files. Structural markup should be strictly constrained to established patterns so different style sheets can be applied to the structural document according to a user's preference. Markup constraints must be clearly and unambiguously documented in a format that a volunteer can read and understand.