Re: Marking Up Poetry

Peter Krantz wrote: 
>Please see the discussion on RDFa which is suitable for
>domain-specific markup: http://esw.w3.org/topic/HTML/PoeticSemantics

>With RDFa you can create your own vocabulary (if none exists for
>poetry) and extend other's if you need more detail.

This is discussed shortly, indeed, if there would be a role attribute with
direct influence on the presenations in user-agents, this might be a solution
as for other list types too, as for headings too - all these domain specific
things could be reduced to one element, one for lists, one for headings,
one for containers (section, article, canvas etc), one for phrase content 
etc. If this is specificed in HTML5 consistently, why not? Currently it is
not.
My own vocabulary will have no influence on the presentation, therefore
this approach does not meet the requirements as noted on the wiki page.
There is a need for a predefined vocabulary with well implemented 
behaviour in user-agents.


 Smylers wrote:
>* Poems are often read quite slowly, and the line-breaks are important,
>  usually signified by a pause.

Lee Kowalkowski wrote:
>I don't understand it either.  If you have a list of entirely of terms
>or a list entirely of descriptions, it doesn't mean you have a list of
>definitions.  You just have an (un)ordered list.


Such things are noted as requirements on the page.
dl/dt/dd does not meet all requirements, but poems or song texts
are often list like content, therefore a list is already pretty close
in structure and meaning. 
Obviously a poetry-strophe is not an unordered list, the order of
lines is typically important for understanding. But ol is not very
useful too, because this is typically presented with some line
markers like numbers or letters, for strophes only used 
sometimes for educational or scientific purposes.
What is left is dl/dt/dd in HTML - the dl simply defines
a strophe of a poem - this seems to be the conclusion for
several different authors of poetry using this in HTML4, 
they use it more as a 'diverse list', anticipating that
the current HTML5 drafts anyway redefine the meaning
of a 'definiton list' as a 'description list'. Well, the list 
describes the content of a strophe - not bad at all and
still better than to call a strophe a paragraph ;o)

p marks up a paragraph, this is somehow a degenerate
case of a strophe without specific structure as strophe-lines.
br marks up a line break, not a line, this is therefore not
related to lines in a strophe.
For example an article indicates already by naming, that
is contains some prose content, this is a really helpful
new element to separate different content, but the 
naming excludes it to use it as a container for poetry, 
therefore either the name of the element should be
changed or another container element for poetry 
should be defined. 


However, obviously for some authors it is sufficient to
use not more than br, b, a and maybe img as the 
only elements to markup a complete project, therefore
any list elements, paragraphs, headings, html, body etc 
are somehow superfluous domain specific nonsense 
from this point of view. They are not really necessary
if someone writes any text on a sheet of paper, why to
use them in HTML? Maybe because in HTML such 
elements are available to indicate somehow the 
meaning and function of the fragment? To help 
user-agents and the audience to get some more 
understandable presentations?
If this is the case, obviously there is a gap in marking 
up strophes in poetry sufficiently. This is described in the
wiki. If not, other domain specific elements for lists, 
tables, headings, phrase content etc are superfluous too 
and can be completely replaced by either div/span or 
simply by br/a/b/img or even text/plain should be
sufficient for everything - it is still somehow readable, in
many cases text/plain has even a better accessibility than
current erroneous or scripted pages in the web ;o) 
Arguments, that there is no need to have elements to
markup specific functionalities and semantical meaning
finally results in the conclusion, that there is not need for
HTML (5) at all... Obviously millions of authors still use
HTML4 or XHTML1.x, therefore maybe this conclusion is
wrong and elements with a specific functionality are 
somehow useful for many authors and readers 
for whatever reason.

Received on Thursday, 28 February 2008 12:05:28 UTC