incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Heidegger ...@leichtgewicht.at>
Subject Re: CSS
Date Sat, 03 Mar 2012 16:10:31 GMT
I have given CSS quite a bit of thoughts over time.

Practically speaking: CSS is a file format that allows to set many 
properties with various detail for a huge set of components with few 
statements. Specially when I new dialect like SASS is used it allows to 
set a huge bunch of properties types. In some way this can be seen as 
IOC descriptor! This is an awesome feature! But it also offers to change 
and safe the properties at runtime:

    - on instantiation: fill properties
    - on style-change within: set changed properties
    - on objects signature change: set changed properties

That is all closely related to a IOC Framework that offers things like 
auto dependency injection.

This has the awesome architectural implication that every module has to 
offer runtime-changable properties. Yeah: modules! ...

Now: That doesn't mean that the implementation is awesome. Compiling CSS 
to bytecode would certainly be a performance boost. But the bigger boost 
would be to make CSS processing optional: If one never uses CSS it 
should not be added. This would allow alternative containers to be 
faster while still utilizing the flexibility of the components. The 
problem is that right now MXML, UIComponent and CSS are hardwired. Those 
needed to be separated and that is tough. There are other engines that 
already are separate styling on a different level like Jakute[1]. They 
work on the basis of the onAdded/onRemoved event handler and I think 
they are a more usable approach within ActionScript. But you can be 
sure: Writing a system that does CSS updating (the 3 events above) 
efficiently (fast) is hard!

And just to be sure: You can/should not use the Flex CSS 1:1 when 
targeting HTML/CSS: The properties do not contain same values (font 
handling anyone) and that can result to quite some conflicts. My 
personal experience with HTML/CSS is that trying to control things 
related to styling within the code is likely to fail as there is always 
extra effort from the developer needed to clean out quirks.

yours
Martin.

[1] http://sibirjak.com/osflash/projects/jakute-styling-engine/

On 04/03/2012 00:18, Ariel Jakobovits wrote:
> I mostly used CSS in the mx days. Though spark skins with fxg are easy for designers,
CSS can be quicker for newbies, and is relevant to future HTML output.
>
> Thing is, I have found CSS styling to be a drag on performance. Any chance we can update
our compiler to apply stylesheets at compile time and perhaps even disable CSS styling at
runtime?
>
> Ariel Jakobovits
> ajakobov@adobe.com
> 650-350-0282
>
> On Mar 3, 2012, at 3:12 AM, sébastien Paturel<sebpatu.flex@gmail.com>  wrote:
>
>> Hi all,
>> Im new to the mailing list so sorry if i do mistakes :)
>>
>> I'm personnally very concerned about the ease of learning curve of Flex for new users.
>> Don't forget that the ease of use and power of this SDK suits to not only enterprise
scale projects. It will be more true when the cross compilation to HTML5 will be a reality.
>> I intend to create a new thread about this subject in the mailing list.
>>
>> But about Spark vs MX subject, i must say that MX components were very important
to easely learn flex, and new spark components were harder to use at first to do only simple
skinning, even if the flexibility made it more powerfull.
>> That said, Spark vs MX war has no sens since they refer to very different use cases
with pro and cons:
>> MX: Ease of use and quick simple skinning
>> Spark: Flexibility and power to create complexes skins and layout
>> We need both!
>>
>> We could say that when the Spark components complete list will be finished, you will
still have the possibility to choose between MX and Spark for your specific projects needs.
>> BUT: The main drawback for MX components is that you cant use them for Mobile!
>> Thats too bad to not have a simple quick way of skinning when working on Mobile projects.
>>
>> The fact that we oppose Spark and MX is only because of flex's history.
>> But you should consider a components list dedicated to use cases for which we would
have chosen MX components.
>> This NEW components library would be (not like MX) based on Spark components and
expose basic skinning attributes easely in MXML (as MX).
>> That way a new lib equivalent to old MX could be used for Mobile.
>> And when a developper is stuck by the limitations of skinning possibilities (like
he would have been with MX) he still can use the Spark base to freely do what he wants.
>> It should not be that much work to achieve that.
>> It must be carefully defined to manage Desktop and Mobile for easy skinning components.
>>
>> In Conclusion in my opinion:
>> Spark should be the base for all components from now on.
>> MX should die mainly because we cant use it for Mobile and it is not based on Spark
(that makes the SDK more hard to maintain).
>> A new components list based on Spark should replace MX for easy and simple skinning
use cases.
>>
>> What you think of it?
>>
>> Thanks for reading
>> Seb
>>
>>
>> Le 03/03/2012 03:02, Om a écrit :
>>>> So if paying for the flex Ide is their only revenue point, to say that the
>>>> mx components were badly written is false. They hit exactly the crowd that
>>>> they needed to hit with them. You may be happy with the spark components,
>>>> but that's when flex died, after they were introduced. When the little guy
>>>> was pushed out.
>>>>
>>> This.  I love the spark architecture, but that's because I have used mx
>>> exhaustively (pushing its limits) and I know all the pain points.  So,
>>> moving to the Spark architecture was a logical progression for me.
>>>
>>> But, this also means that new folks that start using Flex 4+ for the first
>>> time, dont have an easy entry point.  Changing the look and feel of an app
>>> - which was extremely easy in mx is now a chore.  I know and have worked
>>> with design firms that created new application styles using the 'Flex 3
>>> Style Explorer' - which was an online flex application.  Thats it.  Thats
>>> how easy it was to work with mx components.
>>>
>>> I dont know if the answer is better tooling (Catalyst, Design view, etc.)
>>> or if it is a question of more exhaustive documentation, working examples,
>>> tutorials, etc.  Or even a change to the way Spark approaches skinning and
>>> customizations.
>>>
>>> This kind of developer outreach (especially for newbies) should also be a
>>> goal for the Apache Flex project, IMHO.
>>>
>>> Thanks,
>>> Om
>>>
>>>
>>> On Fri, Mar 2, 2012 at 5:10 PM, Cortlandt Winters<cort@cortwinters.net>wrote:
>>>
>>>> Thank you, Micheal for a great response.
>>>>
>>>> I think what we have here are two radically different use cases.
>>>>
>>>> On the one hand flex needs to be a good enough framework that a team of
>>>> three can create something of real value on a 10-30 thousand dollar budget
>>>> in a few months. Without rock stars.
>>>>
>>>> On the other hand how can a  team of 100 which  was probably 10 times the
>>>> number of core flex developers, do world class stuff if the sweet spot is
>>>> for a team of 3-5?
>>>>
>>>> But frankly from Macromedia/Allaire and Adobe's standpoint, there are
>>>> probably a thousand times more users
>>>> in the first scenario than the second, maybe ten thousand more.
>>>>
>>>> So if paying for the flex Ide is their only revenue point, to say that the
>>>> mx components were badly written is false. They hit exactly the crowd that
>>>> they needed to hit with them. You may be happy with the spark components,
>>>> but that's when flex died, after they were introduced. When the little guy
>>>> was pushed out.
>>>>
>>>> I reiterate that there is not a single complete commercial spark component
>>>> skin on any marketplace after two years. Mx skins weren't in the 100's but
>>>> there were 30 or 40 attempts.
>>>>
>>>> Frankly, If you have a hundred developers, you had more than enough
>>>> resources to take the core as3 language and build your own framework that
>>>> covers this larger set of world class issues with a less feature rich end
>>>> point.
>>>>
>>>> I have no doubt that given this experience you are well suited to guide the
>>>> core framework internals in the future, but not if you can't recognize that
>>>> it's a niche case and that mx covered 95% of most user's needs.
>>>>
>>>> Most projects can't create components for the project. Most projects use
>>>> components to build the project. That's why they are called components.
>>>> They are reusable. Most projects are focused on the content and use the
>>>> components to display the content.
>>>>
>>>>
>>>> On Fri, Mar 2, 2012 at 9:36 AM, Michael A. Labriola<
>>>> labriola@digitalprimates.net>   wrote:
>>>>
>>>>>> Ok. I'm totally willing to believe you and to think that I'm missing
>>>>> something here but I think you have to explain that a little bit more.
>>>> What
>>>>> kind of apps were these? Were they super detailed subcomponents? Or was
a
>>>>>> combobox something that needed an item renderer? What other UI set
are
>>>> you
>>>>> comparing them with?
>>>>>
>>>>> The need to build and extend these components for large enterprises
>>>>>
>>>>>> Or to put a hard number on it how big were these projects? Two people?
>>>>> ten? or more?
>>>>> Dozens sometimes hundreds.
>>>>>
>>>>>> But point me to a better set of standard ui components and make the
case
>>>>> for them, because then we can emulate them.
>>>>> Its not that there is a better set. The point is that there are major
>>>>> improvements that can be made
>>>>>
>>>>>> How did you like awt or swing or the microsoft native component sets?
>>>> Did
>>>>> you use the silverlight components at all?  Tcl did the job?
>>>>> Although I didn't always like their internals, the quantity and general
>>>>> extensibility of many of the Silverlight components was quite nice
>>>>>
>>>>>> Did spark solve your problems? Please tell me how removing the ability
>>>> to
>>>>> change simple things like label positioning and styles, base colors,
>>>>> enabled something to solve your problems?
>>>>> It solves many of the problems simply by delegating the instantiation
of
>>>>> the visual components to a separate, swappable class
>>>>>
>>>>>> Things can always be better, but what then, in your mind is the gold
>>>>> standard that we should strive for? Because in my experience, the mx
>>>>> components were the best out of the box stuff that I've been able to
work
>>>>> with.
>>>>> The mx components were the multi-tool of the world. When you buy a
>>>> kitchen
>>>>> appliance that does -everything- you often find that it doesn't do
>>>>> -anything- with expertise. We spent millions of dollars doing nothing
but
>>>>> changing the SDK so we could begin to extend it. Components being created
>>>>> inside of 500 line methods which access private variables so you can
>>>> never
>>>>> change the implementations via subclass. Hardcoded dependencies, hell,
>>>> even
>>>>> the methodology by which createChildren checks for the existence of a
>>>> child
>>>>> before creating a new one so that you have this primitive sort of
>>>> override
>>>>> mechanism. All code smells.
>>>>>
>>>>>> You had to recompile the whole sdk to add minimal functionality?
>>>>> We maintain nearly 15 copies of the sdk each modified in different ways
>>>> to
>>>>> suit client needs. Try to fix the i18n issues of the framework when
>>>>> internally every object is bound to a hard date instance or uses a set
of
>>>>> string utilities which don't work 100% with 3/5ths of the world's
>>>> languages
>>>>> and you will quickly find that, to change one of those pieces (due to
>>>>> coupling and hard dependencies) you have to override an entire branch
of
>>>>> the framework class by class, not just a node.
>>>>>
>>>>>
>


Mime
View raw message