[whatwg] HTML tags for POEM and MUSIC LYRICS

[Tab Atkins Jr.]

On Sun, Nov 26, 2017 at 8:59 AM, GevCbmlGM <bijumaillist at gmail.com> wrote:
> Hi,
>
> Is there any recommend standard HTML tags for POEM and MUSIC LYRICS?
>
> I searched and did not see anyone talk about it.
> But I see different creative way people come up for POEM / STANZA / LINE
>
> 1.
> <BLOCKQUOTE> <P> <BR>
>
> 2.
> <UL> <P> <BR>
>
> 3.
> <DIV> <DL> <DD>
>
> 4.
> <PRE> then text with line brakes and proportional font using CSS styling.
>
> I wish it to be standardized, so if no recommendation exist, I suggest
> following tags.
> <POEM> - With left/right intend from margin, and zero top/bottom
> margin (almost  BLOCKQUOTE).
> <STANZA> - With top/bottom margin, but zero left/right margin (similar to <P> ).
> <L> this is for LINE, single character tag name to replace use of BR.
> Content in<L> tag should not word wrap, instead it should continue
> right side like contents in <PRE> tag.
>
> We also need a set of tags for MUSIC LYRICS, with VERSE, CHORUS,
> tag/attribute to mark repetition. As well as other tags/attributes
> which music community thinks will be needed.

Poems and lyrics are, generally, just text that has significant
line-breaks. Thus, <p> and <br> are the correct markup for them.

For poetry that plays around with spacing and alignment (and thus has
significant whitespace), <pre> is the correct markup for it.

To add anything new to support these, head over to
<https://whatwg.org/faq#adding-new-features> and run thru the
questionaire there; the bar for new additions to HTML is relatively
high. In particular, merely wanting to encode more semantics into a
document is often not worthwhile - in general, semantics are only
useful insofar as they help machines understand the document (so they
can help humans more effectively, such as screenreaders, search engine
spiders, etc.). You'll have to answer to why this level of additional
semantics for poetry is valuable in this way, and how it improves over
the current situation in tools that actually exist (or make a *very*
convincing argument that the current lack of semantics *prevents* a
useful tool from existing, and it's likely that the tool will develop
on its own after this is added).

~TJ