Another idea:
Instead of adding all attributes to <view>, which may lead to an
overload, it may be possible to use specialized mixins which add support
for CSS3 features. And only if certain CSS3 features are necessary,
you'd "mix-in" them into your <view>. That way nobody needs to worry
about performance penalties and documentation would be much easier since
there won't be hundreds of attributes for view.
- André
Raju and I had a good discussion, which I'll summarize here. Raju,
please let me know if something is missing.
+ There's no way around adding discreet attributes. This goes to Rami's
point about keeping things simple, logical and consistent. We need to
benchmark with some large apps to see how adding 50+ attributes to
lz.view affects performance.
+ We need support for compound attributes. It's a nice option for
developers to use if they want to, and is mostly useful for procedural
code. Instead of calling setAttribute() once for each value, they could
make a single call, e.g. with a generic method like
this.setCompoundAttribute("width: 50; height: 55;..."). Or, it could be
added as custom setters on a case-by-case basis, e.g.
setAttribute("transform", "rotateY(10deg) rotateX(20) rotatez(10)
scaleZ(-5)..."); This could be a good place for optimization when
several attributes need to change at once, and could be related to the
work on enhanced runtime CSS support.
+ We may be able to avoid some of the overhead of adding discreet
setters for 50+ attributes by using a generic setter that knows how to
call sprite APIs by convention. There are a few issues with this
approach: how to constrain to only supported attributes, and how to
provide good documentation.
It could use a whitelist of valid attribute names/types. Documentation
could live on the class properties like it does today.
Raju Bitter wrote:
> I know Max, I'm not sure how to deal with the situation. Compare this:
>
> <view csstransform="-transform-style: preserve-3d; -transform:
> rotateY(10deg)" />
> <view transform-style="preserve-3d" transform="rotateY(10deg)
> rotateX(20) rotatez(10) scaleZ(-5)" />
> <view transform-style="preserve-3d" rotatey="10" rotatex="20"
> rotatez="10" scalez="-5" />
>
> I guess the LZX way of doing this would be the 3rd version.
>
> - Raju
>
> On Sep 25, 2009, at 9:41 AM, Max Carlson wrote:
>
>> Unfortunately, I don't know how else to deal with this if we want to
>> support animating these attributes.
>>
>> Raju Bitter wrote:
>>> While single attributes are easy to handle, the number of attributes
>>> will drastically increase with all the new CSS attributes. Think of
>>> the 3d transform, and the properties:
>>> http://www.w3.org/TR/css3-3d-transforms/
>>> The following properties exits:
>>> * transform
>>> * transform-origin
>>> * transform-style
>>> * perspective-origin
>>> * backface-visibility
>>> The transform property can contain a selection of the following
>>> functions: matrix(), matrix3d(), translate(), translate3d(),
>>> translateX(), translateY(), translateZ(), scale(), scale3d, scaleX(),
>>> scaleY(), scaleZ(), rotate(), rotate3d(), rotateX(), rotateY(),
>>> rotateZ(), skewX(), skewY(), skew(), perspective()
>>> Following the attribute approach (one attribute per function), we
>>> would have to add 25 attributes for CSS 3d Transforms only. That
>>> would be attribute overkill, wouldn't it? Or do we want to add 50-60
>>> attributes to views to support the new CSS features?
>>> - Raju
>>> On Sep 25, 2009, at 4:29 AM, James Robey wrote:
>>>> Max Carlson wrote:
>>>>> The CSS3 draft allows a shadow to be defined with four parameters -
>>>>> distanceX, distanceY, color and blur radius. Instead of specifying
>>>>> the x and y offset separately, we thought it made more sense to
>>>>> specify a distance and angle (in degrees).
>>>>>
>>>>> I propose exposing these four properties as separate view
>>>>> attributes (shadowdistance, shadowangle, shadowcolor and
>>>>> shadowblurradius) so they can be animated.
>>>>>
>>>>> An alternate approach is to expose them as a single compound
>>>>> attribute like in CSS3, e.g. 'distance angle color blurradius'.
>>>>>
>>>>> See http://www.w3.org/TR/css3-background/#the-box-shadow and
>>>>> http://www.w3.org/TR/2003/CR-css3-text-20030514/#text-shadows for
>>>>> more details.
>>>>>
>>>>> What do folks think? I have a change ready to go in, but Tucker
>>>>> reminded me I should solicit feedback first. Thanks!
>>>> I like the idea of having them as four animate-able attributes. I
>>>> would not like to do string manipulation, of say, the shadow of a
>>>> box moving farther away when it's "picked up" for a move.
>>>>
>>>> 2 cents
>>>>
>>>> .james
>>
>> --
>> Regards,
>> Max Carlson
>> OpenLaszlo.org
>>
>
-- Regards, Max Carlson OpenLaszlo.org
