While I'm working on this garBage, I'm curious if people feel strongly
that given this:
<stylesheet>
a c {
testval: 1;
}
b c {
testval: 2;
}
</stylesheet>
<class name="a"/>
<class name="b"/>
<class name="c">
<attribute name="testprop" value="$style{ 'testval' }"/>
</class>
<a><b><c id="w3c"/></b></a>
The value for the testprop attribute of instance w3c should be 2 and NOT 1.
That is to say, I assume that we want a similar notion of applicability (not
specificity) with descendant selectors. Can anyone tell me if this appears to
be guaranteed in browserland?
A
On Sep 9, Jim Grandy wrote:
> 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">
> > > <!--
> > > /* rule 1, specificity 10 */
> > > [name="thename"] { background-image: url(confused.jpg); }
> > > /* rule 2, specificity 1 */
> > > p { background-image: url(w00t.jpg); }
> > > /* rule 3, specificity 1 */
> > > div { background-image: url(sad.jpg); }
> > > -->
> > > </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
