Re: 'HTML 5' and some poem markup?

Philip TAYLOR wrote:

>
> There is considerable merit in this proposal, but what it
> represents is one end of a continuum (the minimalist end).
> At the other end is a language so rich that it can be
> used to mark up every known form of text, in any language,
> and of any era, with total precision, but that is so vast
> that no human would ever be able to remember the name of
> each and every element, let alone the attribute(s) that each
> permits or requires.

Well, I agree, HTML does not require to have specific elements 
not related to text (remember: HyperTextMarkupLanguage).
Poems are text, this is the domain of a text markup
language. audio, video, canvas etc is more related to
SMIL - and there is not much problem to use some
SMIL profile to extend XHTML to get some useful (!)
support for such elements. Maybe canvas requires
another. 

>
> HTML as it currently exists is somewhere in the middle,
> offering a limited range of elements that can be used
> to mark up a large number of contemporary  classes of
> document with a reasonable correspondence between markup
> and actual semantics.  What Dr Hoffmann is proposing is
> to extend HTML to encompass markup specific for poems.
>

If it is required to set limits to HTML - leave 
multimedia to SMIL, this fits together, but care about
something like poems, this is text since two ore more
millenniums.
There is no problem for an author to extend the
functionality of XHTML mixing it with SMIL - or do
you see any problem? Surely not, because from 
your point there is no problem with an extension
for poems for authors, can't be any by mixing SMIL
and XHTML to have video and audio more nice
features.
And mixing SMIL and XHTML is possible for many
years without any problems - or have you ever 
heared someone talking about a problem to put some
SMIL into XHTML? ;o)

Does a text markup language need another element
for raster images (as object or img) like canvas?
Is this essential for a backwards compatible text markup
language version? Surely this is less specific for
HTML5 as markup for poems.

As you can see, the limits you try to set are very 
arbitrary and not much related to the language we are
talking about. 

> But if we were to do this, where would we stop ?  Would
> we then need to add markup for plays, for recipes, for chemical
> formulae, for contracts ?  Surely not.  

Would be nice for have a formula element, this could be
a defined semantic point to put in some MathML or some
reduced HTML alternative, if MathML is not available. 
Formulas are specific text to, with a specific semantic
meaning. How to markup this is left to MathML, but
(X)HTML could provide an element with a semantical
meaning for (X)HTML around it - what is the problem 
with this? There is a clear border where (X)HTML ends
and MathML starts, why not to add such an element?


> So the real answer is 
> that HTML of itself is not ideally suited to marking up poems,

Following your argumentation it is not ideally suited to markup
text at all in general...

> but one /can/ fudge it (a) by overloading existing elements
> and clarifying the nature of the overload through the
> "class" (or *"role") attribute, as in
>
> 	<div class="stanza">
> 		...
> 	</div>
>
> 		or
>
> 	<div *role="stanza">
> 		...
> 	</div>
>

Sure, I did this, looks like the state of
the art of semantic text markup using (X)HTML today. 
And I'm 'nearly' convinced that it changes everything,
if I replace class with role and using some prefixes 
for the values ;o) Maybe one can use 

<div role="poem:stanza"> ... </div>

just to emphasise that this div element really is intended
to be an element containing a stanza from a poem ;o)
This crutch may work with a huge list of predefined 
values for role, to ensure, that 'minimalist authors' only
have to use div and role to do everything right ...


> or (b) by using the inherent extensibility of XHTML, as
> suggested by Peter Krantz (below), with whose remarks
>
> I completely concur:
> > XHTML2 provides an extension mechanism through RDFa. RDFa will let you
> > add semantic meaning (and parsing by others) to your specific domain.
> > In fact you could semantically express poems of specific forms this
> > way and create interesting possibilities for people who want to
> > extract the poetry for e.g. resarch reasons.
> >
> > A markup language should probably include as little as possible from
> > specific domains and focus on the general things instead. Domain
> > specifics should be handled via an extension mechanism that allows for
> > unambiguous interpretation of the expressed information.
>
> Philip TAYLOR

With this discussion up to now, I cannot see any progress for the
semantics with HTML5 - why should authors change from HTML4 or
XHTML 1.1? I think there is already some progress in XHTML2, 
but are you sure, the browsers will interprete such extension
included in XHTML2, if they do not even interprete XHTML2?
If this works in a browser I can use on my computers, I will surely 
prefer to use XHTML2 instead of HTML4/5...
Maybe authors want to change because of the new, cool
features, not much related to text markup? Maybe, but
then HTML is maybe the wrong name of the game.


> > The semantic meaning of a paragraph
> > is much different from a strophe or stanza
> > (see wikipedia or an encyclopedia of your
> > preference).
>
> Please follow cross-references:
> > A paragraph is typically a block of text with one or more sentences
> > that discuss a particular topic, as in typography, but can also be
> > used for more general thematic grouping. For instance, an address
> > is also a paragraph, as is a part of a form, a byline, or a stanza
> > in a poem.
>
> - Geoffrey Sneddon


Therefore I do not exclude this in 'my' model to use p inside a 
poem, maybe more related to modern poems, from the semantic
meaning there is not much relation between a stanza/strophe and
a paragraph, therefore both might be useful for poems.



Ian Hickson wrote:

> HTML5 actually defines how to mark up poems in HTML (the word "poem" is in
> the spec half a dozen times, in fact!).

There must be a reason, why it is scattered along the complete specification,
maybe an indication, that simply an element named 'poem' is missing to put
everything to a sufficient place ;o)

>
> Specifically:
>
>  - the heading of a poem is marked up using <header> and the
>    appropriate level of <hX> elements,
>

Yes, this included in my suggestion.
The main problem with hX is, that the heading of the poem is
not directly related to the cascade of headings outside, therefore
it is more useful without the X as for almost any section too.
If someone uses a (simple) PHP-script to generate web pages 
containing poems, the X in the output may change, because the 
cascade outside the poem is different. Authors having such problems
are forced somehow to use 
<div class="heading"> ... </div>
instead, no nice solution again concerning semantics.
And my 'real world experience' with authors joining together
content with PHP like scripts is, that they tend to go this simple
way. They will not use a header with hX in it, they will simply
put some div inside the header or will directly use the div
instead of the header. Do you really believe many of these
authors will sniff around with their scripts, which X is correct 
in the place they are putting a section or something like this? 
Very optimistic... Maybe I will do that and another percentage,
but 99 percent will not ;o)
90 percent will not even see the problem and 9 percent will
comment: why is an element like h missing, if we have sections
and these nice elements around without a numbering.


>  - the stanzas of poems written in the classical form are given by <p>
>    elements, with line breaks indicated by <br> elements (one of the few
>    allowed uses of <br>).
>

See above, this is poor markup, not really useful to identify fragments
of poems as poems, maybe sufficient, if this appears inside a specific
element to identify a poem as a poem.
I'm writing both, (fictional, technical and scientific) texts with paragraphs
and poems too - not a good choice to mix up paragraphs with stanzas
and line breaks with lines - one cannot use <br>some poem line</br>
Therefore br is obviously not a markup for a line, just a line
break, that is simple to see...

>  - the stanzas of freeform poems are given by <pre> elements.
>

Yes, this I tried too several times, again no identification to be
a freeform poem / concrete poetry, however we might call it - 
this is maybe sufficient, if the pre appears inside
a poem element, as it can appear inside a section element
(If there is not need for poem, there is no need for article, nav,
aside, too. div or maybe section would be enough to cover them
all).

Received on Friday, 5 October 2007 18:26:21 UTC