Tag Archives: Javascript

JS RX: Strict Mode interferes with back references

Strict mode prevents the use of back references within a regular expression defined with new RegExp() , mistaking them for octal literals. Use escaped strings instead.

This sucks.

The explanation:

I have a regex:

This little snippet is used to extract properties from objects portrayed as strings – as they aren’t JSON valid, but highly predictable, I’m parsing them myself.

This string:   htmlSelector: '.awe-display-code' will produce the following result:

This appears to be all fine and dandy, but we are matching based on this crucial chunk:  [\'\"`] which appears either side of our property value.

Lets say our value is encapsulated with single quotes:
If a double-quote or backtick is present in the value, the regex will stop matching there and then.

(Note, we aren’t concerned about handling escaped single quotes, for the sake of this explanation)

We can ensure that the second encapsulation character matches the first with a backreference. By making a group of the encapsulating chars through wrapping them in parentheses thus :  ([\'\"`])  we can refer to them later in the regex by their group index – in this case the index is 4, as we’ve added it before the group containing the property we wanted. Our regex now looks like this:

Problem solved!

Sadly, if our file declares  'use strict';  this will throw  an error.

The parser is mistaking \4  for a representation of an octal number, which is deprecated in strict mode.

The solution:

Instead of declaring the regular expression with new RegExp(string) , declare it as an escaped string:


Right-click and drag not working in latest Chrome (~v60+)

When I got this urgent bugfix request I thought it was going to be hell, but fortunately, it turned out to be relatively easy.

When a mouseUp event is triggered, you can check which button has been pressed with the event.button property (in some browsers event.which, and which also has different values from button, but I’m just focused on Chrome atm).

Previously in Chrome, on a mouseMove event while a button was pressed, the event.button property showed the integer for the clicked button (2 in the case of a right-click), but this was changed recently, and it now shows 0, presumably as there is not button click, either up or down, at that moment in time. Without doing any research I’m going to take a punt that this is a better match for the spec, and it does make a certain amount of sense, if one can get over the inconvenience.

The simple answer is to set a flag when the mouseDown event is triggered:

N.B. Remember to declare the initial variable previously in a scope accessible to all of your mouse events.

Then in your mouseMove event, where previously you checked event.button == 2, you can now check isRightClick:

And finally, don’t forget to toggle the flag off at the end of the mouse operation;

This has the added advantage that if you do care about x-browser compatibility and those browsers that prefer event.which,you check for the relevant property only once, when mouseDown, fires and subsequently only have to check isRightClick during the mouseMove event  – and as mouseMove can fire thousands of times, this is a tiny but worthwhile optimisation.

Frankly you should have been doing that anyway. My excuse is I didn’t write the application I’m working on, and the person who did is most definitely NOT a front-end developer!

This change was introduced recently, somewhere around Chrome version 60/61 as far as I can tell.

FullStack Conference 2017 – My talks and slideshows

TIL: Go with a light syntax theme if the lights aren’t right down in the auditorium…

Well, that’s day one of FullStack in the bag, the party is starting, there’s live Micro Drone racing, Dylan and Mark have just finished hosting ‘Have I Got Nodes For You’, and things are gearing up for the opening night blow out – there’s beer and pizza everywhere. I mean EVERYWHERE. Turns out ‘FullStack’ actually refers to the piles of pizza that were delivered by an army of guys on scooters…

Anyway, for anyone who may care to take a look, here are my slideshows from this morning’s presentations. It’s worth noting that these were live coding exercises, so the meat of the information isn’t really carried by the slides, and that the code is in the final state from the end of the talk – this is probably for the best!

[EDIT] Videos have now been added. A Skillsmatter account is required to view them.

Talk 1: I RLLY HATE Forms!

Slides on Slides.com:
Code on CodePen:
Simple form builder and validation script

(It’s true, naming things is the hardest problem in programming…)

Here’s the video – disclaimer: This was my first tech talk, and… I learned a lot about what not to do. In the interest of full disclosure, and as an object lesson in what NOT to do, I won’t try to hide it.

Talk 2: I RLLY LOVE Form Controls!

Slides on Slides.com:
Code on CodePen:
Very boring styled radio/checkbox inputs using the input+label ‘hack’*.
Sliding two state switch
CSS Tabs Widget
CSS Accordion Widgets
Cross Platform Tinder-like Swipe Effect With On-boarding
(This was based on a similar piece of code I borrowed from somewhere – I’m sorry, I’ll try and look up where to give due credit!)

And finally, the Piece dé Resistánce, for which I can take no credit, the masterful SIlon Logic Gates in Pure CSS by Schabse Laks

And here’s the video – lessons were learned from my first one (and I only had 15 minutes to regroup and redeploy) and this was a lot more successful. To those who braved the first, and yet still came to the second, I salute you!

This one was a lot of fun, and the real reward was talking to people afterwards who said the talk had helped them grasp subjects they hadn’t been able to get their head around before. Highly gratifying.

Hat Tip to the legendary Douglas Crockford, who as my ‘warm-up act’ wonderfully, coincidentally, set me up perfectly by talking about number bases.


Many thanks are due to the entire SkillsMatter team for letting me spoil their programme and providing food, beer and support, and to Dylan Beattie for putting me forward for the show.

* Sorry, @davidmarkclem but I still disagree – the label is a hack, but the label and input together are doing precisely what they were originally designed to do , so it’s not a hack – so there!