Problem
Right now, styling an element seems to have two paths:
Add a class
Good for reusable styles, but not ideal for one-off changes because the user needs to manually create or choose a class and make sure it is unique.
Style inline
Good for quick unique styling, but it becomes limiting when you need responsive changes, hover states, or small tweaks only on a specific device.
Proposed solution
Maybe there is room for a middle option here: scoped/local element styling.
The idea would be that the user can style a specific element without manually creating a class, but internally the builder could still generate a unique selector/class for that element. This would keep the UX simple, like inline styling, while still allowing responsive styles, states, and cleaner CSS output.
For example, instead of the user having to create something like hero-title-mobile-fix, the builder could handle that automatically behind the scenes.
Not sure what the best UX would be, but I think this could be worth exploring because it solves a real friction point between reusable classes and quick one-off styling.
Alternatives considered
Inline styles still have benefits and probably still make sense to keep somewhere in the workflow. They are simple, direct, and useful for very small or temporary changes.
That said, for most production use cases, especially on larger pages, relying heavily on inline styles might not be ideal. It can make caching, CSS optimization, responsive styling, and long-term maintainability harder.
Maybe we shoud also think about how the styles can be even more optimized by generating CSS per device/breakpoint, with the option to inline (via <style>) only the above-the-fold or critical CSS. This could keep the output optimized while still allowing better responsive control than pure inline styles.
So maybe the question is not whether inline styles should exist or not, but where they fit in the styling system, and whether scoped/local CSS could become the default for most visual styling.
Area
None
Problem
Right now, styling an element seems to have two paths:
Add a class
Good for reusable styles, but not ideal for one-off changes because the user needs to manually create or choose a class and make sure it is unique.
Style inline
Good for quick unique styling, but it becomes limiting when you need responsive changes, hover states, or small tweaks only on a specific device.
Proposed solution
Maybe there is room for a middle option here: scoped/local element styling.
The idea would be that the user can style a specific element without manually creating a class, but internally the builder could still generate a unique selector/class for that element. This would keep the UX simple, like inline styling, while still allowing responsive styles, states, and cleaner CSS output.
For example, instead of the user having to create something like hero-title-mobile-fix, the builder could handle that automatically behind the scenes.
Not sure what the best UX would be, but I think this could be worth exploring because it solves a real friction point between reusable classes and quick one-off styling.
Alternatives considered
Inline styles still have benefits and probably still make sense to keep somewhere in the workflow. They are simple, direct, and useful for very small or temporary changes.
That said, for most production use cases, especially on larger pages, relying heavily on inline styles might not be ideal. It can make caching, CSS optimization, responsive styling, and long-term maintainability harder.
Maybe we shoud also think about how the styles can be even more optimized by generating CSS per device/breakpoint, with the option to inline (via <style>) only the above-the-fold or critical CSS. This could keep the output optimized while still allowing better responsive control than pure inline styles.
So maybe the question is not whether inline styles should exist or not, but where they fit in the styling system, and whether scoped/local CSS could become the default for most visual styling.
Area
None