"#child1 extends #child2" inside "#parent"?

7 views
Skip to first unread message

Frifox

unread,
Mar 10, 2010, 5:34:23 PM3/10/10
to xCSS - OO CSS framework
HTML for this example:
--------------------------------------
<div id="wrapper">
<div class="header">
HEADER
</div>
<div class="content">
CONTENT
</div>
<div class="footer">
FOOTER
</div>
</div>

and attached CSS:
--------------------------------------
#wrapper {
self {
color: red;
}
.header {
text-align: center;
color: green;
}
.footer extends .header {
color: blue;
}
}


the problem, or more like something not-working-as-i-expected, is the
".footer extends .header" part... of course replacing it with ".footer
extends #wrapper .header" works as expected but that seems a bit,
unnecessary.

Would it be possible for xCSS to assume the ".header" to mean
"#wrapper .header" unless specified otherwise, since ".header" in
nested inside "#wrapper" anyways?

Anton Pawlik

unread,
Mar 11, 2010, 5:33:35 AM3/11/10
to xc...@googlegroups.com
i dont think this make any sens because you will change the .footer by adding later the .header element outside #wrapper

Jeff Dickey

unread,
Apr 19, 2010, 7:15:59 AM4/19/10
to xCSS - OO CSS framework
Frifox,

I'll have to take a look at how xCSS handles inheritance; *as a PHP
developer* the behaviour you're asking for would be what I'd
assume. .footer SHOULD look for .header at the same semantic level
(relative/sibling), then using 'include_path' (or an xCSS-specific
equivalent/supplement), and FINALLY an absolute path
("#wrapper .header") as a last-ditch "Hail Mary" attempt to find the
declared superclass. Doing it this way would allow you to move
around .header and .footer independently of each other, reuse them in
a project where they weren't enclosed by #wrapper, etc.; in short,
what experienced OO developers in *any* language would think of as
normal practice.

Anton, quite honestly, I don't understand your answer at all. Please
enlighten me?

Jeff Dickey
--
Subscription settings: http://groups.google.com/group/xcss/subscribe?hl=en

Anton Pawlik

unread,
Apr 19, 2010, 12:11:16 PM4/19/10
to xc...@googlegroups.com
Hello Jeff,
i can see your point, but the problem is: 

// adding .header outside of the #wrapper
// can lead to unexpected changes to the .footer
// not the right way of doing extensible css
.header {
  color: red;
}

#wrapper { 
        self { 
                color: red; 
        } 
        .header { 
                text-align: center; 
                color: green; 
        } 
        .footer extends .header { 
                color: blue; 
        } 

one thing though that came across my mind, it souldn't be ".footer extends #wrapper .header" but ".footer extends self .header"

Frifox

unread,
Apr 19, 2010, 7:23:37 PM4/19/10
to xCSS - OO CSS framework
{.footer extends self .header}, didn't even thing of that.

Adding SELF would solve the need to rewrite long classes and would be
more fool-proof since I'm having hard time imagining myself
misspelling "self" =P


Though, another problem arises when dealing with declaration deep
where you'd still have to re-write the full path:

#paren1 {
child1 {
child2 {
child3 {
child4 {
font-color: orange;
}
}
}
}
}

#parent2 {
child1 {
child2 {
child3 {
child4 extends #partent1 child1 child2 child3 child4 { }
}
}
}
}

but if I get to that point then its a definite sign that my css is
horribly designed in the first place =D

Jeff Dickey

unread,
Apr 19, 2010, 11:18:48 PM4/19/10
to xc...@googlegroups.com
Hello, Anton!

I see your point. You’re just saying that xCSS has different, arguably stricter, rules on specifying inheritance than I’m used to. Question: In your example, if ‘#wrapper .header’ had not specified a value for ‘color’, which would apply?  The “standalone” ‘.header’ overridden by ‘#wrapper self’, or vice versa (‘#wrapper self’ then ‘.header’)? I’m planning on giving xCSS a good going-over in the next few days, but what I think I’d intuitively expect would be the first behavior — global ‘.header’, then ‘#wrapper self’, then ‘#wrapper .header’. The reason would be the principle of specificity: by declaring behaviour that is shared by all contents of ‘#wrapper’, ‘#wrapper self’ overrides any externally-declared specifications, such as the global-level ‘.header’.  I’d be very confused to find that that was not the case.

Thoughts?

By the way, thanks for writing (and supporting!) xCSS. It looks like it’ll help me solve a couple of problems I’m having on one project... as soon as I can get my head out of the other one I’m working on. :)

Sincerely,

Jeff

--
Jeff Dickey         Seven Sigma Software and Services
Email:              jdi...@seven-sigma.com
Phone/SMS:          +65 8333 4403
Website:            http://www.seven-sigma.com
Blog:               http://archlever.blogspot.com/
Skype:              jeff_dickey
LinkedIn:           jdickey
Yahoo! IM:          jeff_dickey
MSN IM:             jeff_...@hotmail.com (for IM only, please)
ICQ:                8053918
QQ:                 30302349
GnuPG key:
    Fingerprint     1808 D814 3579 4ED1 418F  AB03 D71A 1A8A 2B16 0BF6 6488
    Valid until     30 June 2010
    Download from   http://tr.im/qqQa

Jeff Dickey

unread,
Apr 19, 2010, 11:25:26 PM4/19/10
to xc...@googlegroups.com
Agreed on all points ‹ particularly the last :-)

"We should have only enough rope so as to properly shoot ourselves in the
foot."

Good to see that there's actual thinking going on around this project!

Jeff

--
Jeff Dickey Seven Sigma Software and Services
Email: jdi...@seven-sigma.com
Phone/SMS: +65 8333 4403
Website: http://www.seven-sigma.com
Blog: http://archlever.blogspot.com/
Skype: jeff_dickey
LinkedIn: jdickey
Yahoo! IM: jeff_dickey
MSN IM: jeff_...@hotmail.com (for IM only, please)
ICQ: 8053918
QQ: 30302349
GnuPG key:
Fingerprint 1808 D814 3579 4ED1 418F AB03 D71A 1A8A 2B16 0BF6 6488
Valid until 30 June 2010
Download from http://tr.im/qqQa


Reply all
Reply to author
Forward
0 new messages