Discussion: Element ID convention for refactoring inline event handlers

[WhistlingDonkey]

Description

As part of the effort to bring SMF up to scratch to be able to properly use modern web security, inline event handlers (onclick, :void etc) will need to be refactored. Whether all the events can be put into loaded script files or not I don't know but first things first is that all these elements that use inline event handlers need to have element id's added so listeners can be attached. While it's not a problem as such that it's hard to do there's somewhere around 300+ elements that will require this. Because there's so many I figured it'd perhaps be good idea to come up with some sort of naming convention for all these id's.

[albertlast]

Would be this not the point to use some kind of framework,
How provide such in common?

[jdarwood007]

This is too late in 2.1 to fix this. however it could be looked at for future versions. They don't all need to go into files, but noonce can be used on them.

[WhistlingDonkey]

@jdarwood007, yep, I know it's too late for 2.1 and I fully understand that but it really can't wait another 6 years (given the speed that 2.1 has happened at, not taking a dig) for 2.2 either. I've already done nonces, along with all the other security headers and a 90% complete SRI implementation so refactoring is just about the last thing to do (you can see what I've done on my http-security branch if you so desire).

The thing about nonces in your comment though is that they can not be used for inline event handlers ie, <a href="#" onClick="xxx;">link</a> can not be nonced and once the (modern) browser has a nonce that inline onClick will no longer work unless you specifically allow unsafe-inline, which defeats the purpose of script security, and it still may not work depending on what else is specified for script-src in the CSP.

[live627]

I'd be inclined to match already existing naming styles as seen in the CSS, using underscores as separators.