- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Thu, 28 Feb 2008 11:43:47 +0100
- To: public-html@w3.org
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