Re: Marking Up Poetry

Philip Taylor wrote:
> I'm reluctant to enter into this debate, yet
> feel strangely compelled so to do.  I would like
> to ask Dr Hoffmann a few questions.  
> Dr Hoffman
(n)
> ,  do you believe that poetry should be intrinsically
> supported by HTML 5 ?  

Yes, because it is some specific type of text and
it is still called HyperTextMarkupLanguage, therefore
this language is the right place to have at least a
basic support for poetry, because it has already an
advanced support for prose, sufficient for many
prose applications.
And as already discussed, HTML5 covers much more
than just HyperText, but not only for historical reasons
it should be still possible to markup text with this
in a meaningful way and with basic functionalities.

> And if so, would you 
> prefer that certain new, poetry-oriented, elements
> be included in the HTML 5 language, or would you

Yes, a few new elements would be the best lets
call it the clean or theoretical approach -

A poetry container similar to article, which is 
pretty useful to separate prose content already.
Headings (h1-h6) can be reused for poetry.
header, footer, address can be reused for poetry
as well as phrase content, maybe even br might
have some use, not very often, but because
artists have always the tendency to break taboos,
if it is excluded, it is already a good chance, that
it would be abused ;o)
section can be reused for poetry.
dialog can be used for poetry (like Goethes Faust
or Shakespears Macbeth for example) better than
for prose, as currently specified.
For prose content a similar element, maybe called
conversation could be introduced, because it
does not have any specific requirements as lines
in poetry.

A strophe container and a line container are 
required for the typical microstructure of poetry.

> 
> prefer that some existing elements be overloaded ?
>

An alternative approach is not to overload existing
elements, just to add an additional attribute to
refine the meaning and interpretation of elements
anyway already used for a similar or exactly that
purpose in HTML4. The advantage here is already
a basic backwards compatibility, for example if
dl/dt/dd are used with an additional attribute for
dl - even outdated browsers will still manage to
present it as list like content, even if they ignore
the additional attribute.
I think, this is more the HTML5 design principle
compatible approach, new elements are more
a propper solution for a new language like XHTML2.


> If you /do/ feel that poetry is a special case,
> and deserves instrinsic support, do you also
> feel that there are other special cases that
> have not (yet) been addressed ?  

Yes, some are already mentioned in the 
proposal for a refined definition of dl/dt/dd.


> Would you, 
> for example, like to see dramatic scripts
> supported ?  

See above, could be already done with the
reuse of already existing elements or new
elements introduced in the current HTML5 drafts
together with poetry micro structure.

> Legal contracts ?  

I'm not an expert for this, this looks like prose
content, this is typically already good
covered with a basic support in HTML.
But maybe an expert has to explore, if such
documents have specific requirements on
functionality.

> Bus timetables ?

This I used already often, more for tram line
and underground light rail, but this should
be quite similar for bus or plane.
Lets explore this:
It is table like prose content, therefore
the table elements are a good approach
to start with.
Needs maybe additionally headings (h1-h6),
caption, a container (table), summary, 
tr, th, td, some hyperlinking to comments
maybe (often they are somewhere below
the table to explain specific cases like
X-mas, bank holiday behaviour etc).
th and td are already pretty useful to
separate data cells from each other,
some accessibility tools are available
too in HTML, this is pretty nice, because
it is not always easy to understand such
complex tables.


> 
> Telephone directories ?  

I do not use them often, but what I have
from the german telekom is mainly
some prose content, maybe list like,
dl/dt/dd could be a good approach too,
it correlates names, addresses and 
phone numbers with a list like behaviour,
not very complex at all, name+address
separated from phone number, therefore
a list maybe already sufficient, not really
an application for a table, but this is maybe
more complex in other countries. 
Using headings, section, phrase content etc
covers this already pretty good, at least
for such a piece of literature from the
german telekom ;o)


> Each of these seems 
> to me to be as worthy of intrinsic support as
> poetry, yet there are (as far as I can tell)
> no members of the HTML 5 Working Group
> clammering for their inclusion.  

I think, they have to explain, if there is a
specific requirement for these applications
on basic functionality. If this is found, this
might indicate, that there is a need to do
something. From my analysis above I 
would say, the basic functionality is already
available for several of them.

> So the key question, 
> for me at least, is "what is it about poetry that
> causes you to regard it as a special case ?" (assuming
> that you do).  

It is not very special, not more than for example
ordered lists, unordered list (by the way, I have never
seen an unordered list on a computer yet, it is more
a not numbered list, even sets, classes are typically
somehow ordered on a computer), table, article, dialog, 
aside, etc.
They all provide specific structures or functionalities,
more than for example a div container. The same
applies for such a group of elements like 
poetry, strophe, line.
Compare with the group table, tr, th, td, thead, tfoot,
tbody, they do provide a specific structure or
functionality, this can be simulated too with div+CSS,
but obviously it is helpful to have specific elements
for this too, to get a simpler access to the meaning
or structure and information of table like content.
For example users having only aural presentation
or tactile presentation (braille), it might be already
a help, if a group of elements can be identified as
a poem with strophes and lines. 
If we have for example a classical sonet
(not the Shakespeare type), the user might advice
after the first aural presentation: 'repeat title,
third line of the third strophe and third line of
the fourth strophe of the current piece of poetry' 
to analyse the quality or the content of the sonet in 
more detail. 
If such structures cannot be identified, it is a
waste of time for the user to repeat the 
complete page containing maybe completely
different prose content or maybe other poetry too. 
Additionally a user-agent may provide some 
advanced aural presentation for poetry content,
taking into account more rhythm and timing related
to the used language, if this is  available or possible.
If not, the user might be thankful to get at least
informed, that this is not available - we all know, 
that it is typically a torture to get an aural presentation
of poetry or songs from someone without any 
capabilities for aural presentations - the user
might already skip the poetry, if it is already known,
that it is always a torture to hear poetry in the
used less advanced presenter, which is mainly
pretty useful to present bus timetables and 
telephone directories ;o)

Obviously this is no problem for visual presentation,
typically the user has no problem to identify the poem,
and the strophes somehow, if they are decorated
with some margins and paddings. For visual 
presentation the user may have a problem sometimes
to identify a line - because there was no sufficient 
space available to present one strophe line in one
line, the user-agent had to break the line, therefore
for visual presentation the user-agent may indent
a line break within a strophe line to indicate the
problem for example. Currently it does not, 
because it cannot identify a strophe line as a
strophe line. It simply does not cover this simple
requirement to present the micro structure of
poetry content.

> If you could explain this, it 
> might help those, like myself, who feel some sympathy
> for your cause, yet who do not wish to see the
> HTML 5 language either abused (by overloading
> existing elements with new, unrelated, meanings)

This would be the case if we start to have specific 
elements for Sonets, Ottava Rima, Elfchen (do not know
the english word for it), Limerick, Haiku etc.

This is somehow similar as to have specific elements
for bus timetables, underground light rail, metro,
tram line, planes. Typically the user will be able to
identify this easily (not the user-agent), this is similar
as to distinguish between a Sonet and a Haiku after
the first presentation. If this is required, the author
could simply provide a subtitle or this could
be refined with some RDF(a) approach both for 
timetables and poem types, after the basic structure
is already provided by (X)HTML. The RDF(a) approach 
already assumes, that there is no human mind at all to 
identify anything, therefore the information has to 
be very detailled. With some intellectual capabilities
on the side of the user, a basic structure support
like the group of table elements for timetables and
that group for poetry are already very helpful to
save some time for the author and both for 
visual and not visual presentation. 


> or enlarged to the point where it would require
> a dictionary or an encyclopaedia of elements before
> one could use it successfully, to better understand
> your position.

There are already some nice improvements both in
HTML5 and XHTML2 to get some more structure in
documents for a better understandability and a
better access for everyone...
I think, this is already better as only to use the 
group br/b/a/img to markup everything in a
monotonic, meaningless tag soup.

Received on Friday, 29 February 2008 12:53:25 UTC