Half a croissant, on a plate, with a sign in front of it saying '50c'
h a l f b a k e r y
Oh yeah? Well, eureka too.

idea: add, search, annotate, link, view, overview, recent, by name, random

meta: news, help, about, links, report a problem

account: browse anonymously, or get an account and write.

user:
pass:
register,


       

Please log in.
Before you can vote, you need to register. Please log in or create an account.

User-Supplied JavaScript

OK, Jutta isn't interested in writing JavaScript, but what about other folks?
  (-1)
(-1)
  [vote for,
against]

Before the fishbones fly, please let me explain. Having looked at the source code for a typical HB page, and seen comments by [jutta] that she isn't interested in using JavaScript, I'm quite aware that this Idea may not be acceptable. But....

The fact is, some pages actually already do include JavaScript --there is a "jumptofirst();" function call in the HTML "body" tag of the page I edited, to CREATE the text of this Idea-page, but not on the created-Idea page. I see that the "onload" attribute of the "body" tag is still present, but it is not connected to a function call; it COULD be harmlessly defaulted to onload=";".

It happens that the syntax of JavaScript could allow another function to be included, like this: "jumptofirst();userfunc();" or perhaps more simply ";userfunc();" when the jumptofirst function is not present. The default "userfunc" for a given page would be basically empty (or a simple "return;" statement). The net effect is, no change for any page that does not have user-supplied JavaScript.

When an ordinary Idea page is loaded, below the Idea are currently-existing "link" and "annotate" options. A "JavaScript" option could be added, but would only appear when the author of the page loads the page (like "edit" options for links and annos only appear to the authors of those links and annos).

When the JavaScript option is clicked, a normal editable textbox would appear, into which JavaScript code could be written, starting with the empty/default "userfunc". Other functions could be created, and get called inside the userfunc. It would be highly recommended that development of the code be done outside the HB environment (and simply be pasted into the textbox when perfected), due to the following necessity.

It would be unwise to let that code appear to generic HB users without it getting vetted, first. THIS Idea is Half-Baked because I'm not sure who might volunteer to do such vetting, to ensure the user-supplied JavaScript is safe to actually be part of an ordinary Idea page (computer science students at the university where the HB (last I heard) is hosted, wanting credits?). That is of course another reason why this Idea could get fishboned.

Well, that's enough for now. Things could get lots more complicated, because some folks writing JavaScript are also going to want to write some HTML code, so that the page will have extra elements in some sort of "sandbox" portion of the overall HB page, with which the JavaScript could interact --and that would open up even more possible cans of worms. But, imagine the fun possibilities, when all just happens to get done safely....

Vernon, Jan 20 2016

[link]






       This is pretty silly. (Not my bone though.)   

       There is (or was) a browser extension called Greasemonkey that lets you do everything you're asking for without any need for a webmaster (or webmistress) to get involved. The changes are only visible to those with the extension installed, but are semi-permanent.   

       Incidentally, your use of "userfunc" seems a bit pointless if you were planning on embedding the user's code into the page - it can access any event or any other bit of the html on its own. The only reason to pass it through a function call would be if you were including the code from an external source and wanted to get around the cross-domain restrictions.
mitxela, Jan 20 2016
  

       Userscripts wouldn't require [jutta] to put in any function calls to support them. Look at all of the userscripts and functionality-enhancing browser extensions available for other websites: I think over 99% of them are not supported or facilitated in any way by the websites they work on. JavaScript can manipulate anything on the page; there's no need for a website to build in ways for them to do it.   

       I have long thought that a userscript or extension for this site would be nice to have, to avoid the necessity to load a whole new page for every action, among other things, for those of us who don't enjoy living in the 90s as much. I might make one (but probably won't, because I'm lazy and busy).   

       There's no Halfbakery API, but it could generate the old-fashioned form submissions behind the scenes and display and update one page for the user. Should be no extra server load; the same requests would be sent as if the user was doing them manually.   

       "Other things" could include floating the sidebar down the page so you don't have to scroll up to see the tagline, highlighting annotations and links added since you last visited a given Idea, automating quoting, etc.
notexactly, Jan 20 2016
  

       //those of us who don't enjoy living in the 90s// heretic
pocmloc, Jan 20 2016
  
      
[annotate]
  


 

back: main index

business  computer  culture  fashion  food  halfbakery  home  other  product  public  science  sport  vehicle