incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dwayne Henderson <its.code.in.h...@gmail.com>
Subject Re: CSS
Date Sat, 03 Mar 2012 17:45:33 GMT
Also do check out http://tinyurl.com/6n9an3o!

--Dwayne

On Sat, Mar 3, 2012 at 5:10 PM, Martin Heidegger <mh@leichtgewicht.at>wrote:

> 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/<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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message