I’ve helped a few users here on the forums with some CSS injection:
I’m just playing with the idea of creating a custom browser plugin for Coda to make these injections much easier.
Imagine a list of checkboxes for each of these features above that users could enable and disable at will
Is this something Coda would allow? Seeing Coda’s response to Paul (“… violation of our terms of service”) makes ideas like this a bit disheartening
1 Like
Well, overriding CSS shouldn’t have that potential delayed impact as supplying a random invalid value to a private API with no validation in place that might not break the doc immediately but could break it sometime in the future.
@Jason_Tamulonis what would you say?
P.S. Coda isn’t evil when it comes to enforcing their TOS, otherwise I would be long gone 
It’s just that as a white hat, it’s sorta my responsibility too to make sure that Coda doesn’t suffer from my tricks and whatever I find doesn’t cause a situation where at any point in time something breaks and it’s them who take a hit for it. This already happened with discovering hidden formulas: they told me they still spend quite some effort to keep those operational because so many people depend on them already. I didn’t even realize this.
2 Likes
Oh, I thought they had an issue with us tinkering in the front-end code in general. If they only have an issue with the API hack then that’d be great! But I’m afraid that’s not the case
In order to override CSS the extension needs full access to the DOM. Perhaps they’d allow it if it’s open source?
I totally understand where Coda is coming from! The issue is that they’ve drawn a line in the sand with the width of a car. I’m afraid of being shut down, just like you were, after investing a bunch of time.
It really sucked seeing them shut your project down by the way, that project had amazing potential. Why can’t they just let people use it at their own risk?
Because people will still come to Coda for support, and they’ll have to allocate an engineer to salvage their doc snapshot that might’ve had a wrong value stored somewhere in its data. The value was silently consumed and didn’t cause any trouble back then but eventually resulted in a broken doc
(remember how supplying a wrong color or as little as typing the first letter “B” between quotes in the Button formula already crashed the doc and you couldn’t open it anymore? imagine that you’ve created a button with the color “Grey” instead of “Gray” with such hidden API back in June and it just got ignored, and in December your doc suddenly crashes as soon as you try opening it)
Thanks for the compliments too. The time wasn’t spent in vain; I do use that extension myself and only in the environments that I control. Coda can sleep safely knowing I won’t ever bother their support if anything breaks about it. Just recently I installed it for a client who needed the cursor to jump back to the input field after pressing a button; they’re running a semi-automated photobooth with a barcode scanner and thanks to my hack they can run it on Coda. It also saves me time with my own docs.
2 Likes
That makes sense, thank you! It makes me a bit more hopeful about their verdict on a browser extension, I’d just like to know where they draw the line on this project before I begin
- Would you (Coda) allow an open source CSS injector extension?
- If so, what if it could inject JS too, for example to easily transpose a table?
- And if so, what about if it wasn’t open source?
Hi @Rickard_Abraham - My advice for all developers is to only build against the supported extension points, like the Coda API or Packs SDK. Building against an internal interface, whether that be an endpoint or our DOM, is inherently risky. As @Paul_Danyliuk mentioned one of the primary concerns for Coda is the added support burden that can arise.
2 Likes