List to collaborate on OpenLaszlo platform development, submit source code and report bugs

Neil Mix | 1 Apr 07:30

Re: optimiziation for inheriting fontsize/name properties

That's very clever.  And I'm humbled -- you just taught me something  
about JavaScript that I didn't previously know.  This language slays  
me -- after 4 years of it I still don't have it down.  :/  Neat.

On Mar 31, 2006, at 5:33 PM, P T Withington wrote:

> On 2006-03-31 17:59 EST, Neil Mix wrote:
>
>> That looks a lot like a cloning operation:
>>
>> function cloneObject(obj) {
>>   var clone = {};
>>   for(var n in obj) {
>>     clone[n] = obj[n];
>>   }
>>   return clone;
>> }
>
> Except the clone will not track changes in the object it was cloned  
> from.  By using the prototype chain, if a view inherits a style  
> from its parent and the parent's style changes, the view would see  
> it too.  (Hm, but there would still need to be an event sent to  
> tell the child view to notice the change...)  [Note in my code I  
> set the css object to have the parent object as it's prototype, and  
> then set the local values from the init args into the local css,  
> which will cause them to override any in the parent.  If you want  
> to dynamically revert an overridden style to inherit from the  
> parent, you just delete it and the parent value will be exposed.]
>
>>>> use prototype-inheritance to give you memo-izing for nearly free.

(Continue reading)

headers

Jim Grandy | 1 Apr 18:19

Re: optimiziation for inheriting fontsize/name properties

Clever indeed -- kudos to Tucker!

This would put the "cascade" in our style model with very little  
effort. Nice.

Two questions to pursue: how different would this be from our current  
style feature? And: how different would this be from w3c css? I'm not  
sufficiently up to speed on either to be able to answer these  
questions without some research.

jim

On Mar 31, 2006, at 9:30 PM, Neil Mix wrote:

> That's very clever.  And I'm humbled -- you just taught me something
> about JavaScript that I didn't previously know.  This language slays
> me -- after 4 years of it I still don't have it down.  :/  Neat.
>
> On Mar 31, 2006, at 5:33 PM, P T Withington wrote:
>
>> On 2006-03-31 17:59 EST, Neil Mix wrote:
>>
>>> That looks a lot like a cloning operation:
>>>
>>> function cloneObject(obj) {
>>>   var clone = {};
>>>   for(var n in obj) {
>>>     clone[n] = obj[n];
>>>   }
>>>   return clone;

(Continue reading)

headers

P T Withington | 2 Apr 01:39

Re: optimiziation for inheriting fontsize/name properties

On 2006-04-01 11:19 EST, Jim Grandy wrote:

> Clever indeed -- kudos to Tucker!

Aw, shucks.  You and Neil give me too much credit.  Adam uses this  
technique all over the LFC.  The only 'clever' bit was to realize  
there was a way to set the prototype chain with straight Javascript  
(rather than relying on access to the internal __proto__ field as is  
done in the SWF kernel).

It really is just a standard feature of a prototype-based language.   
I think that everyone is so brainwashed by class-based languages (the  
C++/Java marketing borg) that they forget there are other models.   
Even we try to tweak Javascript to fit the more conventional class- 
based model.  I'm always glad when Adam reminds me about features  
that come from our prototype-basis, like being able to magically make  
singleton instances without having to create a class.

> This would put the "cascade" in our style model with very little  
> effort. Nice.
>
> Two questions to pursue: how different would this be from our  
> current style feature? And: how different would this be from w3c  
> css? I'm not sufficiently up to speed on either to be able to  
> answer these questions without some research.

You mean the current compile-time CSS implementation?  I think our  
goal with our current implementation is to be closer to w3c CSS, and  
this could help us get closer by providing cascading at runtime.   
(Obviously, for the DHTML back-end we can use the browser

(Continue reading)

headers

Jim Grandy | 2 Apr 22:27

Re: optimiziation for inheriting fontsize/name properties

On Apr 1, 2006, at 3:39 PM, P T Withington wrote:

Two questions to pursue: how different would this be from our current style feature? And: how different would this be from w3c css? I'm not sufficiently up to speed on either to be able to answer these questions without some research.

You mean the current compile-time CSS implementation?

No, I mean the simple tinting/styling feature we've had for a while.

I think our goal with our current implementation is to be closer to w3c CSS, and this could help us get closer by providing cascading at runtime. (Obviously, for the DHTML back-end we can use the browser implementation of CSS and it will just be correct.)

Well, that's the question: does the cascade in CSS (at least avoiding the more exotic features in CSS2/CSS3 like first-word and first-line styles) align well with Javascript prototype inheritance? I'd like to assume it does, but didn't want to assume :-)

It will mean a change from the current way we implement some features, such as text font/size/style, since they are presently individual attributes of text, not properties of a single style attribute.

Right. But there's a nice deprecation progression -- from duplication of state, to pure-virtual "forwarding" attributes using just a setter, to removing the attribute. In this case, I think it'd be worth the increased clarity and expressive power.

_______________________________________________
Laszlo-dev mailing list
Laszlo-dev <at> openlaszlo.org
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev

headers

Oliver Steele | 4 Apr 21:47

Re: optimiziation for inheriting fontsize/name properties

On Apr 2, 2006, at 4:27 PM, Jim Grandy wrote:

On Apr 1, 2006, at 3:39 PM, P T Withington wrote:

Two questions to pursue: how different would this be from our current style feature? And: how different would this be from w3c css? I'm not sufficiently up to speed on either to be able to answer these questions without some research.

You mean the current compile-time CSS implementation?

No, I mean the simple tinting/styling feature we've had for a while.

I think our goal with our current implementation is to be closer to w3c CSS, and this could help us get closer by providing cascading at runtime. (Obviously, for the DHTML back-end we can use the browser implementation of CSS and it will just be correct.)

Well, that's the question: does the cascade in CSS (at least avoiding the more exotic features in CSS2/CSS3 like first-word and first-line styles) align well with Javascript prototype inheritance? I'd like to assume it does, but didn't want to assume

It might be useful for implementing CSS inheritance, where an element inherits properties from its parent. CSS properties are inherited where the value of the property is "inherit"; this is the default value for many properties, such as the font properties.

There's another mechanism in CSS, which is the application of properties to elements through the mechanisms of rules and selectors. For each CSS rule, you need to calculate which elements its declarations apply to. For each element, you need to order its declarations by their weight (whether there's an "!important" modifier), origin (which style sheet), specificity, and order of the rule within its stylesheet.

It would be nice if you could represent each set of declarations (specified by a rule) as an object, and use the prototype chain order to represent the order. One problem is that, because "!important" modifies the declaration rather than the rule, different declarations in the same rule have different orders with respect to the declarations in other rules.

It wouldn't be any great loss to omit "!important". Ordering by stylesheet origin may not be necessary in the context of LZX either, so long as inline styles override other styles. The (a?) remaining problem is that different sets of rules apply to different elements. For example, the declarations in R1 and R3 might apply to E1, while the declarations in R2 and R3 might apply to E2. To implement this with prototype inheritance, E1 would need to consult a prototype chain where R3's prototype was R1, and E2 would need to consult a chain where R3's prototype was R2. This could be implemented by cloning R3 before applying it to each element. This would still be two different prototype chains: one to represent the rules; and another to represent the containment hierarchy. The second chain is consulted when the first yields a value of 'inherit'.

[*] By the way, the "cascade" itself in C[ascading]S[tyle]S[heets] refers to the ordering of rules by stylesheet origin, even though this isn't the most highly ranked facet in the ordering algorithm, or what with the benefit of hindsight is the most important feature of CSS.

It will mean a change from the current way we implement some features, such as text font/size/style, since they are presently individual attributes of text, not properties of a single style attribute.

Right. But there's a nice deprecation progression -- from duplication of state, to pure-virtual "forwarding" attributes using just a setter, to removing the attribute. In this case, I think it'd be worth the increased clarity and expressive power.

_______________________________________________

Laszlo-dev mailing list

Laszlo-dev <at> openlaszlo.org

http://www.openlaszlo.org/mailman/listinfo/laszlo-dev

_______________________________________________
Laszlo-dev mailing list
Laszlo-dev <at> openlaszlo.org
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev

headers

P T Withington | 4 Apr 21:59

Re: optimiziation for inheriting fontsize/name properties

On 2006-04-04 15:47 EDT, Oliver Steele wrote:

> On Apr 2, 2006, at 4:27 PM, Jim Grandy wrote:
>> On Apr 1, 2006, at 3:39 PM, P T Withington wrote:
>>
>>>> Two questions to pursue: how different would this be from our  
>>>> current style feature? And: how different would this be from w3c  
>>>> css? I'm not sufficiently up to speed on either to be able to  
>>>> answer these questions without some research.
>>>
>>> You mean the current compile-time CSS implementation?
>>
>> No, I mean the simple tinting/styling feature we've had for a while.
>>
>>> I think our goal with our current implementation is to be closer  
>>> to w3c CSS, and this could help us get closer by providing  
>>> cascading at runtime.  (Obviously, for the DHTML back-end we can  
>>> use the browser implementation of CSS and it will just be correct.)
>>>
>> Well, that's the question: does the cascade in CSS (at least  
>> avoiding the more exotic features in CSS2/CSS3 like first-word and  
>> first-line styles) align well with Javascript prototype  
>> inheritance? I'd like to assume it does, but didn't want to  
>> assume 
>
> It might be useful for implementing CSS inheritance, where an  
> element inherits properties from its parent.  CSS properties are  
> inherited where the value of the property is "inherit"; this is the  
> default value for many properties, such as the font properties.
>
> There's another mechanism in CSS, which is the application of  
> properties to elements through the mechanisms of rules and  
> selectors.  For each CSS rule, you need to calculate which elements  
> its declarations apply to.  For each element, you need to order its  
> declarations by their weight (whether there's an "!important"  
> modifier), origin (which style sheet), specificity, and order of  
> the rule within its stylesheet.

Barring !important, we could model css selectors as 'traits' (as we  
have been discussing them, essentially mixins that come between the  
tag class of each instance and the instance itself.).  !important is  
a real pain.

> It would be nice if you could represent each set of declarations  
> (specified by a rule) as an object, and use the prototype chain  
> order to represent the order.  One problem is that, because "! 
> important" modifies the declaration rather than the rule, different  
> declarations in the same rule have different orders with respect to  
> the declarations in other rules.
>
> It wouldn't be any great loss to omit "!important".  Ordering by  
> stylesheet origin may not be necessary in the context of LZX  
> either, so long as inline styles override other styles.  The (a?)  
> remaining problem is that different sets of rules apply to  
> different elements.  For example, the declarations in R1 and R3  
> might apply to E1, while the declarations in R2 and R3 might apply  
> to E2.  To implement this with prototype inheritance, E1 would need  
> to consult a prototype chain where R3's prototype was R1, and E2  
> would need to consult a chain where R3's prototype was R2.  This  
> could be implemented by cloning R3 before applying it to each  
> element.  This would still be two different prototype chains: one  
> to represent the rules; and another to represent the containment  
> hierarchy.  The second chain is consulted when the first yields a  
> value of 'inherit'.

You are basically describing how traits are implemented.  I have a  
prototype of traits in pure Javascript if you would like to see.

> [*] By the way, the "cascade" itself in C[ascading]S[tyle]S[heets]  
> refers to the ordering of rules by stylesheet origin, even though  
> this isn't the most highly ranked facet in the ordering algorithm,  
> or what with the benefit of hindsight is the most important feature  
> of CSS.
>
>>> It will mean a change from the current way we implement some  
>>> features, such as text font/size/style, since they are presently  
>>> individual attributes of text, not properties of a single style  
>>> attribute.
>>
>> Right. But there's a nice deprecation progression -- from  
>> duplication of state, to pure-virtual "forwarding" attributes  
>> using just a setter, to removing the attribute. In this case, I  
>> think it'd be worth the increased clarity and expressive power.
>> _______________________________________________
>> Laszlo-dev mailing list
>> Laszlo-dev <at> openlaszlo.org
>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>

headers

Jim Grandy | 4 Apr 22:24

Re: optimiziation for inheriting fontsize/name properties


On Apr 4, 2006, at 12:59 PM, P T Withington wrote:

>
> Barring !important, we could model css selectors as 'traits' (as we  
> have been discussing them, essentially mixins that come between the  
> tag class of each instance and the instance itself.).  !important  
> is a real pain.
>
For those interested, there are notes toward an RFC on traits to be  
had at

http://wiki.openlaszlo.org/Traits_Proposal

And I have an scratch implementation of traits against the nightly  
builds that I'll submit soon.

jim

headers

Henry Minsky | 2 Apr 01:51

Re: optimiziation for inheriting fontsize/name properties

It will mean a change from the current way we implement some
features, such as text font/size/style, since they are presently
individual attributes of text, not properties of a single style
attribute.

Yeah, what are the implications of changing that. Should we try to have some intermediate support for the current mechanism for setting font size/style/name directly on a text object and also on a style object? We could have a backward compatible API for a while.

_______________________________________________
Laszlo-dev mailing list
Laszlo-dev <at> openlaszlo.org
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev

headers

Benjamin Shine | 2 Apr 05:38

Re: optimiziation for inheriting fontsize/name properties

On Apr 1, 2006, at 3:51 PM, Henry Minsky wrote:

>
>
> It will mean a change from the current way we implement some
> features, such as text font/size/style, since they are presently
> individual attributes of text, not properties of a single style
> attribute.
>
>
> Yeah, what are the implications of changing that. Should  we try to  
> have some intermediate  support for  the current mechanism for  
> setting font size/style/name directly on a text object and also on  
> a style object? We could have a backward compatible API for a while.
>

I would like to see us develop a model which encourages dealing with  
typography as sets of related characteristics. I would be happy to  
see the API for setting font characteristics separately go away.  
Professional visual design generally uses just a few combinations of  
font color/size/weight/family in an entire document; our model should  
make it easy to make things look good, and hard or impossible to make  
things look bad.

HTML and Microsoft Word made it too easy to use too many text  
effects. I almost always prefer a simple dignified typewritten or  
LaTex document to the insanity of freshmen and programmers set loose  
with too much typographic freedom.

One of the Laszlo Systems visual designers, Peter Andrea, posted a  
rant on web design awards which is worth reading:
http://laszlomail.com/blog/2006/02/10/state-of-the-art-in-graphic- 
design/
"Each of the sites he has chosen to represent utilizes conventions in  
color, layout, typography, and hierarchical structure that are the  
centuries-old foundation of print design. For proof, take a spread  
from any contemporary magazine, and compare it to the screen grabs… I  
would argue that 9 times out of 10, you will find the printed page to  
be superior in every respect."

The ability to set font size/style/name/color directly via separate  
API calls is necessary for making a rich text editor, but that's a  
little tiny subset of "things we want to do with text."

benjamin shine
software engineer
ben <at> laszlosystems.com

headers

P T Withington | 4 Apr 21:54

Re: optimiziation for inheriting fontsize/name properties

On 2006-04-01 22:38 EST, Benjamin Shine wrote:

>
> On Apr 1, 2006, at 3:51 PM, Henry Minsky wrote:
>
>>
>>
>> It will mean a change from the current way we implement some
>> features, such as text font/size/style, since they are presently
>> individual attributes of text, not properties of a single style
>> attribute.
>>
>>
>> Yeah, what are the implications of changing that. Should  we try  
>> to have some intermediate  support for  the current mechanism for  
>> setting font size/style/name directly on a text object and also on  
>> a style object? We could have a backward compatible API for a while.
>>
>
> I would like to see us develop a model which encourages dealing  
> with typography as sets of related characteristics. I would be  
> happy to see the API for setting font characteristics separately go  
> away. Professional visual design generally uses just a few  
> combinations of font color/size/weight/family in an entire  
> document; our model should make it easy to make things look good,  
> and hard or impossible to make things look bad.
>
> HTML and Microsoft Word made it too easy to use too many text  
> effects. I almost always prefer a simple dignified typewritten or  
> LaTex document to the insanity of freshmen and programmers set  
> loose with too much typographic freedom.
>
> One of the Laszlo Systems visual designers, Peter Andrea, posted a  
> rant on web design awards which is worth reading:
> http://laszlomail.com/blog/2006/02/10/state-of-the-art-in-graphic- 
> design/
> "Each of the sites he has chosen to represent utilizes conventions  
> in color, layout, typography, and hierarchical structure that are  
> the centuries-old foundation of print design. For proof, take a  
> spread from any contemporary magazine, and compare it to the screen  
> grabs… I would argue that 9 times out of 10, you will find the  
> printed page to be superior in every respect."
>
> The ability to set font size/style/name/color directly via separate  
> API calls is necessary for making a rich text editor, but that's a  
> little tiny subset of "things we want to do with text."

I think we want to adopt CSS as a way of doing this.  Even though it  
gives the naive designer the same amount of rope you are complaining of.