[MEI-L] <div> in header

Roland, Perry D. (pdr4h) pdr4h at eservices.virginia.edu
Thu Oct 29 20:55:08 CET 2015

The definition "Major structural division of *text*, such as a preface, chapter or section" was intended to convey the idea that <div> is to be used in *the text*. That is, <div> is available for text within the <body>, but not in the header.  I'd be grateful for suggestions for improving the definition so it's more clear.

Structuring metadata above the paragraph level is the function of the various metadata elements themselves.  Allowing the recursively nest-able <div> element within the header would discourage the "data-like" treatment that metadata requires; that is, a hierarchy that's as flat as possible.  Where internal structure is permitted, it's often facilitated by the use of elements that may appear as content of a <div>, such as <p> or list-Like elements -- items that either contain phrase-level text or can occur within phrase-level text.

Renditional info in the header is also strictly at the phrase level, when for instance <rend> is permitted within <altId> and <classCode> to accommodate typographical features like superscripts and subscripts.

I think <div> already is aligned with its counterpart in HTML.  That's another reason why it isn't allowed within the header.


Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu
From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Andrew Hankinson [andrew.hankinson at mail.mcgill.ca]
Sent: Monday, October 26, 2015 12:12 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] <div> in header

On Oct 26, 2015, at 4:48 AM, Axel Teich Geertinger <atge at kb.dk<mailto:atge at kb.dk>> wrote:

Hi Andrew

I can do a workaround by wrapping the contents in a <div> before passing it to the text editor and stripping it off again with XSLT on saving. Nevertheless, I am not sure I agree that header contents is never intended to be rendered. After all, the header may contain such information as transcriptions of a source's title page.

I think the distinction I was trying to say is that the information in the header is never rendered *directly* -- that is, it's never intended to be related (in a positional sense) to the content in the document. Of course, the information in the header can and should be intended to be shown to the users, but I think the positioning and display of header text should be left to the software rendering it.

We are rendering loads of header information in our catalogues. I agree that exact placement of text blocks doesn't seem to be a likely thing to do in the header, not even within the title page transcriptions (I have no idea what kind of coordinates would make any sense unless we implement a detailed page layout specification; but that's definitely not a road I want MEI to go down). MEI does, however, already allow quite some text formatting within <p> such as font style, size, and color, so header content may already contain some rendering information.

I would even go so far as to say that anything that has to do with font, sizes, etc. should be held in the "<music>" section. Holding rendering information in the header seems like a recipe for confusion.

But more important, I do not see why <div> should be used for positioning and other rendering purposes only. On the contrary – the MEI guidelines say:
<div> (division) – Major structural division of text, such as a preface, chapter or section.
This is exactly the structuring mechanism I would like to see in the header as well: structure on a larger scale than <p>.

Yes, this is problematic. Personally, I would like to see <div> take on more of the HTML-like definition of a block-level element, to cause less confusion to encoders who are used to the HTML-like behaviour: "It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so."



Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca<mailto:andrew.hankinson at mail.mcgill.ca>]
Sendt: 25. oktober 2015 23:00
Til: Music Encoding Initiative
Emne: Re: [MEI-L] <div> in header

Personally, I think of <div> being used to position rendered text like in HTML. So having it in the header would be problematic, since that information is never intended to be "rendered" directly.

This is somewhat related to a recent discussion on GitHub: https://github.com/music-encoding/music-encoding/issues/272


On Oct 25, 2015, at 1:23 PM, Axel Teich Geertinger <atge at kb.dk<mailto:atge at kb.dk>> wrote:


Is there any particular reason why <div> elements are not allowed anywhere in the header?
I am asking this because I want to use a Rich Text Editor (tinyMCE) for blocks of text in the header, for instance in <annot> or <history> within <work>. This type of editor requires that the editable content is wrapped in a single element (like <p> or <div>). It is not good at handling mixed content. Of course i could use <p> as the wrapper, but then I would have to have one editor instance for every paragraph, if I want more than one paragraph of text.

I actually think that allowing <div> in <history> could also make the structure a little clearer. As it is, <history> may contain <head>, <creation>, <eventList> and any number of <p>s. Perhaps it would be nice to be able to wrap all non-structured text in a single <div> to separate it from the more structured elements <creation> and <eventList>?


mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>

mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151029/d6ddc636/attachment.html>

More information about the mei-l mailing list