Re: [Laszlo-dev] LPP-2618 and more specificity weirdness

Jim Grandy Sat, 09 Sep 2006 21:50:10 -0700

Being one of the ones who hated it, let me give you the main reason why we must apply css style rules to subclasses: doing otherwise totally breaks our expectations about OO encapsulation.

Let's say you have an LZX app with six instances of 'testview', and a bunch of CSS rules applying to instances of 'testview' in various ways. Then you decide you need a minor change to the behavior -- but not the appearance -- of two of those instances, so you write a subclass, 'testviewsub', and modify the tag declaration of those two to be <testviewsub/> instead of <testview/>.

What would the OO (never mind the CSS) developer expect to happen? They'd expect instances of 'testviewsub' to look like instances of 'testview'. Having 'testviewsub' instances suddenly lose all of the styling applied to 'testview' instances is (a) unexpected, (b) annoying, and (c) leads to very wasteful duplication of CSS rules, which in turn leads to (e) lots of bugs and maintenance headaches.

So I believe we need to integrate our class system with CSS such that the rules applying to a class also apply to the subclass.

My expectation of this was that subclass specificity would follow similar rules to DOM hierarchy specificity. (And note that I say "DOM hierarchy specificity" because "lexical specificity" doesn't have any meaning in this context since we are using @immediateparent instead of @parent in order to adhere to CSS' DOM hierarchy inheritance.) And, as Tucker points out, the CSS specification is clear about DOM hierarchy specificity.

To further narrow down what our subclass specificity rules should be, let me walk into the CSS2.1 spec a bit, starting with the description of how to compute the specified value (http://www.w3.org/TR/CSS21/cascade.html#specified-value):

User agents must first assign a specified value to each property based on the following mechanisms (in order of precedence):

   1. If the cascade (http://www.w3.org/TR/CSS21/cascade.html#cascade) results in a value, use it.
   2. Otherwise, if the property is inherited (http://www.w3.org/TR/CSS21/cascade.html#inheritance) and the element is not the root of the document tree, use the computed value of the parent element.
   3. Otherwise use the property's initial value. The initial value of each property is indicated in the property's definition.

Note that by "inherited", the spec means "inherited from the DOM parent", not "inherited from some putative superclass".

As for the cascade, the first rule in the cascade description says:

1. Find all declarations that apply to the element and property in question, for the target media type. Declarations apply if the associated selector matches (http://www.w3.org/TR/CSS21/selector.html) the element in question.

The "matches" link leads us to a description of the various types of selectors, including this one:

A type selector matches the name of a document language element type. A type selector matches every instance of the element type in the document tree.

Our CSS Proposal on the wiki suggests that LZX classes be considered "document element language types" in the sense used in the W3C CSS spec. I think this is the right approach. So if you follow this whole chain through, the p-inherits-from-div model in HTML maps directly over to our button-inherits-from-view class hierarchy.

Unfortunately, in the end what is not made sufficiently clear in the CSS2.1 spec is how sub-typing relations (both the p/div one in HTML and our button/view on in LZX) affect specificity in the cascade. I can't find any commentary on this in either the CSS2.1 spec or the two relevant CSS3 specs (CSS Selectors, www.w3.org/TR/css3-selectors/, and CSS Cascading the Inheritance, http://www.w3.org/TR/css3-cascade/).

However, as Tucker has pointed out we have plenty of de facto evidence that the specificity of all rules applying directly to a class should be higher than the specificity of any rules applying to its immediate superclass, and so on. And if that's not the precise model, I strongly feel that we should test the behavior of the major browsers in this area and follow their lead.

jim

On Sep 9, 2006, at 11:40 AM, Adam Wolff wrote:

well, we could say that css style rules don't apply to subclasses. I
argued for that earlier but everyone hated that idea.

A

On Sep 9, P T Withington wrote:

On 2006-09-09, at 12:15 EDT, Adam Wolff wrote:

This is expected behavior. The reason for it is not that edgar is looking
at its parent for the value of testdata, it's that edgar is also a view,
and right now our specificity stuff doesn't account for the more direct
applicability of the subclass selector.

If this is 'expected' it's going to confuse the heck out of people who expect
our CSS to work like w3c CSS.

As I said in my response, Ben's intuition matches CSS. Here is my equivalent
CSS:

<style type="text/css">

</style>
<div name="thename">
<p id="edgar">
<span name="background-image" style="font-size: 72pt">This is
a test</span>
</p>
</div>

Which will display the background-image 'w00t'.

In CSS a `p` is effectively a `div` with specific defaults for css attributes,
but rule 3 will never apply to a `p`.

You can confirm this by switching the order of the rules, and you'll get a
different result. I assume that the applicability of rules with the same
specificity in CSS is undefined, but ours happen to roughly mimic lexical
order for now because we are using array.sort which I think is stable.

One of the cascade rules of CSS is lexical order. Later rules with equal
specificity take precedence over earlier rules.

It would be nice to make subclasses more specific than superclasses, but
that would make specificity a function of not only the selector, but also
the node being selected, and that seems like a pain.

I think the idea of making a CSS tag selector select for `instanceof` is
appealing, but it is going to confuse the heck out of people who are expecting
it to be like a CSS tag selector, as Ben's example shows.

My vote would be to fix this now, before it is released in the wild. The
current behavior could be considered an extension of CSS. As such, it should
probably be indicated with a different syntax than the tag selector. At the
very least we need to tweak it so that a more-specific tag/class has more
specificity!

_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev

_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev

Re: [Laszlo-dev] LPP-2618 and more specificity weirdness

Reply via email to