Wedge

Public area => The Pub => Features => Topic started by: Nao on August 21st, 2013, 06:00 PM

Title: Getting rid of zebra classes
Post by: Nao on August 21st, 2013, 06:00 PM
Quote from Arantor on August 20th, 2013, 04:34 PM
You don't need to get rid of windowbg everywhere.
Oh, on the contrary, I need to...
I think we need to have a 'generic' class for areas that need to apply a background, whether striped or not, but I don't really know... Just 'bg', maybe, would be fine..? But form vs. function, etc... So, just 'window' or 'win'...? Well, 'windowbg' never really made sense, I mean, it was never about 'windows', more about simply areas with alternating colors, so... 'zebra'? No, we need to ensure that the class can also be used on non-alternating areas, hmmm...
Quote
One at a time - there's already postbg specifically for posts, target that first. Then one for the thoughts list, and so on and so on. Eventually yes, windowbg will go and that's a good thing. Ideally each major area should have its own set of classes so that it's easier to style at will - while it will take slightly more CSS, the per-page saving could be surprising - because you wouldn't necessarily need to leave in all the classes; I don't know what 'root' does but I see no reason why you couldn't flatten down 'root postbg(2)' to simply postbg,
.root is mainly used by JS to determine the closest message ID, but over time, I started styling it as a 'generic' way to target a post container, and it can be renamed as you wish.
Quote
There are precisely two XenForo sites I know of that don't look like XenForo. Every other installation just screams XenForo. Ditto for IPB. Anything that introduces behaviour that is dependent on rewriting layout markup is going to be fragile.
It's always a fine line, between creativity and customizability... Just ask Bloc, I guess... ;)
Title: Re: Getting rid of zebra classes
Post by: Nao on August 22nd, 2013, 05:54 PM
Okay, so, I started work on this, and there's (already!) an interesting issue... Right from the start, really. (Although I did manage to get MessageIndex to behave... :))

Topic pages!

HTML is like this:
<post>
<separator>
<post>
<separator>
<...>

So, if I'm styling <post>'s background, it'll always respond to :nth-child(odd), because :nth-child(even) would hit the <separator>.

It strikes me as a bug or something, because .postbg:nth-child(even) should hit every other .postbg elemnt, and certainly NOT "every other element, provided it has the .postbg class on it"...

I'm just sayin'. Work in progress, everythin'.

Posted: August 22nd, 2013, 05:49 PM

Oh... Crap! Got it.
What we're looking for is not :nth-child(even), it's :nth-of-type(even)...

Found explanation here:
http://css-tricks.com/the-difference-between-nth-child-and-nth-of-type/

Silly me...
Title: Re: Getting rid of zebra classes
Post by: Nao on August 22nd, 2013, 06:05 PM
Here's a screenshot from my local site...

Because I merged .postbg/.postbg2 into .root (you could argue it's not my best idea and I should keep a '.bg' class in addition to .root), Wedge no longer removes bg classes when soft-merging posts, and as a result, it leaves stripes inside posts themselves, like this...

Do you this it's best to remove the background (and thus restore a bg class somewhere), or it's okay like that..?
Title: Re: Getting rid of zebra classes
Post by: Arantor on August 22nd, 2013, 06:10 PM
I could make the argument either way actually. Having zebra striping per post would certainly add the sensation that they are different posts. On the other hand it would clearly indicate they are one post.

For styling the overall post rather than the individuals, you could always tie it to .postarea rather than .root since .postarea contains all of the posts from a single merge.
Title: Re: Getting rid of zebra classes
Post by: Nao on August 22nd, 2013, 11:00 PM
Nah, I could simply 'cancel' any styling on .postarea .root, probably simpler, too...

Sorry, looks like I forgot to attach the screenshot...!
Title: Re: Getting rid of zebra classes
Post by: Arantor on August 22nd, 2013, 11:08 PM
Looks good, I like it like that.
Title: Re: Getting rid of zebra classes
Post by: Nao on August 22nd, 2013, 11:34 PM
Oh... I forgot.
Since these are children of postheader, the zebra counter is reset on each soft-merged post, meaning we get inconsistencies within them. :-/

I guess it's one of those cases where there's no good solution...
Title: Re: Getting rid of zebra classes
Post by: Arantor on August 22nd, 2013, 11:41 PM
I think the only solution is to drop postbg vs postbg2, and use postbg:nth-of-type(even) to style alternately, so it's done based on groups of posts rather than individual posts within a group...?
Title: Re: Getting rid of zebra classes
Post by: Nao on August 22nd, 2013, 11:50 PM
I dropped postbg and postbg2 today... (?)
I replaced them with '.msg', which is what '.root' used to be (only, compresses better :P)
I don't think there's a way to 'maintain' the zebra counter when you're looping through a series of msg classes that are INSIDE another msg class... Can you?
Title: Re: Getting rid of zebra classes
Post by: Arantor on August 22nd, 2013, 11:55 PM
It's still in the source here... And actually... maybe you can.

As I understand it, and I might be wrong... parent > child:nth-of-type(even) would work and not match children or nesting or suchlike. I dunno. I'm not a CSS guru.

Heck, I managed to break notifications just by adding:
Code: [Select]
#pms extends #notifs
to the CSS (and it actively broke everything related to notifications, though I would add there was a suitable element with that in it, it all looked right but the popup wouldn't pop up)
Title: Re: Getting rid of zebra classes
Post by: Nao on August 23rd, 2013, 12:16 AM
Quote from Arantor on August 22nd, 2013, 11:55 PM
It's still in the source here... And actually... maybe you can.
Now it's committed, so you should be able to see what I was talking about... And maybe test your idea ;) Unfortunately, it's bed time for me... Wanted to have most of my commits done! (I avoided committing my .windowbg changes, they're... confusing. It's going to require even more work, hmm...)
Quote
As I understand it, and I might be wrong... parent > child:nth-of-type(even) would work and not match children or nesting or suchlike. I dunno. I'm not a CSS guru.
Unfortunately, from my initial tests, :nth-of-type will only apply on the current level, so it's always reset when entering a new div. Just like :nth-child, in the end.
Quote
Heck, I managed to break notifications just by adding:
Code: [Select]
#pms extends #notifs
to the CSS (and it actively broke everything related to notifications, though I would add there was a suitable element with that in it, it all looked right but the popup wouldn't pop up)
I'll look into it tomorrow...!