Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JSON: How to encode object style selectors #297

Open
adrianholovaty opened this issue Jun 1, 2023 · 3 comments
Open

JSON: How to encode object style selectors #297

adrianholovaty opened this issue Jun 1, 2023 · 3 comments

Comments

@adrianholovaty
Copy link
Contributor

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
Copy link

samuelbradshaw commented Jun 1, 2023

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
Copy link
Contributor

mscuthbert commented Jun 1, 2023

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
Copy link

samuelbradshaw commented Jun 1, 2023

+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"])

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants