Enterprise CSS - The bigger they are, the harder they fail
I'm *trying* to reskin (ie. make less ugly) this system where the css 'skin' that you can edit gets "processed" by some magic bullshit in the background. None of this would be a huge problem if I had actual access to the system in question to be able to properly test it but I don't, I just have the 'skin' files and a bag full of "trial and error" ready to use up.
This is an example of the type of selectors that are throughout the 2000 line css file:
af|showDetailFrame::no-header-content-light {}
Which through the magic of this wonderful system becomes:
af_showDetailFrame_no-header-content-light,.x8n {}
Now I could mostly live with that IF .af_showDetailFrame_no-header-content-light
was the class name that the html used to style the element in question. But no, of course it isn't, lets use the totally logical .x8n
class that's been created out of fat air during this processing stage. A class that the only way you can know even exists is to sift through the horrendous html that this system spits out.
What's worse is that in some places where the class/id names are actually output in the html they aren't "processed" like they are in the css file, so the rules that in theory should apply to them, don't. Only the super-user-friendly name like .x8n
work. Yay.
You end up with shit like this:
<table id="menuGlobalRegion:menuBar" class="x1j">
Where you have a class name that's only found in the processed css and an id that isn't in the original css or the processed css, and because of it inclusion of a 'colon' (and in some cases a 'pipe') it's somewhat tricky to target.
For example, in real web browsers you can target it by escaping the colon (or pipe) ... kind of appropriate that both of those words can be used to describe how I feeling about this at the moment.
#menuGlobalRegion:menuBar {}
But you can forget about IE having any idea what you're trying to do.
You could even do something like this:
table[id*='menuGlobalRegion'] {}
But again, forget IE.
On top of all this as part of the processing step, a different css file is created (and served) for each browser, and what differences there are between them seem to be minimal, and I've got no idea how it determines what these differences should be anyway because the "skin" only has on css file in it.
All this from a *new* version of what I imagine is a fairly expensive *enterprise level* system.
Now, back to deciphering this bloody voodoo witchcraft css file.
Edit: I've got nothing against 'processed' css in general, so long as it doesn't get in the way of actually get stuff done - as is the case in this situation. A large part of the problem in this instance is the rubbish html that I'm trying to re-style.