- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Fri, 5 Oct 2007 20:19:42 +0200
- To: public-html@w3.org
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