I'm definitely open to better naming schemes. I am hopeful that lots of
our SWCs will have SWF equivalency to some degree over time, so actually
putting SWF in the name may not be helpful in the long run. Better doc
may be helpful as well.
My 2 cents,
-Alex
On 3/6/17, 11:09 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>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
>>
>>
