flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FlexJS] get rid of inline styles (was Re: [FlexJS]Layout problems)
Date Fri, 02 Dec 2016 07:09:46 GMT
Re-ordering your post so I can address higher-level points first:


On 12/1/16, 4:55 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>
>But Basic set is at the core of
>all. Is at the core of MDL set
>
>

This statement doesn't have to be true, and makes me think that the old
Flex SDK mentality is persisting.  IMO, the MDL set has no obligation to
subclass the Basic set.  The top-level components in the Basic set are
supposed to be compositions of beads.  MDL can just compose the same or
different beads without having to subclass Basic components.

One of the problems of having a core and inheritance is that you have to
get it right, but often there isn't one right answer.

>I think
>Basic set (as is) will not be used at all since the final visuals are not
>production ready, so you know people will need this level of customization
>or they will never join FleJS for sure. and here you have the first
>example of many
>of the styles in flexjs needs to be removed in order to get the MDL branch
>working ok, and so will happen with others like Bootstrap, and so on...
>Only if we create our own FlexJS style design could take into account the
>actual styles, but I think that if MDL or Bootstrap does not need all of
>that, we should not need creating our own CSS set in the end (I can't say
>much more here since I'm not a CSS expert to affirm that, but based on
>what
>I see...is clear that it's the reality).
>

In my mind, there are going to be two kinds of themes: pre-existing ones
like MDL and custom ones like the themes that regular Flex SDK customers
used to brand their applications.  In the second kind, I don't think it
matters as much as to what default styles are. Folks will simply override
the defaults in their themes.

I was a bit surprised that MDL didn't override everything we set as
defaults for HTML.swc.  That means to me that if someone has certain
styles set elsewhere, even in their browser settings, that could cause
really strange and unexpected results.  But OK, that's the way it is, and
so we should think of other ways to have a default look for HTML.swc,
although again, as I said above, the MDL library has no obligation to
inherit from HTML.swc.

If we really need to support more inheritance, then maybe all visual
styles should be moved from HTML into some default theme.  It would be
nice to have a better set of defaults that are a bit more production ready
for Basic so we can see how and why there are collisions between themes.

>You could as well use documentation to expose requirements and make people
>know that 2 or 3 styles are required and if they remove from CSS things
>could break. We could prepare as well a MVCSS (minimum viable CSS) so
>people would not need to use the remove default compiler flag, and have
>another with relative positions, borders and other no-so required things,
>but needed in basic comp set.
>
>

Way back in early Flex, we found our customers didn't like this.  There
was a version of Flex where only the type-selectors with the same name as
the component was applied.  So CheckBox extended Button and lots of styles
important to Button needed to be copied to the CheckBox type selector.
This was way faster at runtime because we didn't have to chase down the
super classes and their styles. But customers really complained because if
you subclassed Button and made a MyButton, you had to know which styles to
copy to a MyButton type selector or the component wouldn't work.  I'm sure
our documentation was not sufficient, but even then, folks thought it was
a pain.

If you want to ensure no styles are specified in code for the MDL library
feel free to do so.  I'm just not sure how important tat is for the Basic
set.

>
>> Similarly, Label isn't supposed to be interactive, so we turn off mouse
>> events.  It is the equivalent of mouseEnabled in SWF.  The way we found
>>to
>> do it is to set a style.  Again, I'm not sure that should be settable
>>in a
>> CSS theme.
>>
>>
>I think so. If we could set the style in CSS and we are not doing this
>because we are afraid of our user...that's a very bad policy. There's
>other
>methods to avoid that. For example, if in MDL mouseEnabled is not
>contemplated...I would left in my CSS.
>
>
>
>> The way we handle visible=false also sets a style: display:none.
>
>
>that's one of the styles I historically use when doing some html, and
>always put in CSS...there's no reason not doing the same in FlexJS
>moreover
>taking into account this is a framework to craft things and nothing final.

IMO, there are styles that are functional like display:none and
pointer-events and no-wrap and styles that are visual.  For functional
styles, I'm not sure it is the easiest API to make folks work with all of
these CSS styles instead of through properties on the component,
especially properties that have a high likelihood of changing at runtime.
So that's why Basic has a visible and alpha properties.  Seems nicer to
set those than have to set style.display = "none".  Yes it means you can't
set things invisible by changing CSS themes, but again, someone is welcome
to create a different component set that does make folks use style.display
= "none".

Again, going back to the first point.  There is often no right answer, so
we are working hard to make sure FlexJS can support multiple independent
component sets so customers can choose the API surfaces that they like
best.

My 2 cents,
-Alex

Mime
View raw message