Re: Request for clarification of the case where 'the image isn't discussed by the surrounding text, but it has some relevance'

> <h1>The Lady of Shalott</h1>
> <p><img src="shalott.jpeg" alt=""></p>
> <p>On either side the river lie<br>
> Long fields of barley and of rye,<br>
> That clothe the wold and meet the sky;<br>
> And through the field the road run by<br>
> To many-tower'd Camelot;<br>
> And up and down the people go,<br>
> Gazing where the lilies blow<br>
> Round an island there below,<br>
> The island of Shalott.</p>"


I think, this is a bad example to markup poetry or arts at all.
Marked up in this way, it is simply a paragraph
including an image, no poem at all.
To remove it from the HTML5 draft would already improve
the quality of the draft slightly.

Because the image is inside the paragraph, it obviously belongs
directly to the idea presented in the paragraph and needs therefore
to have a descriptive alt attribute. A paragraph always repesents
some idea, therefore is should not be empty. Containing only an
image without alt or with an empty alt means effectively, that the
paragraph represents no idea, therefore the p elements is abused
here.

As far as I understand what I have read about that poem, not
the author is the guilty one here, he did not markup the poem
at all and did not have an image as the first strophe/stanza of the 
poem. Therefore we can assume, that an editor has used
the image and the poem to combine them in an inappropriate way.

If this editor thinks, that the image is not an intrinsic part of the
paragraph or text/poem, it should be not part of the paragraph/text/poem.
If the editor thinks, that this is a poem, the complete text should
not be marked up with a p element to indicate a paragraph.

Therefore the editor of this heading/paragraph/image combination
either intended to corrupt the idea of a poem or did not know how
to separate a decorative image from the content, the poem and did
not know how to mark up a poem in (X)HTML, what is no surprise, 
because there are no specific elements to markup poetry currently
in (X)HTML.
If we assume, that the editor wanted to cite a poem, there is a
high probability, a paragraph may present a strophe/stanza. In this
case it would be surprising for a classical poem to have an image
as a strophe/stanza. Looking at the second paragraph however,
we can assume, that if the image represents a (new) strophe/stanza
of the poem, the alt text should have rhyme and rhyhtm.
If we assume, that the next paragraph is an equivalent of the image, 
the complete paragraph should be content of the alt attribute.
Because there is no possibility to structure the text in the
alt attribute somehow to represent a poem, an object element
would be a better choice.
Because currently there is no propper way to markup poetry
at all in (X)HTML, it could be a much better idea anyway to
use object to reference the complete poem in another format.

According to what I read, there seems to be a tradition, that
some artists are inspired by the original poem to paint something.
In such a case we have two related pieces of art. But one is
not part of the other, therefore an editor has to separate them,
to add some information about artists/authors and maybe it
would be a good idea to write somehow, that the image
was inspired by the poem or something like that to indicate
the relation, which is no equivalence or decoration.
In HTML5 this could be two 'article' elements apart from the
problem, that poetry is no article an a painting is not either,
but this is another limitation of the current HTML5 draft by
the choice of element names. 'figure' might be a possebility
for the painting too, if it is assumed, that the text is the
'important' part of the construction, however, obviously
the 'figure' should not be part of the poem of course.

To conclude, the current sample is pretty confused and no sample
to show good markup style or how to structure documents
somehow useful. And it does not represent the original idea
of the poem author to write a poem.

Received on Tuesday, 19 August 2008 10:17:38 UTC