by Kyle Weems 1.April 2008 14:57
I am something of a hypocrite when it comes to terms. On the one hand, I'm infamous for cryptic statements like "Have you seen the thingy I was using at that place that one time?" On the other, I'm increasingly tyrannical about always using the appropriate terms for various bits of CSS and code (I'd be better at this if I wasn't guilty of screwing them up so often myself).
There is, however, a point where enough is enough. In CSS3 there exists a thing called the general sibling selector that is on the verge of driving me insane. What is it? To quote Sitepoint, "The selector matches elements that are siblings of a given element."
Before I get any farther into CSS gobbledygook and the reason for my Hulk-like fury, let's consider the word sibling. According to definr (the web's cutest and fastest dictionary), a sibling is a person's brother or sister. According to guiStuff, siblings are "... a group of two or more elements that share the same parent." With this in mind, let's consider the following metaphor:
I have two siblings, an older brother named Conrad, and a younger brother named Eric. The former is 19 minutes older than me (You read that right. And if you don't think hasn't been holding those 19 minutes over me for my entire life than you're probably not a twin). The latter is 10 years younger. It's my impression that as Conrad and I moved out of my parents' house that they sighed in regret that it was another ten years before they actually got any peace and quiet.
Prior to CSS3 there already existed the "adjacent sibling selector", which has the following syntax: E+F {declaration block}. This matches F when it immediately follows E. So in the example of my siblings, if you considered all of us as being "son" elements, the code son+son { declaration block} would match myself and Eric (I'm after Conrad and Eric is after me), but not Conrad (as he didn't follow any prior siblings).
I've always disliked the term adjacent for this, as it's one way, and thus misleading. After all, isn't Conrad adjacent to me in the order? If I was on the W3C (there's a pompous thought) I would have pushed for the term "following adjacent selector". This wasn't entirely horrible in most cases, but let's say that I'm trying to select any one of us sons that is adjacent to a son with a red shirt. Something like son:redshirt+son {declaration block}. If Conrad was wearing a red shirt, it'd match me but not Eric. However, if I was wearing a red shirt, Conrad would not match, although Eric would. (Incidentally, I don't think any of us look good in red, but maybe that's an allergic reaction to the color caused by a childhood of watching Star Trek reruns, which taught me that wearing a red shirt meant you were usually being stabbed by a Klingon, swallowed by a rock monster, or crushed by a robot). So what CSS could I use to select Conrad in such a situation?
It was my foolish impression that CSS3 had come to the rescue with its new "general sibling selector", which would allow for all sorts of weird solutions to dropdown list problems and such with fancy combinations with pseudo-classes, attribute selectors, and anything else I could cram into a single style. After all, it contained the word "general", which sounds so all inclusive. It's syntax is E~F {declaration block}. So, if I wanted to make my brothers disappear whenever I wore a red shirt (who doesn't want to make their siblings go away from time to time?) I could simply use the following code: son:red-shirt~son{display:none;}.
Victory, right?
Wrong.
Once again, the wunderkids at the W3C had failed to be more specific with their name for this little selector. If I were to be using this style, and wearing aforementioned shirt, my younger brother would disappear but my elder would remain. Now, where this serves more purpose than the adjacent sibling selector is that if Conrad were to wear the red shirt, both Eric and I would disappear, even though Eric isn't adjacent to Conrad. But once again, it only affects following siblings, not preceding ones. So no matter how garish the red was on my chest, my eldest brother would continue to sit there, filling space and reminding me of his senority.
Why?! Under what case is it absolutely nessecary to have a style match a case with an element following somewhere in the distance behind it's sibling, but never the converse? If I had to rename this monumentally disappointing selector, I'd call it a "not necessarily adjacent following sibling selector", which granted is a long name, but at least it'd be accurate. Where's my truly general sibling selector?
When one takes in all of CSS3's selector options, the following becomes clear: the entire body of the W3C, be it user agent manufacturers (AKA, browser makers), authors (AKA, web designers) and whatnot (AKA, I don't know) feel that it's more nessecary to be able to set a style to the 3rd, 8th, 13th, 18th, and 23rd children of a given element (using E:nth-child(5n-2)), but NOT the ability to reference a sibling that precedes another with a specific trait?!
That's patently absurd!
Don't get me wrong, I'm salivating for :nth-child as much as the next developer (when I re-read that sentence, it comes across a bit... wrong), but I think there's plenty of less-complex design problems that are being ignored.
Where is a true general sibling selector when you need one?