Captured the text here so we don't lose it in the email streams:
https://github.com/apache/royale-asjs/wiki/Styling-Improvements

a

Andrew Wetmore
Assistant VP, Marketing and Publicity, The ASF <https://apache.org>
Editor-Writer, Infra team, The ASF

Editor, moosehousepress.com


On Mon, Feb 9, 2026 at 12:32 PM Josh Tynjala <[email protected]>
wrote:

> Did you mean to post this to the Royale dev list?
>
> --
> Josh Tynjala
> Bowler Hat LLC
> https://bowlerhat.dev/
>
>
> On Mon, Feb 9, 2026 at 7:54 AM Gabe Harbs <[email protected]> wrote:
>
> > I’ve been spending a lot of time thinking about how to improve styling
> > capabilities in Royale. I have some ideas and I wanted to get others’
> > thoughts.
> >
> > Styling HTML is probably one of the big pain points.
> >
> > Tailwind CSS has solved the problem very nicely, but there’s some
> problems
> > with Tailwind:
> >
> > 1. Getting the Tailwind CSS generated for a Royale app. Tailwind is built
> > to read HTML, find the classes and populate CSS at build time. That
> doesn’t
> > fit perfectly with the Royale build process.
> > 2. You need to “know” Tailwind to specify the utilities. There’s no easy
> > way to get code completion in MXML etc.
> > 3. It doesn’t mesh perfectly with the Royale architecture of getting
> > functionality and styling.
> >
> > I was thinking:
> >
> > The big advantage of Tailwind is that it makes it very easy to compose
> CSS
> > functionality using a lot of small utility classes and only the classes
> > used will be used in the end result.
> >
> > We have a very similar concept in Royale: Beads.
> >
> > That set me thinking about how we can accomplish the same thing in Royale
> > and here’s what I’m thinking:
> >
> > - I want to create a new component set (I’m thinking of calling it
> “Style”
> > which would have a large set of styling beads.
> > - Each bead would encapsulate a specific function in CSS.
> > - We already have the ability to add CSS classes dynamically
> > - There would be a global utility class lookup
> > - Each time a utility class (in a bead) is applied, the class will be
> > checked against the lookup and dynamically added if it doesn’t exist.
> > - There would be a standard naming convention for the classes so each
> > utility which does a specific thing would be created exactly once.
> >
> > The end result would be that all the CSS would be completely dynamic and
> > would not be needed to be added to statically loaded CSS files.
> > - The actual code for creating the CSS should be quite concise and barely
> > add weight to the app.
> > - I have no done profiling on dynamically added CSS stylesheets, but I
> > think it’s very performant.
> > - CSS would be lazy loading which could further improve load times.
> > - It should certainly add less weight than constantly declaring inline
> > styling as is currently very common.
> > - Using stylesheets might be more performant. (Not sure about that.)
> > - Using stylesheets give much more flexibility for styling
> > - It addresses pain points like hover behavior.
> >
> > Thoughts?
>

Reply via email to