h a l f b a k e r yJust add oughta.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
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....
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Destination URL.
E.g., https://www.coffee.com/
Description (displayed with the short name and URL.)
|
| |
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. |
|
| |
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. |
|
| |
//those of us who don't enjoy living in the 90s// heretic |
|
| |