[Laszlo-dev] optimiziation for inheriting fontsize/name properties
P T Withington
ptw at openlaszlo.org
Tue Apr 4 15:59:53 EDT 2006
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
>> 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
> [*] 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
>> 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
More information about the Laszlo-dev