Open scoiatael opened 1 year ago
In GitLab by @rychlis on Jun 24, 2021, 10:42
Also specify how are we going to represent that a layer is using specific style
In GitLab by @nikitamironov on Jul 13, 2021, 24:15
Good job, nonetheless there are few more notes:
1) Octopus layer styles are not only properties we have under effects
key. Layer styles' affected properties are also:
useLayerBlendModeOnly
blendMode
opacity
2) Figma fill. Regarding what you said here:
Color style requires the new type of style object in Octopus, it can't be put into
effect
object as a single "color" can be applied to eitherfill
orborder
. Probably acolorStyle
object that would consist of one ofcolor
,gradient
orpattern
Octopus objects.
I am not sure I understand what is the problem. Do you mean that having effects.fills
as array is a problem and we need to have some way which let you to set up only one fill?
- Description field needs to be added.
This should be added in octopus-manifest.json
I suppose.
3) Regarding XD
Interestingly, XD doesn't keep any explicit mapping between styles and places where the styles are applied to. So when editing a style, every entity in the design that shares the same style configuration (color or text) is being changed as well, no matter if the style has ever been applied to the entity or not.
Mind-blown. This is so messy approach, imo.
4) Regarding octopus proposal: I am not sure I understand some points, we probably should arrange Zoom meeting to discuss it. Nevertheless, combining meta-info (description, library metas etc) imo should not be part of "chunk". All meta about design structure should be in octopus-manifest.json while chunk file should contain only pure style representation and id.
In GitLab by @janroztocil on Jul 13, 2021, 11:07
The latest proposal with concrete octopus example is in https://gitlab.avcd.cz/backend/octopus/-/issues/48
I don't know if this is still true (for Sketch), I created a layer style and it seems that opacity and blend mode doesn't propagate into applied styles "instances". May be that was some legacy Sketch feature.
But anyhow, it would be possible to encode properties that are outside of the effects
object, see the proposal (it's not explicitly shown there but there's a place for that).
I think it's well shown in the proposal.
Yea, that's XD thing, we can't do much about it, I guess we will just list the known styles but without the back reference :shrug:
That's possible, from a format normalization perspective it's even better to have the data only in a single place. However, I wasn't sure how it will be used, whether there's a possibility of distributing styles octopuses without link to the manifest, I don't have strong opinion on that.
In GitLab by @janroztocil on Apr 21, 2021, 19:24
Styles - Octopus representation research
Some form of (shared) styles concept is present in Sketch, Figma and XD. The following text summarizes the implementation specifics in particular source tools, and then proposes a format of representation in Octopus.
The main goal of this initiative is to extract the shared styles information into one place (single Octopus-like file). Currently, styles are copied in every Octopus document that references them. That is far from ideal, the data are duplicated and it's hard to do any high level reasoning of how the styles are used within the design.
Sketch
In Sketch there are two kind of styles: layer styles and text style.
A single 'Layer Style' consists of a arbitrary combination of a fill, border or any other effect on a layer.
Text style is a standard text type format configuration (font face, font size, line height, letter spacing, alignment...).
Both style types can originate directly in the document or be part of a library (which is part of the design anyway).
When a layer has a style assigned, this style can be overridden in the instantiated symbols.
Extra Sketch features is so called "Tint" - which kind of overloads most of the layer's style configuration. However, as it can only be applied to symbol instances or group layers and does not manifest any "shared" properties, it probably doesn't need to be considered here.
Octopus implications
As the current format is based on the Sketch not many changes are needed. Probably only better separation of the two style types.
Figma
Figma recognizes 4 styles types: color, effect, text and grid.
Color style represents a single raster fill configuration, i.e. it can be a solid color, gradient or pattern, which can be used as a layer or a border fill. (It seems that other border parameters like width, alignment or dash pattern can't be configured as a style - of any type).
Text style is standard text type format configuration as in Sketch.
Effect style could be an arbitrary Figma layer effect (drop/inner shadow or layer/background blur).
Grid style is just a named grid layout configuration.
Figma also allows to add description to the style.
Styles can be design local or teams shared.
Octopus implications
effect
object as a single "color" can be applied to eitherfill
orborder
. Probably acolorStyle
object that would consist of one ofcolor
,gradient
orpattern
Octopus objects.XD
XD uses color and text styles. Color style is basically the same as in Figma (pattern is not allowed here). And text style is the same as in all the other tools.
Interestingly, XD doesn't keep any explicit mapping between styles and places where the styles are applied to. So when editing a style, every entity in the design that shares the same style configuration (color or text) is being changed as well, no matter if the style has ever been applied to the entity or not.
Octopus implications
None, as long as the new
colorStyle
object is added.Octopus proposal
The styles file would basically be a valid Octopus document. Although the specification needs to be slightly updated, so that for example
layers
field is not required. Such setup allows for the styles to be part of artboard Octopus document as well be a standalone file.Proposed changes
layerStyle
object to represent the whole layer/effects configuration (currentlyeffects
is directly instyle
)blendMode
anduseLayerBlendModeOnly
are only present inlayerStyle
object, if those are part of a single style (as it might be in Sketch), bothlayerStyle
andtextStyle
object are there as children ofstyle
(same applies to a style that would combine text formatting and layer effects - e.g. drop shadow, dunno what is the type then thought)source
field to represent the origin of the style, could bedocument
orlibrary
(may be more, like Figma team)sourceId
as a formal identifier of the source (library ID or team ID), is empty when source is local documentdescription
fieldstyle.colorStyle
to satisfy Figma and XDstyle.gridStyle
as it comes from FigmaMeta-example
Here is a commented example, most of the inner fields are just standard Octopus representation. Hopefully this is sufficient to get the idea of the updted format for now, latter we will update the formal Octopus schema.
Next Steps