JSON: How to encode object style selectors

[adrianholovaty]

In the MNX style system, there are two ways of targeting a style:

• Via a class name (e.g., "color all objects with the class "highlight" red)
• Via an object type (e.g., "color all notes red")

This issue concerns the latter. When MNX was XML-based, targetting based on object types had a natural solution: you'd just use the element name (note targets <note> elements, etc.). But in JSON, objects don't have an inherent name that's directly encoded in the document.

This suggests we need to provide an enum of addressable style selectors. More precisely, we need to provide a list of the following:

• The string to use (e.g., "note")
• The type of object that this refers to (e.g., the note object)

Even if we were still using XML, we likely would have had to define this list. It wouldn't have been feasible to allow any type of XML element to be styled, because that doesn't semantically make sense in all cases.

With this in mind, here's my proposal:

• In the Styling an MNX document docs, we provide a full list of all strings that can be used to express object types, with a link to the corresponding object type's docs page.
• For every type of object that is styleable, we update its doc page to define how to target it via a style.

Thoughts or alternate proposals?

[samuelbradshaw]

I notice on the linked note object definition we don't have a type property or a class property. Do those need to be added to enable styling?

It seems maybe we need to make a distinction between full objects and simple properties. Our list of objects (https://w3c.github.io/mnx/docs/mnx-reference/objects/) has several items that seem to be simple string or number properties, not full JSON objects {}.

After separating those out, it may be easier to see what it makes sense semantically to style. It seems that simple string or number properties won't usually be semantically styleable, but full objects with a type usually will be. Where that's not true, we could consider changing objects to simple properties and vice versa.

[mscuthbert]

Agreed with @samuelbradshaw about making a distinction between full objects and simple properties. If it doesn't parse as a Javascript object / Python dict, it's something else.

But as the discussion in #295 progresses, I don't think we necessarily need a type or classes property to determine that something is an object or a particular type of object -- it's a note because of its attributes and where it appears in the score not because it has "type": "note" in it.

(p.s. -- I spelled class as classes purposefully -- let's definitely avoid using any attributes that are reserved/keywords in major programming languages -- not having React .className or in other cases .klass is a major advantage in programming.)

[samuelbradshaw]

+1 for "classes" instead of class, to avoid reserved keywords, but also to use a plural word where a list/array is expected. ("classes": ["editable", "highlighted"])