Circling back to this.

For now, the default naming scheme is to "add more words".  There is no
current specification of "where".  So, Button adds a text property and
becomes TextButton.  But elsewhere there is SimpleStatesImpl and
StatesWithTransitionsImpl.  I don't mind the inconsistency, but maybe
other folks do.

But anyway, the current scheme is to add words to indicate increased
capabilities of PAYG in the various implementations.

We might later choose to give SimpleCSSStylesImpl a better name, but for
now, the numeric fontWeight code could go in a
NumericFontWeightCSSStylesImpl or StyleCSSStylesImplWithNumericFontWeight
to indicate the additional PAYG functionality.  And return
SimpleCSSStyleImpl to supporting only "bold" and "normal".

Thanks,
-Alex

On 3/6/17, 11:39 PM, "Alex Harui" <aha...@adobe.com> wrote:

>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
>>>
>>>
>

Reply via email to