Adding autolayout feature

[scarnation]

Hi I am new to penpot and I am creating this issue as a suggestion to a feature that would really help alot in my transition to your platform. The auto layout feature such just like that on figma would really aid the speed and efficiency of design on your platform. I am also open to helping and contributing in anyway to this project, I am a product designer and java developer.

[swordfest]

This is a key feature for Penpot to achieve a strong base workflow since Figma is been bought by Adobe and lot of people are looking for similar tools.

[dick-jo]

Seconding the critical need for these features but would also encourage using more appropriate nomenclature when discussing this - autolayout is a feature of a proprietary tool (Figma).

Figma's autolayout is modelled primarily on the following W3C specifications:

• CSS Box Model Module - Padding, margin borders etc...
• CSS Flexible Box Layout - Flex parents/children, grow, shrink, main/cross axis alignment etc...
• CSS Box Alignment Module - Further main/cross axis alignmnent, gap properties, etc...

Notably, Figma's autolayout terminology deivates at times significantly from these specifications.

The reason I raise this as critical to addressing this issue due to the following risk: By modelling these features on Figma's 'autolayout', there is significant risk of adopting proprietary language instead of the nomenclature used in the W3C spec - which is already thoroughly well-considered and universally accepted.

The following nomenclature specimens are good examples of where Figma's terminology creates problems.

Figma	W3C
Autolayout	Flex
Spacing between items	Gap
Fill	width: 100%
Hug	width: fit-content
Vertical direction	Align*
Horizontal direction	Justify*
Top left alignment	Start*
Bottom right alignment	End*
Spacing mode: Packed	justify-content: start*

• items marked with an asterisk represent one of the most egregious issues with Figma's proprietary nomenclature: Complete failure to account for the ability of a parent container to switch it's layout direction. For example, when changing a flex parent from flex-direction: row to flex-direction: column the main axis changes from horizontal to vertical. The main/cross axis distinction vs using horizontal and vertical explicitly is critical as it allows the layout to remain agnostic to the layout direction of any given container. Perpetuation of this poor terminology also creates additional barriers between design and development, where for no productive reason terminology has been abstracted, obfuscating translation of design into code.

Furthermore, the other major issue with modelling on Figma is an additional major blind spot in Figma's implementation: No grid support. Whilst Figma's autolayout allows you to use flex-like layout rules, there is no equivalent support for CSS Grid.

The issue here is that ultimately, other than nomenclature issues, modelling on Figma will likely perpetuate these blind spots and cause Penpot to neglect serious opportunities for innovation such as the adoption of CSS Grid functionality into any 'autolayout' style feature implementation.

[jcklpe]

I approve of this push by @dick-jo to adhere to the w3c standard terminology.

[scarnation]

Yes @dick-jo , keeping appropriate naming will definitely help in guiding the proper implementation of the desired features

[Profesor08]

Adding CSS grid like layout will instantly kill figma. And the priority of implementation css grids must be highter when flex layout, because it is easier, gives more opportunities and has better support for gaps. In flex layout you will play with margins, making shit code to simulate gaps, just to make layout to work.

[dick-jo]

Completely second this @Profesor08 - people love Figma's autolayout but have no idea what they're missing without grid support. This would be an absolute gamechanger for digital design GUI tools. This is why I made the terminology recommendations above - not to be pedantic, but to urge alignment with established conventions. This should help avoid reinvention of proprietary concepts.

As a side note however, flex actually does fully support gap. You should give it a whirl.

[Profesor08]

@dick-jo

As a side note however, flex actually does fully support gap. You should give it a whirl.

For browsers with max 2 years old. Not all users has devices of 2021, 2022 years.

[swordfest]

@dick-jo If we talk about standard conventions and layouts, I think we should include sizes adjustments like width: auto, fixed or 100%... Elements that Figma includes as Fill, Hug, Fixed

[scarnation]

Since its open source, i believe the next step technically is to see how the code is currently structured and also hear from the code maintainers just in case they are currently working on this feature already. If not so we can see to contributing code, documentation or design towards implementing the feature to the project

[swordfest]

@scarnation I checked the dev blog and I can confirm there is a dev working on this few weeks from. Ge even posted some gifs or videos to show us a sneak peek

[reinhart1010]

The following nomenclature specimens are good examples of where Figma's terminology creates problems.

And this would be bangers with official support for flex-wrap

[Alotor]

Hi, we're working in this feature right now but, as you can expect, is a complex one so it will be a while.

I posted an update some time ago if you want to check the progress.

https://community.penpot.app/t/autolayout-sneak-peek/153

I'll close this issue but feel free to add new ones if you feel like there is missing features.

Thanks for your support.

[jdittrich]

re: Terminology discussion: It is also possible that figma’s terminology easier to understand for many designers. W3C is rightfully concerned with specification and making their terms expressible in CSS, not primarily in being easy to imagine or to talk about (If these would be their primary concerns, they might produce ambigous specs, which is worse!)

For example, figma uses…

• direct references to space (horizontal, vertical, top)
• multiple words that are not hyphen-constructs (which are harder to put in CSS and tediuous to type)
• direct terms for which W3C uses a syntax-based abstraction (which would be terrible to talk and think visually about)

[dick-jo]

I completely understand where you're coming from @jdittrich but here's my issue, and I think it's a really big one that nobody is talking about: Learning and understanding proprietary design tool methodology and terminology has become equivalent in terms of learning cost/effort to simply learning how to actually code these things up for real. If not moreso.

Moreover, we now have issues like this: https://forum.figma.com/t/frame-size-appearing-as-hug-x-hug-instead-of-w-x-h/21355/24 where developers are left scratching their head trying to decipher design tool language.

Consistent language based on how real products actually work and are actually built bridges the gap between designers and developers in a very profound way. These tools are so mature that the amount of effort put into learning design tools could easily have made many designers very capable developers also, but both worlds are completely siloed behind (to my eye, purposefully) obfuscating terminology.

[jdittrich]

Consistent language based on how real products actually work and
are actually built bridges the gap between designers and developers in a very profound way.

A visual tool can't nor should work the code of what is produced at the end, just like writing a script is not the same as a film. People tried in the late 90s to create tools that 1:1 produced code with the result that neither code nor visual result were great.

The solution to your concerns of communicating in the same terms and understanding how code works, seems to learn HTML and CSS in code. This would be building a bridge, however, it is one that is crossed in merely one direction, towards the shore of the devs.

That the worlds are "siloed" is not due to teminology alone – design and development come from different professional traditions and this, among other things, leads to different values, practices and also terminology. This is why they work together, but are not the same.

[jcklpe]

I am a designer with a background in visual art. I think using the more consistent w3c terminology would be my preference.

But I am not fully bought in and used to the figma terminology. I know that blender struggled to gain traction until recently when in v 2.8 they switched to following a more traditional ui as found in other professional apps such as Maya.

The point that dick-jo is making I think is less that a design tool is capable of code but rather that ultimately many patterns in ui are ultimately arbitrary (in the same way that the rules of language are ultimately arbitrary in how they differ from one region to the next). The ui prior to blender 2.8 was fine. The change was good though because it eased people's transition between the commercial closed source to open source software. There are certainly issues to be considered here on both sides of the equation but I don't think it's as simple as saying that code and design are separate disciplines.