Hi Alex,
2018-03-08 23:06 GMT+01:00 Alex Harui <[email protected]>:
> Hi Carlos,
>
> I don't doubt that SASS is powerful and useful, otherwise it wouldn't be
> popular. What I am asking you to consider is that every decision you make
> affects a lot of people and we only have a relatively small team.
Maybe you missed what I wrote at the beginning of this discussion. Use SASS
doesn't means anything for the rest of the project.
Let's compare with a PSD vs an img. Imagine I author a PSD to create a
button image background. Then I can put only the final PNG
in our framework to use it by a css and optionaly put the PSD I used to
author the final PNG in some source folder so people can use it.
This is the same. SASS is the PSD and CSS is the PNG. The important thing
here's that I'm using SASS to be more productive,
and I'm producing a final "defaults.css". I can remove all SASS files and
configurations and work it on my own, but I think people would want it
In the other hand, people that don't want to use are not obligated, since
they can use the final "defaults.css" as its template to create his own
theme.
For me is just a matter of convenience since I can code the visuals in a
more organized way, just like I were coding AS3 vs JS. We use AS3 and not
CSS for the same reason people use SASS over CSS. It's more easy, can catch
errors, and you are more safe of what you're doing.
> So the
> first question I have is what is there about the current Royale feature
> set that makes it truly impossible or impractical to implement a CSS-based
> theme and generate flavors of it with other CSS files? If you push for
> SASS that means we have to impact all of our non-Maven users by asking
> them to integrate SASS somehow, or do more work on the compiler. We can't
> just make everybody use Maven and SASS. That won't help us gain users and
> successful migrators.
>
I tell you in various emails this days. My problems are more in the post
processing of CSS by the royale compiler.
There's still sume rules that we don't allow, and that is limiting me since
I need to workaround.
I thought about solving it in the compiler, but after trying it, I continue
to be not able to solve it myself.
In the next "step", the main problem is how to make colors configurable by
the final user.
The way other frameworks do is the following [1]. They have all
combinations of css colors in a final minified file.
We can do this better by creating the palettes and creating the CSS on the
fly as people compile the Royale App.
The input will be 2-3 colors passed by ANT or Maven, the output for jewel
should be for example
"royale-jewel-${primary}-${secondary}-${accent}.min.css"
or if we create one with gradients then six vars ${primary1}, ${primary2},
${secondary1}, ${secondary2},...and so on
But please, if we do this, it should not be planned as a few hacks here and
there. For me this should be part of something
like the targets rework you did some months ago. Where you need to
introduce it in all its complexity.
This is the same, and what we get from this is a huge reward since we'll
have a great theme support that will people start to consider
Royale in real apps since we can provide them with a UI set that is usable
out of the box and match colors in their brands. They can choose how their
apps
looks from the beginning. Right now they can since we are providing basic
theme, or MDL, that makes them be stuck in the MDL namespace and what things
works in that external UI set.
> That's why I want you to provide a concrete example or two of what you
> can't do with the current feature set. And that doesn't mean by using
> MDL-style string substitutions or SASS-syntax. In the end, you want to
> start with a set of CSS files and have the final CSS to look like
> something. Royale has a way of doing that. Why does that way not work
> for you?
the "partials" (for taking SASS naming) is working in royale, so we have
already one thing.
That's ok, we need more on this, but we need now, or do you want I cross my
arms and wait
for this to be implemented? what should I do? I need to focus on Sketch, on
prototyping, on design, on coding visuals
that fills my time each day on Royale. I can't do much creating this
features in royale compiler, since I read that code and don't know what to
do
even with your Kindly explanations what I thank you for providing me, since
is time you're investing for me.
> Sure there might be better ways, like all of the CSS features
> you listed below, but why do our themes need to use them? Also consider
> that the more advanced CSS you use, the more work there will be to create
> a SWF equivalent.
>
The final css is the same you will make by hand, so if SVGs are not
supported in SWF, this will no make a difference.
If linear gradients are not supported as well, again is the same...again
think in the PSD/PNG paralellims with SASS/CSS,
if SWF was not supporting PNG, the problem will not be that I author it
with Photoshop, is that we need Royale to make
it happen (support PNG in SWF)
>
> I think it will help the community more to understand the trade-offs and
> avoid using the latest, coolest thing so we don't have to expend as much
> energy getting it to work for non-Maven users.
>
>
We the things I'm doing, you don't need to wire SASS in ANT to see my work.
As I'm uploading generated defaults.css, you have the final css file,
ant a ANT build will retrieve this as in the rest of projects.
Hope this clarifies all this more and we could go to the real target that
is getting a better visuals in a UI set that I'm sure will
provide us more engagement for people out there.
Thanks
Carlos
> Thanks,
> -Alex
[1] https://cdnjs.com/libraries/material-design-lite
