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 mailing list
Laszlo-dev@openlaszlo.org
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev

Reply via email to