How are (and where are) the container width sizes being set? Unlike images I don’t see anyway to set a width (as px, %, rems, size value, etc), and nor do I see anyway to set the max-widths. I noticed it as when I resize the viewport containers we jumping to set (yet unknown) breakpoints causing the content to jump in size when set as a percentage of the container width.
The Container Component widths are set in the Screen Studio, these are your site breakpoints.
If you need to set an exact width for some content, you can use the very flexible “Section Component”.
I hope that’s what you’re after and I got it right 
Yup, the Screen Studio is what I was looking for.
As for the Section component… I’d much rather be able to have similar controls on the Container component. Why have two very similar components with very different properties? A Section is still a container - what’s special about a Section that it needs it’s own component?
2 Likes
For sure, it’s all doable, it was a design choice we made to separate them out. Ideally you just use a container when you want to restrict content to the breakpoints, in all other cases you use the more flexible Section. Having said that, this kind of feedback is exactly why we wanted to open get the beta out, so we can have feedback on these nitty gritty details — this is good stuff.
I’ve cc’d in @bon here to get his thoughts on it. Stay tuned!
2 Likes
One thing that would be handy would be to include a ‘Dimensions’ setting in the Theme Studio that would enable you to provide named values such as image-max-width: 50%, profile: 320px, content-width: 42rem, etc that could then be used whenever a custom value is declared.
Also, the ‘Text Style’ setting label should probably be changed as all of the values contained within it have more to do with type metrics and sizes (line height, letter spacing, font size, etc. than style (the only property related to style there is conceivably ‘weight’, but even that is still more metric oriented).
The more I look at it, the more I’m starting to wonder if the Theme Studio settings need to be revisited and refactored a little to clean things up, and ensure logical groupings and consistency. I keep looking at Pages styles, layout, etc panels for inspiration.
The main thinking behind this is to keep each Component focused on its own task.
To flip your question on its head: Why have all the Section settings everywhere when you just want to contain your content to the specified container widths? 
I am still 50/50 on the best approach here - I can see both being beneficial, and if most users are finding the correct approach confusing then we’ll definitely update the Section to include the Container widths (this could mean the Container becomes obsolete).
Or the Section component becomes obsolete. 
You have the semantic tags available in the advanced area of the properties to turn a container into a section, division, aside, or whatever type definition a user wants to add to the container. I would also move that to the top of the container properties list instead of the advanced section at the bottom, indicating that the user is free to use whatever type of container type they want in that one component.
Bonus points for updating the component type label in the node list and viewport to match.
My thinking here is that if you have one base, but very flexible container component that the user can define as they wish, then it becomes unnecessary to burden the user with additional container component types where they then have to understand and choose when and where they would use each one.
This is an interesting one 
Tailwind ships with defined widths, max widths, and min widths. We don’t currently have a component control that exposes these widths (we have a sizing control with auto | full | screen | custom), but I did wonder how quickly beta users would pick up on this!
Perhaps we need to add a more detailed control for widths that offer things like min/max widths, and allows users to pick from the predefined widths that ship in tailwind 
We could also add a “Widths” area to the Theme Studio. I just wonder how often you would actually be needing to customise these widths: How many custom/one-off widths (aside from the Container widths) do you typical use on a site?
And, thinking out loud here, another option is to create Globals from the already existing Core components and specify a custom width via the sizing controls.
E.g: if you wanted a Section that was 42rems you could:
- Drag in a Section
- Set the width to
customand then enter42rems - Right-click the Section and create a global
You now have a reusable Section with a width of 42rems. I think this would be my approach if I needed one or two sections at a specific width.
You can also take the same approach for images - add an Image, set a custom width, create a global. Then you can just override the resource drop well for unique images, but still keep your custom image width.
Another option is to use the “CSS Classes” in the Advanced Controls for each components - you can always use Tailwind’s arbitrary values feature to enter a “one-off” value.
Not saying we won’t add this; if we find it’s causing everyone frustrations then we obviously will. We do, however, have to be careful about how much we add to the Theme Studio as it can complicate things
2 Likes
From someone who’s only had the beta 24 hours, the most confusing thing for me is the relationship between, and uses of, Containers, Sections, Flexes and Grids.
Coming from Wordpress it’s way more confusing than just having simple elements with all the necessary properties.
For example, if I just want to place an image in the centre of the page I can’t do it with an image component (assuming alignment would be considered a property of the parent).
In WP I just drag an image in and centre it. In Elements I have to decide if I need a container to respect responsive widths (which also can’t centre), then have a flex, flex item and image component and go through various properties to find the right ones.
Don’t get me wrong, it’s awesome to have so many options but it is very confusing when working without a rope (tutorial).
Despite the confusion and some frustration, it’s easy to see how great this will end up being.
If I’m doing it all wrong don’t worry, I’ll be smarter tomorrow
2 Likes
Yeah, to be honest I’m at the point where I don’t want all of the various container choices (container, section, flex + flex item and grid + grid item), but rather one container with the option to define it’s behaviour (block, flex, grid, etc).
In terms of flex and grid, it can be assumed that any elements that are direct children of the flex or grid component are flex items or grid items. Having yet another container type to define flex items and grid items only complicates things. If I want to organize things within a container using Flexbox or Grid I can choose to add my own container if necessary. As it stands, flex item and grid item aren’t even listed in the component library and are only available if you create a flex or grid container in the structure view.
For me the base block elements/components would be:
- button
- container (can be set to block, flex, grid, etc, as well as a semantic type if desired; article, section, aside, main, header, footer, nav, etc. - otherwise div.)
- heading (can be set to h1…h6)
- image (supports both svg and png, jpg, gif, avi, webp, etc, as well as media queries and src alternates)
- paragraph (see my post here)
- audio/video
- quote
- table
- frame/embed
- form, form inputs (checkbox, radio button, field, etc)
Having too many container types really muddles and confuses things. Also, these are the common things people will expect to see within a WYSIWYG web editor.
2 Likes
Totally agree. 
Like a good old song said « I can’t keep it in, I’ve got let it out » 
One more step and we will soon think Dreamweaver 
yeah I know I leave again 
I can see how this will work if after dropping it in the canvas a dialog pop-up is initiated requiring a decision of what kind of container it should be. Leaving it neutral without the prompt requires a non-coder to know what the container types are and when to use them.
I believe this app should be able to accommodate the non-coding community without fuss. The more complex features should there, but not necessary to build a top-notch website. IMO this is the hardest part of building an app.
1 Like
The rest of this I totally agree with. K.I.S.S. Keep It Simple Silly.
I don’t think a pop-up is necessary, as ideally you drop a container into the page/viewport and then edit its’ properties as you wish using the properties inspector. If you want it to be a grid, select grid. If you then decide you want a flex layout, choose flex - but it doesn’t require you to make that decision first, either via the component library, or via a pop-up.
Chances are users will become very familiar with what properties core components have as they will be using them often. Throwing in a pop-up to select the type, only slows things down as they’re likely moving to the inspector anyway to set padding, width, margins, background colours, etc.
I completely agree with you that this app needs to focus on the non-coding community, period. The fact that you can add more complex features if you wish is a plus, but it shouldn’t be the default.
How does a non coder know what to select and where to find the selector?
We are tracking in the same direction here.
1 Like
Quick mock-up of an inspector for the Container component/element.
In the Inspector you could present the user with ‘Container → Layout → Format’ controls which allow them to set the format type to None, Flex, Grid, etc. Of course each selection would provide a different set of applicable options below (ie; Direction, Gap, etc).
Whether Layout should be the first or second segment/tab is worth considering here, or maybe the format grouping is placed in the style segment/tab as you don’t necessarily want to introduce additional hoops for the user to jump through.
2 Likes
Ok heart on sleeve here with this reply. I’m the perfect user candidate. I’m not a coder. I have struggled with the Container, Section, Grid flex options for a few days now. I finally got a four card grid working, but if you saw the struggles I had getting it, WOW. Haaaaa. Well, I’t’s just me I’m sure. Hopefully as the beta’s continue I will get a better handle on it. I really like what I’m seeing so far and I’m sure the refinements will make the difference.
3 Likes
This was my concern. Since you shared this, would you mind detailing what you struggled with? Please try to put into words the thoughts and conceptions you had during the process. It would help us potentially direct our thinking for a better workflow. You are exactly the type of personal feedback we are looking for!
1 Like
Hi Flash,
I will try, The biggest issue I’m having is learning how to nest the components. then trying to align the items in the components. I keep trying to align the actual text object and such. But the alignments are in the flex items, grid items, grids and sections and so on. Coming from the work processing world this new way of thinking is different and must be learned. It really is the nesting of things. I could see a complex layout getting hard to follow. Here is an example of an alignment issue. I was looking for Left, Center and Right. Only to find, Auto, Stretch, Start, Center, End. Since I did not see left I assumed there was no left. Finally I tried Start and that left aligned my Flex item. Ugh. Anyway it is those kind’s things that are unusual for non-coders.
Ken
2 Likes
Thank you sharing. This is definitely a legit issue. This is a CSS issue not a Realmac issue. To RM’s credit they are using industry terminology, however, it is not intuitive to the uninitiated. Thanks again, and if you have more to share, please do!