[MEI-L] <div> in header

Mon Oct 26 17:12:07 CET 2015

> On Oct 26, 2015, at 4:48 AM, Axel Teich Geertinger <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."

-Andrew

> 
> Best,
> Axel
> 
> 
>  
> Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [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 <https://github.com/music-encoding/music-encoding/issues/272>
> 
> -Andrew
> 
>> On Oct 25, 2015, at 1:23 PM, Axel Teich Geertinger <atge at kb.dk <mailto:atge at kb.dk>> wrote:
>> 
>> Hi
>> 
>> 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>?
>> 
>> Best,
>> Axel
>>  
>> _______________________________________________
>> mei-l mailing list
>> mei-l at lists.uni-paderborn.de <mailto:mei-l at lists.uni-paderborn.de>
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l <https://lists.uni-paderborn.de/mailman/listinfo/mei-l>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de <mailto:mei-l at lists.uni-paderborn.de>
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l <https://lists.uni-paderborn.de/mailman/listinfo/mei-l>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151026/e67b9de6/attachment.html>