Clarify inheritance and override of a note's color by descendant elements

[mdgood]

The MusicXML 3.0 documentation leaves the relationship between the color of a note element and the color of the note's descendant elements unclear. Should descendants like the lyric element inherit the note element's color, and override the color within the element if necessary? Or should note elements be uncolored unless otherwise specified? The same issue applies to hierarchy within the note element, such as the relationship of text and elision color to the color in the parent lyric element.

The design intention was for descendants to inherit from the parent and override where needed, but this should be verified, changed if needed, and made explicit within the documentation.

This general principle could also be applied to other hierarchical elements within MusicXML. The topic gets more complicated for elements like beams and slurs that span the XML hierarchy and move between note elements that have different colors. That will be addressed in a separate issue. This is also related to a parallel question about inheritance of the print-object attribute in issue #61.

See the MusicXML forum discussion started by Frank Weinstock at http://forums.makemusic.com/viewtopic.php?f=12&t=2471 and the discussion started by Michael Cuthbert (@mscuthbert) at http://forums.makemusic.com/viewtopic.php?f=12&t=2359.

[mscuthbert]

My initial thought is that the element's color should govern all the color of all elements defined within the element (similarly for higher level elements such as measure if applicable). A that begins a chord should override the default color for all members of the chord, as if there were a element. Slurs etc. would thus behave the same way, and therefore a slur beginning on a with a color would probably need a "color='black'" attribute.

I'll make one more push for moving styling information to a style attribute and allowing CSS (or at least a subset thereof such as defined in SVG) to dictate style. There are a lot of free parsers for CSS and we'll eventually be needing a lot of other ways to define color/gradient/font-styling, etc. so it'd be good to piggyback on what is already out there.

Thanks for moving this here!

[lemzwerg]

What is the current status of this nine-year-old issue? Is there any progress, or any intention to work on this? AFAIK, there is no clarification in the current MusicXML standard version...

Is there a survey available how programs like Sibelius or Finale implement color support? Do they obey the intended inheritance?

[lemzwerg]

Alas, no response... I thus went on by myself and implemented the following rules in the current development version of LilyPond's musicxml2ly.

• For <note>, only items that are directly attached to it are affected by a top-level color attribute. This means that breathing marks, dynamics, and lyrics don't inherit the color.
• Spanners (i.e., elements like beams, slurs, or hairpins that span more than a single note) don't inherit colors either.

Here is a new MusicXML test file for colors (from LilyPond's test suite); below are the results formatted with LilyPond (including the explanatory text) and pre-4.4.0 MuseScore – Finale 27 doesn't support color while doing MusicXML imports.