I'm going to throw a comment in here from the sidelines....
At the end of reading this, you might think it seems like a trivial
suggestion, but here goes anyway:
I understand the logic in striving for a basic set of browser/swf
compatible styles and I agree with the need. But I actually don't think it
deserves the name 'Simple', and that this naming may be part of the reason
people are coming at this from different directions.
Simple has two general meanings:
-plain/basic
-easy/not difficult
I don't know for sure, but I suspect the original choice of 'Simple' here
was in the 'plain or basic' sense, with a sense of constraint to support
both swf and js targets. But I'm not sure this is been the general
interpretation..
For someone trying to target JS first and not so concerned about SWF,
SimpleCSSStylesImpl may not be an easy option, it would be 'constrained' or
'restricted' perhaps.
I think it probably needs to be called what it is :SWFCompatibleCSSImpl
(given that js side has the 'super-set') or even CrossPlatformCSSImpl or
something like this.
Then the name of the class would make it clear to people using it what to
expect, and to people contributing to the framework what should go in it,
and what should not.
I suspect if it was named something like that you ("constant reader") would
never have ended up reading this thread.
Just a thought, anyway...
On Mon, Mar 6, 2017 at 7:45 PM, Alex Harui <aha...@adobe.com> wrote:
>
>
> On 3/5/17, 10:11 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:
>
> >Hi,
> >
> >> How will we achieve parity on the SWF side? And keep the SWF
> >> implementation simple. SWF only knows about "bold" and "normal".
> >>That's
> >> one reason SimpleCSSStylesImpl is "simple”.
> >
> >Is this a real concern? There are several other styles in that class that
> >don't have parity between JS and AS i.e background image, border style,
> >vertical align and padding. May also be others I’ve not looked at all
> >properties in detail.
>
> They may not have parity today due to bugs, but the goal is to reduce the
> differences to zero if possible. I think we can do that for the styles in
> there, and if we can't, we'll probably pull out the ones we can't.
>
> >
> >It seems wrong to me to disable something in the JS side just because
> >it’s not supported in the AS side.
>
> It isn't disabling something on the JS side, it is giving users choices
> about size, performance and features. That is the nature of PAYG. There
> is no one "right" answer. Users are not required to use
> SimpleCSSStylesImpl, and I doubt SimpleCSSStylesImpl will be the most
> popular IValuesImpl. But it has a goal of being "simple", small, and
> parity.
>
> We definitely need the code you wrote, but in a different class. We need
> other IValuesImpls.
>
> Thanks,
> -Alex
>
>
