-
Notifications
You must be signed in to change notification settings - Fork 14
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
Add Minimal schema #2
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I recall your other PR included some scripts to merge everything into a single schema file. Are you planning to add that later?
Yea, I wanted to discuss the scripts before adding them to the repo. Maybe we need to figure out profiles as well so the scripts create a full schema for a given profile |
should we add "default" to every property? |
should we move common properties to a different place and reference them where needed, to avoid duplications? For example "w" (width) is used in |
should we add caniuse property for syncing feature names? |
Co-authored-by: Aidosmf <[email protected]>
I've added a script that merges the schema into a single file. I have neither committed nor ignored the file, we should discuss which approach to have with it. I suggest not having the file committed and having it built with github actions. |
We would need to have discussions for defaults as separate merge requests
I added the proposal #3 I think caniuse should follow the schema, not the other way round.
No, I really don't like splitting the schema like that, I think it would make it significantly more difficult to read and maintain. If unrelated objects have similar properties they should be duplicated. In the schema I'm trying to keep relationships between objects somewhat similar to an object-oriented model. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
"title": "Opacity", | ||
"$ref": "#/$defs/properties/value" | ||
}, | ||
"sk": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we specify that skew and skew axis are not supported in layers and that they are only supported as shape transforms?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think some players support them in layers as well, perhaps this can be specified in the profile definitions
Description
This adds the schema for a very basic lottie definition (Subset of the baseline profile).
Once this is merged we can discuss adding schema definitions for more objects in baseline/core profiles.
I've made some of the schema definitions hierarchical so it can map better to an object model (not just JSON validation), this also reduces duplication of certain properties shared by similar objects.
Compatibility Considerations
I've only added objects and properties that are widely supported. Do let me know if there's anything that should be removed or properties that need to be marked as required for a specific object.