Title
Disable copy and paste/right click function for posts

Short, concise description of the idea
Give an option for posts to be protected from users who copy and paste text/right click and save pictures and post it somewhere else without credit for the original poster.

Full description of the idea
Protecting intellectual property should be given greater priority today. Livejournal entries now range from original fiction to sharing of copyright material, all of which infringe on the hard work of individuals or companies. While posts are made to share and expose works to the community, there should be no reason for users to be given the chance to steal work without credits as often the case today. Not to mention, original works are not officially given copyright and authors cannot chase down those who steal their work and post elsewhere while collecting revenue from the advertising on their sites.

Scripts that disable copy and paste/right click are not allowed to be incorporated into livejournal, therefore LJ should consider putting this option up and reduce the headaches of other users.

• Protect intellectual property.
• Prevent spread of copyright materials (since there is only one copy online)
• Reduce likelihood of intellectual piracy.
• Thereby encourage more people to share their work online without fear of pirates.

• Not welcome to pirates.
• Experts may be able to crack the code and steal the stuff anyway.

Title
Embedding Google Waves in LJ

Short, concise description of the idea
Enable Google Wave to make a post in LJ, which also embeds an entire Wave in said LJ post.

Full description of the idea
Blogspot and Wordpress already have bots or plug-ins embed Google Waves into Blogpost or Wordpress posts, and it'd be great if LJ has something like that too.

The entire wave is embedded in the post, so other Wave users can interact with the embedded wave as if they were in their own Wave clients i.e. they can edit and reply to the Wave, they can input their own content through drag and drop, they can use the Playback function etc.

For a demonstration of the Blogspot-Google Wave integration, please see minutes 3:11 to 4:15 of this video here: http://www.youtube.com/watch?v=p6pgxLaDdQw

And the WordPress plug-in is here: http://mashable.com/2009/09/08/google-wave-wordpress-plugin/

Resources LJ will need to implement this here: http://code.google.com/apis/wave/

• Richer user interaction without taxing LJ, since it's the Google Wave that's doing the heavy lifting.
• Integration with one of the most exciting new products on the Internet makes for a great reputation for LJ.

• There should be at least one person on the LJ Dev team who already has a Developer's Preview.

Title
Userpic Factory behavior without javascript is broken.

Short, concise description of the idea
When I upload a 100x100 userpic with javascript disabled, it creates a userpic cropped from a small corner of the image I uploaded.

Full description of the idea
It should just use the original uploaded image, scaled down if necessary.

• Being useful ever.

• None.

Title
embed whitelist

Short, concise description of the idea
We're all aware we can't embed twitter badges (that aren't butt-ugly) or Flickr badges, etc, into our profiles/sidebars/etc, due to stability concerns (at least that's what I assume is the reason). How about a 'white list'?

Full description of the idea
By starting a list of acceptable embeds that LJ has confirmed does -not- break the site, users can better consolidate/promote their presence elsewhere online. I know I'd love a flickr badge to my profile over there, rather than a simple link. Similarly I'm sure a LOT of people would prefer twitter users had a badge on their journal rather than loudtwitter spam clogging friend pages. It's not so much that I want to post my tweets to my journal as having my twitter feed accessible from my journal - be it a profile or sidebar item.

• Starting a list of approved embeds (there's probably a more appropriate term for what I'm talking about) will control what can be posted from the LJ side.
• A list will give users a place to browse and pick and choose things they can include in their journals they weren't necessarily aware of before.
• Social networking bonus points.

• Someone will have the odious task of approving/disapproving embed/applications.
• If word gets around that there is a 'white list' in the making, there may be an influx of suggestions.
• There could be some cross-layout issues, but I'm not entirely sure how that works.

Title
Allow limited access to scripting, beyond current embedding options

Short, concise description of the idea
Loosen restrictions on scripting in journals.

Full description of the idea
By disabling almost all JavaScript and IFRAMES, LiveJournal is preventing access to a large number of the advantages of the Semantic Web in the name of security. Perhaps the feature could be restricted to permanent and paid users--users with a financial stake in LiveJournal are probably a lower risk [EDITED: The stricken assertion strongly rebutted in comment-space. Read the comment threads for alternate implementation suggestions].

• LJ users can take advantage of various semantic and "Web 2.0" tools, mashups, and extensions.
• Stay competitive with Blogger, WordPress, and other platforms that allow these technologies.
• Some tools out there automate the addition of Affiliate tags, allowing one to "monetize" links from their journal.

• Harder to prevent cross-site scripting attacks and content that breaks friends pages.
• Care must be taken to prevent "breakage" of friends and friendsfriends views.
• Possible increase in support issues that are actually related to embedded or scripted content from other sites.

Title
Journal embedding through JSON

Short, concise description of the idea
Allow access to the content of your LiveJournal through JSON, so people can embed it in their web sites through JavaScript.

Full description of the idea
JSON is a lightweight means for passing data through JavaScript. Making LiveJournal posts available through JSON would allow users to customize the way they embed their LiveJournal in other pages without placing a load on their web server. (The current method simply inlines the journal's exact style via document.write(), which doesn't work in XHTML.) Del.icio.us have already demonstrated this kind of feature.

For example, this would make it possible to place a list of the titles of your most recent posts in a page, and have those link to the full text of each post.

• Embedding in HTML will become much more flexible, allowing end users to create a wide variety of scripts without requiring vetting by LiveJournal personnel.
• Embedding in XHTML will become possible through means other than frames.
• Friends would be able to see protected entries, since the cookie could be read out of their browser; a web server based solution would be unable to do this.
  

• The interface between LJ's internal database format and the JSON converter will require maintenance.
• Badly behaved scripts may hammer the JSON converter and require some form of throttling.
  

Title
Lightbox on LiveJournal

Short, concise description of the idea
An addition of the Lightbox function inside a LiveJournal entry and as standard for the ScrapBook.

Full description of the idea
Adding a Lightbox function for LiveJournal entries as a tag such as image location and then if you wanted to create a mini gallery, as it allowed with the Lightbox script just do image location.

As standard for the ScrapBook but with the option of having it off or on.

• Better way of organising images.
• Looks nicer.
• Additional options for users.

• Hard to implement on the ScrapBook?
• Legal issues?
• Compatibility issues with older browsers.
• Security?

Title
Add support of Dean Edward's IE7.js script as an option for customized journals.

Short, concise description of the idea
The IE7.js file predates Internet Explorer 7 by a large margin, and allows earlier versions of Internet Explorer to mostly handle advanced CSS effects correctly.

Full description of the idea
The homepage for the script in question is:

http://dean.edwards.name/IE7/

It has extensive documentation and examples available, and only requires (at a minimum) a single .js file be included in pages, either all or only those served to Internet Explorer 5.0, 5.5, or 6.0 under Windows.

• Allows IE5-IE6 to much more fully support CSS, including advances effects commonly requested in styles, and also including modern graphics-file formats like transparent PNG files.
• Easy to only include if requested, can be made a switchable setting on a per-journal basis for those journals customized in such a way as to benefit from the script.

• Slows the client-side page rendering fractionally when the script is first loaded and it runs through and 'corrects' all the HTML code automagically to work much closer to spec.
• Adds to the download size initially to fetch the .js file.

Title
Ajax-ify LJ cuts

Short, concise description of the idea
Add a taste of Ajax into LJ-cuts, so clicking on them reveals the cut text, instead of needing to go to another page

Full description of the idea
Instead of an LJ cut tag adding a link to the post's page and anchor for the location of the cut, have it add the javascript/css/fun stuff needed so that when you click on the cut, it just slides down and there's the cut contents, right where you are.

• No need to leave your friends page to read stuff under a cut
• Less page loads since you its all on one page
• It would look really slick :-p

• Additional coding overhead may be prohibitive
• If several images are behind a cut, they would still take up bandwidth when loading the page, even if the cut was hidden (unless extra extra code was written to only load images when the cut is revealed) EDIT: it has been pointed out this would not be a problem. Proper AJAX would not load the content until the link is clicked.

• possibly definitley add an option for users to enable/disable it, both for viewing (eg: I don't want any lj-cuts I see to be ajax") and creating (eg: "i dont want my lj-cuts to be ajax")

Title
Reduce dependency on JavaScript

Short, concise description of the idea
When an old page is replaced with a new version that uses fancy JavaScript, a link should be provided to the old version.

Full description of the idea
LJ is introducing a lot of new features which need JavaScript (the Xcolibur sitescheme, QuickReply commenting, AJAX commenting, the new update page, the new S2 editor, the proposed new portal page...). This is all very well, but not all these features degrade gracefully for people who don't have JavaScript or don't have modern browsers.

Obviously the developers can't be expected to make every page compatible with every weird or ancient browser out there. Hence I'm proposing that JavaScript heavy pages provide links to non-JavaScript pages, a bit like Gmail's "HTML only" version.

So for example, update.bml could include a link to /old/update.bml, the new S2 editor could provide a link to the old S2 editor (which was ugly, but a lot more widely usable than the new one). Ideally, it should be possible to set a site-wide preference in a cookie that you don't want to see JavaScript on site-based pages, but that would be more work and perhaps not justified.

• More features of the site would be useable for everyone. I'm talking about some pretty core features, like the ability to post entries or reply to comments, not just frivolous add-ons, here.
• Not everybody has the ability to upgrade to a newer browser or change their JavaScript settings.
• The range of ways people can access the web is growing all the time. As well as catering for older computers, LJ should consider new technologies like WAP and who knows what might be invented in the next few years.
• People who find they can't display a page properly are very likely to just give up and leave the site. Having lots of JavaScript which is broken for many users is ultimately going to cost business.
• Better accessibility. The more of the site is available in as simple a format as possible, the more easily people with various disabilities are going to be able to use it.
• The old, easily useable versions of pages already exist, so this would require little or no new coding.
• Less developer effort spent on making JavaScript work cross-browser. If users have the option to use the old version, it will be less of a problem when unforseen bugs show up. For example, there was a huge kerfuffle over QuickReply until eventually an option was provided to turn it off; had that been available from the start, that would have been avoided. Likewise, there was a lot of stress and emergency patching needed to fix the update page so that it was even vaguely workable for a large number of users.
• Lots of people dislike change, so having old pages available would quell some of the whining when a new feature is introduced.
• Even though the proportion of users who can't deal with modern JavaScript may be small, in absolute numbers it's a lot of disgruntled users because the userbase is so huge.

• JavaScript looks cool and modern.
• Some of the old versions of pages are pretty sketchy.
• Some new features might just not be possible without JavaScript.
• It's generally good to retire obsolete code rather than keeping it running in parallel with new code.
• It might be argued that it isn't worth any effort at all, even the most trivial, to support minority browsers.

• If an old HTML / BML page is replaced with a new JavaScript page, the new JavaScript page should contain a link to "HTML only version", and the old version should be kept available on the site.
• If a new feature is introduced that relies on JavaScript, the option should always be added to disable it, at least in the console (qv QuickReply comments).
• There should continue to be an option to display comment pages in the sitescheme (as there is now), even if that ceases to be the default. [link]