> 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

Reply via email to