I did mention it in my original post that I was getting it the moment I group two elements. And that error won’t go away until I ungroup them. Even if I click on the error in the error box, it doesn’t show any measures to be taken etc.
More than this I am not sure what exactly is causing it. Don’t know if it comes on grouping certain types of elements etc. I can share my editor if required.
I had given a screenshot. That may probably help coders as they can check when does that error come?
Hello again everyone. I released another video just now in which I build an entire signup page from scratch using the new responsive engine. You can watch it on YouTube here: https://youtu.be/Okobpne9v-E
The page that I build in the video was modelled after this image that I found on Dribble
@nick.carroll Third party elements, like tables, charts, icons and so on, are randomly taking a 0px height. They also don’t seem to adjust to alignment rules. I urge you to make this a priority.
Nice! I was thinking the Align to Parent layout mode might be good for that as well as various “dashboard-like” layouts, since elements can basically be “pinned” to various locations around the edges of the container.
Seems like the new layout engine brings a ton of flexibility with respect to how to achieve a given UI.
We’ve identified the case of the errant “Group X is not a possible option” issue in the issue checker.
The default horizontal alignment for a new container in a column parent container is stretch to fit - however, if the group that is added in has a fixed width, this option isn’t possible and an issue is raised. We are updating the default alignment as a fix, but in the meantime, just toggle the child container’s horizontal alignment and the issue will go away.
Is it just me. or does the naming of row and column containers backward. When I create a column container, my instinct is that the content organises in columns (ie horizontal). When I create a row container, I expect the content is going to organise in rows (ie vertical). I assume its based on the fact a column will scroll as a column and row as a row, but if you’re not doing real scrolling you don’t even necessarily think of this. I’ve only just realised that so much of my frustration has been cause I keep getting this wrong.
My other biggest learning point to date is I used to put everything in groups because you had to use groups to collapse elements, etc. I was initially frustrated that components didn’t sit within groups like they used to. Once you realise that you only need groups for actually doing grouping stuff, it all starts to make a lot more sense, and it is definitely the right way to have approached this.
Brilliant! I did not notice this…
FYI- I have been coding for over 40 years in too many languages and frameworks to remember, and never experienced such a great environment. Thank you.
Here goes the question of the month . When do you think the responsive engine will be out of beta so we can really convert our apps into the new responsive?
Have not viewed any videos. Sorry. Personally, I derive much more benefit from tinkering.
I generally set out with a specific UI (layout and behavior) that I need and then try to create it using various approaches. There’s often more than one way to achieve a given layout for a specific screen width, but each might respond differently at other widths.
That said, as you noted, it’s beta software, so things will evolve and improve. The best we can do at this point is provide feedback and submit bug reports.
Still experiencing issues with the new responsive engine and how it works/doesn’t work with custom CSS.
I submitted a bug report with a video that demonstrates and explains the issue.
Bug report #18046
In the video and editor I have a page with three different versions attempting to get the behavior I want using the new responsive engine to exemplify the problems. There is another page with the old engine in use with the same setup of custom CSS to show how it should behave to exemplify the bug in the new engine as well as reiterate a feature request of a checkbox on a container element that would be to ‘enable scroll on overflow’ to avoid the need for the custom css all together.
The issue seems to be that a parent element in the new engine is not able to contain all the child elements when the child elements contents requires more height than what is set on the container as a max-height or a max-height setting using custom CSS.
The thing to keep in mind is that the terms “row” and “column” refer to how the contents of the container are arranged. The parent (container) controls the children (contents).
So, items inside a “row” container try to arrange themselves “in a row” and wrap vertically if they don’t fit horizontally. Conversely, items inside a “column” container try to arrange themselves “in a column” (stacked).
Maybe this will help somewhat…
That’s just the beginning, though, because each child also has its own layout controls to allow its alignment along the opposing axis to be adjusted as well. IOW, items inside a row container can each have their vertical alignment tweaked even though they’re collectively aligned horizontally, and vice versa for items inside a column container.
Yeah, what @jared.gibb says; although I would refine that statement slightly by changing the last two words to “width decreases”.