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
