royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <>
Subject Re: Trying to remove "style" attribute set by Royale. First let's focus on style="display:block"
Date Mon, 12 Mar 2018 10:22:25 GMT

I see we have very different ways to how we see royale. In the end I see
Royale like you, but I care about the output we get in HTML in concrete,
since is different than the code we can produce in other outputs like AS3
(and maybe some day in Java, Swift,...). HTML is what is delivered to the
final user, the rest not since are compiled to bytecode and are not as
inspectable as HTML.

anyway, I think is good to have different points of view but with care so
the positions could co-exists.


2018-03-12 10:55 GMT+01:00 Harbs <>:

> > the frameworks I'm watching are MDL, Semantic and Bootstrap (all top
> > frameworks) to see what they do in different cases and guide me to find
> the
> > best way to implement the HTML Jewel should output in royale in Royale.
> All
> > of this frameworks are only HTML/JS/CSS (not builds from other code),
> but I
> > think that's not the point, since in the end both build front end
> > interfaces with controls and layouts
> It’s very much the point. These are all frameworks which attempt to enable
> a *document markup* (i.e. HTML) to be styled. Sure people use this for web
> apps, but it’s an abuse of what HTML was originally designed to be.
> The way I see Royale is an *application framework* which simply uses HTML
> and browsers as a *rendering engine*. Our goal isn’t and *should not be*
> pretty HTML markup. That’s only important if you are *writing HTML
> documents*. The strength of CSS is that it allows the styling to be
> divorced from the documentation and content. That is *not* an important
> goal for application development. It *is* important for (a subset of)
> applications to be easily skinned, but CSS files should be a means (if
> necessary) and *not* a goal.
> > So are you telling me that our output is better than theirs? That our way
> > of put somethings in the own html markup is better than theirs? I don't
> > think so, since they do the same but with better results: better
> optimized
> > and less weight html code.
> Yes. CSS lookups are inherently inefficient. “Pretty” HTML markup is *not*
> optimized. If CSS styling is not inlined, the browser must look through
> (sometimes quite complex) lookup tables to figure out what the styling
> should be. The fact that browsers can execute CSS lookups as quickly as
> they do is quite amazing.
> > In the other hand, you are telling me to write a bead to override or
> > correct something the framework is hardcoding? I suppose you are
> referring
> > to a bead that removes all styles hardcoded, so that doesn't strikes out
> my
> > CSS styles... I think that's not the way to solve this. If I were making
> an
> > App maybe that's could be the solution as a workaround, but we are
> > framework developers, not users.
> I think that any properties in a theme which can only be specified using
> CSS files should have any inline css zeroed out by a bead. I would look for
> ways to have the values inlined though. Possibly the themes can be
> swappable beads which overwrite styles? Don’t know...
> > I think that solution was good to start with, but now it demands to
> > refactor to something better.
> >
> > Harbs, are we trying to make the best framework out there? I think this
> > concrete point will make people reject us when they started to see the
> html
> > we product all bloated with styles, when that's not necessary and can be
> on
> > a "first level" CSS that be part of the lib code (not a theme) and be
> > included always. I think that's the right solution and we'll get the same
> > we have now but in the right insertion point.
> I really don’t think that’s true. If you are talking about people who
> *like* writing HTML, they’re not going to want to use Royale anyway. To me
> a big part of the attraction of Royale is that I can avoid (for the most
> part) writing HTML in my app. The attraction is MXML and ActionScript files
> and avoiding complex HTML and CSS files.
> Again: Default inline css can easily be overwritten (or zeroed out) in
> beads for cases when it’s needed. I see no need for major changes to the
> architecture.
> My $0.02,
> Harbs

Carlos Rovira

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message