I like the idea of capability-specific mixins also. I wanted automatic
mixins for accessibility a while ago - there's a bunch of code that
doesn't need to be in radiobutton and tree unless accessibility is
available, and on.
Another issue with using mixins is they can't be applied on an instance,
only on a class.
P T Withington wrote:
Our goal should be to provide generic API(s) that encompasses the
features that will be most useful to LZX developers. We don't want to
restrict the power of platforms by taking the least-common denominator,
nor to we want to create a baroque interface that encompasses every
possible feature of every possible platform. Where possible, we want to
align with standards (or emerging standards). And we want to make it
possible for developers to gracefully degrade by testing
canvas.capabilities.
So, the idea of creating mixins that represent a set of features
corresponding to a capability makes it easier to document.
We don't support conditionally adding a mixin in LZX, but maybe we can
do that 'under the covers', so that you can say something like:
if (this is lz.dropshadowable) {
this.setAttributes({shadowangle: 135, shadowdistance: 12,
shadowcolor: 'black'});
}
so you don't have to test capabilities?
On 2009-09-25, at 11:08, Raju Bitter wrote:
Good idea, André! Although the features are not limited to DHTML! The
whole range of drop-shadow for text, boxes, rounded corners and 3d
transform is available in either Flash9 or Flash10 (3d transform).
What would that mean for all the text features like right-to-left,
etc. which are available in Flash10, and partially in DHTML?
http://labs.adobe.com/technologies/textlayout/
Those features are not available in SWF8/SWF9! @Henry?
On Sep 25, 2009, at 3:55 PM, P T Withington wrote:
I like the idea of separating multi-parameter interfaces out into a
mixin. It at least makes the documentation more logical.
---
Another idea that was alluded to in this thread that I think we
should pursue: The concept of a 'batch' interface. This might not
be used directly users, but it would be a way to optimize the
animation of multiple attributes. Two ideas:
LzNode/setMultipleAttributes(plist:Array) where plist is an
alternating list of attribute name and value
This would let the system have a chance to optimize event sending, by
deferring them until all the attributes have been given their new
values.
LzNode/setAttributeAnimator(attribute:String, animator:Animator)
LzNode/animationStep();
This would be a reorganization of the animation substrate. Rather
than individual animators running off the idle clock and triggering
constraint cascades, you assign an Animator object to an attribute
(it contains the parameters of the animation of that attribute), and
add a delegate to the idle queue that runs animationStep on the
instance being animated. animationStep is a similar batch
optimization that uses all the Animators to compute the new values of
the animated attributes of the instance, installs those values, and
then sends the associated events.
Hmmm....
An attribute animator is really just a constraint that is
constraining the attribute value to a function of elapsed time...
What can we make of that?
On 2009-09-25, at 08:48, André Bargull wrote:
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
--
Regards,
Max Carlson
OpenLaszlo.org
