UI designer and front-end developer with over 20 years of experience here! 😊I always enjoy watching your videos and truly appreciate the effort you put into them-great work! This particular approach reminds me of how I've built front-ends for most of my career. Interestingly, I've recently started going in the opposite direction, using more flexbox to handle these kinds of situations. That's what I love about front-end development-there’s rarely a "wrong" approach. It’s all about finding the method that works best for achieving the desired results. Keep up the fantastic work!
Hello Tim, Great work on Lumos; it’s been incredibly helpful for building in Webflow! 🎉 I’ve run into an issue with the new margin trim feature in page_code_base related to absolute positioning. I have two absolutely positioned elements within a parent div: • Element A is a full-width image positioned below Element B. • Element B is a smaller div, 1/3 the size of Element A, meant to be centered with auto margin on all sides. However, the margin trim prevented auto margin from applying correctly to Element B’s top, causing it to stick to the top of the parent. I had to add u-margin-trim-off to the parent div for auto margin to work fully. I believe this margin trim behavior might confuse new users trying to get familiar with the framework. Thanks for considering this feedback. Cheers!
Hi Timothy! I've been using Lumos since the first time it came out. Today I've once again started a project, but i was the first time Lumos did not feel intuitiv or common anymore in a while. So i looked up your recent uploads and came here. I always appreciate the changes you make to Lumos and I really feel that most of the time your deciding on what's best for the framework. However, this time i cannot get behind the new changes so i would really appreciate another video or explenation to these: 1. Why did "we" go back to applying margins to the text classes? 2. Why did you decide to remove the Paragraph and Heading Component again? 3. I really think the whole Gap and Flexbox utilities are quite hard to understand, what are the real upsides here? 4. What do the CSS Variables "Column Margin" do? Please don't get this as just critics because there have been changes. I really appreciate your steady work on the framework. But as someone running an agency using Lumos for all new Builds the v2.0.5 just felt a little weirder to built with for me.
Hi Leon, Thank you for using Lumos and for this valuable feedback! I'm sorry the reason for these changes wasn't better explained. 1. Margins save time by making spacing automatic. They allow us to apply consistent default spacing to elements and easily update that spacing globally when needed. Imagine having to change the bottom spacing on all subheadings globally when using flex gap or spacer divs. With margin when we add any element to the page, we don't have to remember the spacing value that should be used with that element. And if specific spacing is needed in certain cases, margin utilities can easily override the defaults. I avoided margins for a while because they didn't work with conditional visiblity, but the new global margin trim solves this problem. This video covers the benefits of margin in Lumos. www.linkedin.com/posts/timothy-ricks-413668140_it-took-me-far-too-long-to-realize-this-activity-7251194755856961537-Lwri? 2. The Heading & Paragraph components added extra divs and friction. Instead of being able to apply a custom class directly to the rich text, we had to add it to a parent div of a rich text. In some designs where the style of the heading accent words change between section types, having the headings locked into a component made changing the children styles difficult. 3. If we apply a style to a class, Webflow includes that css on every page of our site, even pages not using that class. By reusing utilities for common styles like flexbox and gap, we're able to keep our global css light and clean. Also with practice, applying utilities is often faster to build with instead of manually clicking through the style panel. 4. With display grid, we have to manually reduce the grid column count on each breakpoint to prevent the gaps from causing overflow. The column-width and column-margin variables solve this by allowing us to align elements on our grid guides without applying display grid to their parent. Applying margin right to an element of column-margin/3 would push it over by the size of 3 columns + 1 gap (making it start on the 4th column). Setting an element's width to column-width/3 would make it the size of 3 columns. I know these are big adjustments. If there's anything specific that continues to feel weird after some use, please let me know so I can improve it. No change is made unless it comes with big workflow improvements or solves an important problem.
Hi Timothy, Could you explain why you use top and bottom margin? Could you not just use bottom margin for everything? Im sure there is a reason but I dont see it 🙂
I got a reply from Timothy on Linkedin - These same margin values are used in rich text also for consistency. Larger top margin on a heading keeps it separated from any paragraph above it. Top margin on a paragraph keeps it separated from any image or other content above it.
It’s a different way to work for sure, but I’m already seeing big benefits which I should probably cover in a future video. Child flex alignment can be set to inherit as long as the flex direction matches the parent. So flex align inherit wouldn’t work on horizontal button wraps.
@@timothyricks Further to below comment, just been thinking about this. I really would not want any default margins added to elements in future version of Lumos. Unsure if that's on the cards or not but I love the 'reset' nature of atom elements currently.
@@timdaff Thank you, Tim! I already started working on default margins, but I don't take your feedback lightly. With margin trim enabled automatically and with parent text style classes clearing the styles of their children, we shouldn't notice a big difference between this update and the current workflow. I could even create a utility that enables the old reset if you think it would help. The goal of this update is to make styling more automatic with page building mode coming and to allow for global style updates. Currently for instance if we want to increase the bottom spacing on every subheading throughout the site, it's a very manual process because gap doesn't allow for these global updates like margin does. www.linkedin.com/feed/update/urn:li:activity:7251194755856961537/
@@timothyricks Thanks for the detailed response, apologies for only just seeing it now. I've got a new Lumos build about to kickoff. Taking a look at your linkedin too! Hope you enjoyed / are enjoying Webflow conf!
Hello, Timothy! First of all, thank you for everything you do. I have a few questions regarding Lumos, and I would really appreciate your answers. For example, I have a div with the class hero_wrap, and I’ve added utility classes for h-flex and gap. Now, if I want to add some CSS that Lumos doesn't have in its utility classes, like a transform rotation, is it better to go back to the hero_wrap class and add that CSS for the transform, or can I simply add that CSS while the utility classes are still applied? Which is the better practice? Why is there now a text-wrap: pretty on paragraphs in the latest version, but there is no max-width in ch units in the component settings? As far as I know, text-wrap: pretty is not yet supported in Safari and Firefox. Is there something I'm not aware of? When we have a u-grid-custom that has a main layout of 12 columns by default on the desktop version, should we set it to 1 column at lower breakpoints, or can it remain at 12 columns? Will there be overflow issues due to spacing between the columns? If I have a slightly more complicated site with colors that may be difficult to set up with Lumos embeds for colors, and I want some custom complicated buttons, can I bypass Lumos colors by simply removing the CSS embed related to colors and manually set the colors through Webflow variables, like in Client First?
I have been using Lumos and can answer the colour problem to the best of my knowledge (not as good as Timothy lol) You can add new 'swatch' colours to Variables. For example, maybe dark-1, dark-2, dark-3, light-1, light-2, light-3 etc. Then also add new 'theme' variables like background-2 or text-2 what you need for your design. Then in the page 'Custom Code' page_code_color you can add and reference these new values for light and dark themes. If you need another background that is dark on both themes add something like --theme--background-2: var(--swatch--dark-1); to the light theme and --theme--background-2: var(--swatch--dark-3); to the dark theme. God, its hard to explain just in words lol. Does that help at all?
Hi, thank you for the kind words! Great questions! 1. It's best to apply any custom styles to the base class (hero_wrap) when possible in case any of the utilities need to be removed in the future or if more utilities need to be added later. With the Lumos Chrome Extension if you press the "shift" and "up arrow" keys, it will jump to the base class for easy styling. 2. text-wrap: pretty just ensures that the last line of text has more than one word on it. It's a progressive enhancement so for browsers that don't support it, nothing breaks. The styling just looks nicer in browsers that do. Text-wrap: balance isn't always ideal on paragraphs especially for long form content like blog posts because each paragraph starts to look like it has inconsistent widths. For a single paragraph like in a CTA section, the u-text-wrap-balance utility could always be added. Lately, I've been applying my max-width directly on the rich text element and not linking it to a component field especially for paragraphs because I notice my clients and team aren't taking the time to readjust the max-width when they change the copy. But that max-width could still be linked to a component field if you'd like. 3. Yes, we always want to reduce the column count of a grid on lower breakpoints because the gaps count as space and can cause overflow issues especially with an increased font size. The new column-width variables in Lumos allow us to avoid using grid all together in many cases, they don't have the overflow issue, and are easier to work with. 4. Yes, the color embed can be completely removed if you'd like, and you can apply swatches directly without going through themes. Themes can handle really complicated colors in an easy way if setup correctly though and have a lot of benefits. For multi-brand sites, the Lumos Brand Switcher can help. webflow.grsm.io/tricks?path=lumos-brand-switcher
I love these little hacks you share with us. Thank you! Isn't it sometimes frustrating to have to invest so much time to make simple layout adjustments like this by writing all these special rules? I wish we could make such things in Webflow much more intuitively and that an intelligent system would do these CSS tweaks intelligently in the background for us.
Thanks so much! Webflow is designed to be un-opinionated so it can work with any way someone might choose to build. I think that's a great thing because it allows us to add in different frameworks that handle these intelligent things in the background for us. I do wish Webflow would open up some of its restrictions around variables though. That would remove the need for a lot of custom code and allow us to make more things natively.
@timothyricks: Good point. I agree, and certainly see the benefit of this openness to different ways of setting up and organising this set of rules, and am very grateful for your wonderful contribution with Lumos :) Coming from a graphic design background and enjoying the freedom of programs like InDesign and AfterEffects for layout and animation, I sometimes dream of a program where it is possible to set up this set of visual rules in a purely intuitive way, without sacrificing (an obsessive) attention to detail. What a true no code web design tool would look like. After all, the design decisions we make as designers are primarily based on conceptual, visual and of course structural considerations like hierarchy and order. Personally, I would like to leave the translation of these decisions to algorithms and automated processes which turn them into the abstract languages of HTML, CSS and JS. I have to be honest and say that this may be due to my lack of understanding, but I have always wondered why these in my eyes "simple" capabilities of HTML, CSS and JS cannot be translated better and more intelligently into automated rules and actions. If I have any hope for AI, beside not completely f*cking up this planet, it is that it can provide this interface that Dreamweaver once tried to be. Sorry for that outburst, but it had to be said. A question for the crystal ball: Do you see a program like the one I describe coming in the near future?
Oh, I see! We’re already experiencing different tools coming out with various levels of abstraction. As a general rule the more abstracted a tool is, the more control we give up. I love digging into css and understanding all of the minor details because that’s my main focus. But if I was to create an animation, I wouldn’t want to understand all the complex details of after effects. I would want a tool that handles some of that stuff for me. So I think there’s room for tools with varying levels of complexity for experts, hobbyist, and others who just want something out quickly.
UI designer and front-end developer with over 20 years of experience here! 😊I always enjoy watching your videos and truly appreciate the effort you put into them-great work! This particular approach reminds me of how I've built front-ends for most of my career. Interestingly, I've recently started going in the opposite direction, using more flexbox to handle these kinds of situations. That's what I love about front-end development-there’s rarely a "wrong" approach. It’s all about finding the method that works best for achieving the desired results. Keep up the fantastic work!
This is genius. Thank you for the straight forward content.
Amazing! I love your videos Timothy.
Hello Tim,
Great work on Lumos; it’s been incredibly helpful for building in Webflow! 🎉
I’ve run into an issue with the new margin trim feature in page_code_base related to absolute positioning. I have two absolutely positioned elements within a parent div:
• Element A is a full-width image positioned below Element B.
• Element B is a smaller div, 1/3 the size of Element A, meant to be centered with auto margin on all sides.
However, the margin trim prevented auto margin from applying correctly to Element B’s top, causing it to stick to the top of the parent. I had to add u-margin-trim-off to the parent div for auto margin to work fully.
I believe this margin trim behavior might confuse new users trying to get familiar with the framework.
Thanks for considering this feedback.
Cheers!
Absolutely A-mazing!! Loved this!!
Hi Timothy!
I've been using Lumos since the first time it came out. Today I've once again started a project, but i was the first time Lumos did not feel intuitiv or common anymore in a while. So i looked up your recent uploads and came here. I always appreciate the changes you make to Lumos and I really feel that most of the time your deciding on what's best for the framework.
However, this time i cannot get behind the new changes so i would really appreciate another video or explenation to these:
1. Why did "we" go back to applying margins to the text classes?
2. Why did you decide to remove the Paragraph and Heading Component again?
3. I really think the whole Gap and Flexbox utilities are quite hard to understand, what are the real upsides here?
4. What do the CSS Variables "Column Margin" do?
Please don't get this as just critics because there have been changes. I really appreciate your steady work on the framework. But as someone running an agency using Lumos for all new Builds the v2.0.5 just felt a little weirder to built with for me.
Hi Leon,
Thank you for using Lumos and for this valuable feedback! I'm sorry the reason for these changes wasn't better explained.
1. Margins save time by making spacing automatic. They allow us to apply consistent default spacing to elements and easily update that spacing globally when needed. Imagine having to change the bottom spacing on all subheadings globally when using flex gap or spacer divs. With margin when we add any element to the page, we don't have to remember the spacing value that should be used with that element. And if specific spacing is needed in certain cases, margin utilities can easily override the defaults. I avoided margins for a while because they didn't work with conditional visiblity, but the new global margin trim solves this problem. This video covers the benefits of margin in Lumos.
www.linkedin.com/posts/timothy-ricks-413668140_it-took-me-far-too-long-to-realize-this-activity-7251194755856961537-Lwri?
2. The Heading & Paragraph components added extra divs and friction. Instead of being able to apply a custom class directly to the rich text, we had to add it to a parent div of a rich text. In some designs where the style of the heading accent words change between section types, having the headings locked into a component made changing the children styles difficult.
3. If we apply a style to a class, Webflow includes that css on every page of our site, even pages not using that class. By reusing utilities for common styles like flexbox and gap, we're able to keep our global css light and clean. Also with practice, applying utilities is often faster to build with instead of manually clicking through the style panel.
4. With display grid, we have to manually reduce the grid column count on each breakpoint to prevent the gaps from causing overflow. The column-width and column-margin variables solve this by allowing us to align elements on our grid guides without applying display grid to their parent. Applying margin right to an element of column-margin/3 would push it over by the size of 3 columns + 1 gap (making it start on the 4th column). Setting an element's width to column-width/3 would make it the size of 3 columns.
I know these are big adjustments. If there's anything specific that continues to feel weird after some use, please let me know so I can improve it. No change is made unless it comes with big workflow improvements or solves an important problem.
Great tutorial as always, Tim! 🎉
Do I have to manually add these codes on the cloneable or is it already embedded in the cloneable?
Thanks so much! They're already in the cloneable
Fascinating.
Hi Timothy,
Could you explain why you use top and bottom margin? Could you not just use bottom margin for everything? Im sure there is a reason but I dont see it 🙂
I got a reply from Timothy on Linkedin - These same margin values are used in rich text also for consistency. Larger top margin on a heading keeps it separated from any paragraph above it. Top margin on a paragraph keeps it separated from any image or other content above it.
Amazing. Are these already applied to the Lumos Style Guide Template?
Thank you! Yes, they are
@@timothyricks thank you Tim. I have 3-4 projects I want to use Lumos but I'm still learning all the goodies. Quite a learning curve.
I dunno if this is the death of flexbox but interesting work!
For the child flex-boxes alignment, couldn’t we just set to inherit?
It’s a different way to work for sure, but I’m already seeing big benefits which I should probably cover in a future video.
Child flex alignment can be set to inherit as long as the flex direction matches the parent. So flex align inherit wouldn’t work on horizontal button wraps.
@@timothyricksI’m still loving Lumos flex utils + grid + subgrid.
Will be keen to learn more on this new technique though!
@@timothyricks Further to below comment, just been thinking about this. I really would not want any default margins added to elements in future version of Lumos. Unsure if that's on the cards or not but I love the 'reset' nature of atom elements currently.
@@timdaff Thank you, Tim! I already started working on default margins, but I don't take your feedback lightly. With margin trim enabled automatically and with parent text style classes clearing the styles of their children, we shouldn't notice a big difference between this update and the current workflow. I could even create a utility that enables the old reset if you think it would help. The goal of this update is to make styling more automatic with page building mode coming and to allow for global style updates. Currently for instance if we want to increase the bottom spacing on every subheading throughout the site, it's a very manual process because gap doesn't allow for these global updates like margin does.
www.linkedin.com/feed/update/urn:li:activity:7251194755856961537/
@@timothyricks Thanks for the detailed response, apologies for only just seeing it now. I've got a new Lumos build about to kickoff. Taking a look at your linkedin too!
Hope you enjoyed / are enjoying Webflow conf!
Hello, Timothy! First of all, thank you for everything you do.
I have a few questions regarding Lumos, and I would really appreciate your answers.
For example, I have a div with the class hero_wrap, and I’ve added utility classes for h-flex and gap. Now, if I want to add some CSS that Lumos doesn't have in its utility classes, like a transform rotation, is it better to go back to the hero_wrap class and add that CSS for the transform, or can I simply add that CSS while the utility classes are still applied? Which is the better practice?
Why is there now a text-wrap: pretty on paragraphs in the latest version, but there is no max-width in ch units in the component settings? As far as I know, text-wrap: pretty is not yet supported in Safari and Firefox. Is there something I'm not aware of?
When we have a u-grid-custom that has a main layout of 12 columns by default on the desktop version, should we set it to 1 column at lower breakpoints, or can it remain at 12 columns? Will there be overflow issues due to spacing between the columns?
If I have a slightly more complicated site with colors that may be difficult to set up with Lumos embeds for colors, and I want some custom complicated buttons, can I bypass Lumos colors by simply removing the CSS embed related to colors and manually set the colors through Webflow variables, like in Client First?
I have been using Lumos and can answer the colour problem to the best of my knowledge (not as good as Timothy lol) You can add new 'swatch' colours to Variables. For example, maybe dark-1, dark-2, dark-3, light-1, light-2, light-3 etc. Then also add new 'theme' variables like background-2 or text-2 what you need for your design. Then in the page 'Custom Code' page_code_color you can add and reference these new values for light and dark themes. If you need another background that is dark on both themes add something like --theme--background-2: var(--swatch--dark-1); to the light theme and --theme--background-2: var(--swatch--dark-3); to the dark theme. God, its hard to explain just in words lol. Does that help at all?
Thanks so much, @@anenglishmanyoutube! That's exactly right
Hi, thank you for the kind words! Great questions!
1. It's best to apply any custom styles to the base class (hero_wrap) when possible in case any of the utilities need to be removed in the future or if more utilities need to be added later. With the Lumos Chrome Extension if you press the "shift" and "up arrow" keys, it will jump to the base class for easy styling.
2. text-wrap: pretty just ensures that the last line of text has more than one word on it. It's a progressive enhancement so for browsers that don't support it, nothing breaks. The styling just looks nicer in browsers that do. Text-wrap: balance isn't always ideal on paragraphs especially for long form content like blog posts because each paragraph starts to look like it has inconsistent widths. For a single paragraph like in a CTA section, the u-text-wrap-balance utility could always be added. Lately, I've been applying my max-width directly on the rich text element and not linking it to a component field especially for paragraphs because I notice my clients and team aren't taking the time to readjust the max-width when they change the copy. But that max-width could still be linked to a component field if you'd like.
3. Yes, we always want to reduce the column count of a grid on lower breakpoints because the gaps count as space and can cause overflow issues especially with an increased font size. The new column-width variables in Lumos allow us to avoid using grid all together in many cases, they don't have the overflow issue, and are easier to work with.
4. Yes, the color embed can be completely removed if you'd like, and you can apply swatches directly without going through themes. Themes can handle really complicated colors in an easy way if setup correctly though and have a lot of benefits. For multi-brand sites, the Lumos Brand Switcher can help.
webflow.grsm.io/tricks?path=lumos-brand-switcher
I love these little hacks you share with us. Thank you!
Isn't it sometimes frustrating to have to invest so much time to make simple layout adjustments like this by writing all these special rules? I wish we could make such things in Webflow much more intuitively and that an intelligent system would do these CSS tweaks intelligently in the background for us.
Thanks so much! Webflow is designed to be un-opinionated so it can work with any way someone might choose to build. I think that's a great thing because it allows us to add in different frameworks that handle these intelligent things in the background for us. I do wish Webflow would open up some of its restrictions around variables though. That would remove the need for a lot of custom code and allow us to make more things natively.
@timothyricks: Good point. I agree, and certainly see the benefit of this openness to different ways of setting up and organising this set of rules, and am very grateful for your wonderful contribution with Lumos :)
Coming from a graphic design background and enjoying the freedom of programs like InDesign and AfterEffects for layout and animation, I sometimes dream of a program where it is possible to set up this set of visual rules in a purely intuitive way, without sacrificing (an obsessive) attention to detail. What a true no code web design tool would look like.
After all, the design decisions we make as designers are primarily based on conceptual, visual and of course structural considerations like hierarchy and order. Personally, I would like to leave the translation of these decisions to algorithms and automated processes which turn them into the abstract languages of HTML, CSS and JS. I have to be honest and say that this may be due to my lack of understanding, but I have always wondered why these in my eyes "simple" capabilities of HTML, CSS and JS cannot be translated better and more intelligently into automated rules and actions. If I have any hope for AI, beside not completely f*cking up this planet, it is that it can provide this interface that Dreamweaver once tried to be. Sorry for that outburst, but it had to be said.
A question for the crystal ball: Do you see a program like the one I describe coming in the near future?
Oh, I see! We’re already experiencing different tools coming out with various levels of abstraction. As a general rule the more abstracted a tool is, the more control we give up. I love digging into css and understanding all of the minor details because that’s my main focus. But if I was to create an animation, I wouldn’t want to understand all the complex details of after effects. I would want a tool that handles some of that stuff for me. So I think there’s room for tools with varying levels of complexity for experts, hobbyist, and others who just want something out quickly.