Here's a minimal test case:
http://caer.me/clickhandler.html

I suspect an IE-specific conflict between the ca. 2008 css list js and jquery that I injected my little submenu into.

I got it working. Am I going to now obsessive-compulsively troubleshoot an issue between a really old (and rather complex) javascript, jquery and IE10?

In a word, no.

Well sure, if it's an isolated case then no point losing sleep over it. Like you said earlier, the user isn't going to be looking at the source anyway, so if it works, no big deal.

You are not PB.

It's quite simple:

    •  If all you want to do is whine about how useless you are at debugging trivial JS issues, use Ranter's Corner.

    •  If you want to receive advice on how you can stop being useless, post in Coding. It's not like these folder things are new technology or anything...

 (heart)

Um, and?

It's a blessing.

No doubt, but why bring it to my attention?

Peter could never bring himself to post what you said, unless he dropped acid a thousand times.

I don't expect he will, though.

Except I have at no point told you to lose sleep, and specifically identified it as a trivial issue.

Whether or not a random person decides to view source is irrelevant. More relevant, however, is whether a developer will come along in six months to make a change and wonder who did the ugly hack and why - they will of course be able to check the source control commit history for that line and see the explanation for making that particular change, right?

The web site is a whole ugly dog's breakfast. I chose the least intrusive route. Which paid off when I discovered my additions are compatible with ie7+ with a couple of minor CSS hacks (apologies; I know how repugnant you find this, you loon). The website is overripe for a complete rebuild, but ... not my call (or yours).

"the source control commit history"

You're joking, right? Please tell me you're joking.

Seriously? The web site is a whole ugly dog's breakfast, so you're modifying it without using source control, because that makes so much sense.

Jeepers! Next you'll be saying you were working directly on the live server for those three hours.

The live site hasn't been touched.

For you, I recommend the acid therapy. Begin today.

Unlike yourself?

Been there, done it. :O)

:'D (fail)



Since I've recently started a job which could be classed as slightly corporate I've noticed a reliance on IE. I was sent a link to sign up to something by one of the MDs and when opened in Firefox it said I should probably use IE. When I opened it in IE I got that up there.

Our SAP CRM system only seems to function properly in IE too. It's usually a slow pile of shit though.

No source control? At all? Good grief.

You could at least stick the whole thing in a local Git repo, if only to keep track of what you've done yourself.

That is something I need to do for many of my little projects. I always end up with multiple different revisions all over the show :$

Hah :D It's not even difficult or slow

git init .

Then create/edit the .gitignore file and add the names of any files you don't want included in the repo (passwords, compiled stuff etc.), then

git add .
git commit -am "Yay, my first commit!"

That sets everything up. Then when you make changes:

git add lib/some_new_library.rb
git commit -am "Add SomeNewLib to repo. Fix a broken thing."

The '-am' parameters mean, respectively: automatically add modified files to this commit; use the last part of the command (the bit in "quotes") as the commit message.

You can make a new branch based on the current one:

git checkout -b fancy_feature

The -b means 'create a new branch'. Leave it out to switch to an existing branch. You can merge changes from another branch to the current one:

git checkout master
git merge fancy_feature

This switches to the branch 'master', then merges 'fancy_feature' into it. If you edit the same part of a file in two different branches, then try to merge them, you'll get merge conflicts, which are a pain in the arse to fix, so don't do that.

To see which branch you're on, and what files have changed since last commit:

git status

To see what specific changes you've made since last commit:

git diff

You can include a filename after that to only diff that specific file.

Thus concludes my 5-minute intro to Git.