Wrong docs name for option to enable inline javascript
DanielBielczyk opened this issue · 10 comments
Docs state that you can use { inlineJavaScript: true } to enable inline JavaScript. But it should be { javascriptEnabled: true }
But it should be
Too subjectively (like in "No, it should not").
Closing as not an issue (no reasons to introduce new issues and breaking changes just because of questionable linguistic preferences).
It's not subjective linguistic preference. javascriptEnabled is option name used in code. inlineJavaScript doesn't work.
I should have made myself clearer, sorry...
OK, I see what you mean now - my bad. Fixing the docs right now.
Fixed in be2020e.
javascriptEnabled was renamed inlineJavascript, which should allow either for back-compat. If it's not, that's a bug.
To answer this:
https://github.com/less/less.js/blob/c93c854d64dcdd2ff35bcd2657b29772f10dcd2a/lib/less-browser/add-default-options.js#L46-L47
The javascriptEnabled option is confusing, but was less ambiguous before @plugin was introduced. Javascript is always "enabled", and setting javascriptEnabled=falsewill NOT disable using JavaScript in your Less style sheets. But it WILL disable using INLINE JavaScript. You can still call JS plugins and call JS functions all over the place in your Less code.
IMO javascriptEnabled=false is simply not correct, if a user's expectation is that JavaScript usage will be disabled. It will just be disabled for usage inline. Hence, inlineJavascript=false.
But....if it's clear enough that it refers to inline JavaScript only (missing from current docs), and it wasn't correctly used in 3.x, then I guess this change is fine.
if a user's expectation is that JavaScript usage will be disabled.
Or is it just a bit of overthinking?
Sure in a wild forest one can imagine expecting it to disable whatever JS (e.g. plugins), but the same way he can imagine expecting it to disable Less compiler itself, JavaScript within a browser - and all the weird things... :)
Should we really bother? In this particular case I'd just follow the "don't change what's not broken" way (the option may be called in whatever crappy way as soon as it's properly documented. I absolutely do not mind the inlineJavascript change but are various transition burdens really worth the result? I.e. before we had no issue, now we have at least one :) And I feel like this "So is it inlineJavascript or javascriptEnabled?" story to be continued :(
Should we really bother? In this particular case I'd just follow the "don't change what's not broken" way
No, I'm not emotionally invested in it. Especially if I didn't successfully rename this in the 3.x changes anyway. I think it might be potentially confusing, but we could revert any changes to javascriptEnabled and then revisit later if someone is ever confused.
We should probably release latest docs.. 25 days after fix and I was still wondering why inlineJavascript option (from docs) doesn't work.
@dwelle Thanks for the reminder. Pushed.