### Allow users to specify an account as a roleplaying account

10:24 am
Title:
Allow users to specify an account as a roleplaying account

Area:
accounts, statistics

Summary:
Allow users to specify an account for roleplay without affecting paid account services.

Description:
This is a suggestion mainly for statistical purposes! Dreamwidth has an active, sizable roleplaying community, a consequence of which is that there are a lot of "character accounts" scattered across the site. As someone who's very curious about DW's site statistics, I can't help but think that means there's a lot of essentially fictional data skewing things one way or another.

If possible, I'd like for roleplayers to be able to specify an account as being made for roleplay. It would have to be in a way that doesn't affect paid services, since some get paid/paid premium accounts and some don't. In addition to being able to choose it during account creation, there would also need to be an option for existing accounts to "switch over", since there are many, MANY existing character accounts.

Challenges involved: oh boy! I'm not at all familiar with site coding, especially Dreamwidth's, so I can't imagine how complicated this might be. I also don't know how many people would actually use this option, but I thought I'd throw this out there anyway.

Poll #18026 Allow users to specify an account as a roleplaying account
Open to: Registered Users, detailed results viewable to: All, participants: 56

This suggestion:

Should be implemented as-is.
33 (58.9%)

Should be implemented with changes. (please comment)
1 (1.8%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
21 (37.5%)

1 (1.8%)

### Add "Edit entry again" to Journal entry was edited Success page

11:48 am

Title:
Add "Edit entry again" to Journal entry was edited Success page

Area:
entries

Summary:
Add "Edit entry again" to Journal entry was edited Success page "From here you can" options.

Description:
The page Success when one has edited a journal entry is:
<blockquote>
Success

Journal entry was edited.

From here you can:

* View this entry
</blockquote>

Having another option be "Edit this entry again" would be handy when one is making a number of changes to the same entry in a row, or saved and immediately realised another edit to make.

Poll #15507 Add "Edit entry again" to Journal entry was edited Success page
Open to: Registered Users, detailed results viewable to: All, participants: 61

This suggestion:

Should be implemented as-is.
54 (88.5%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
7 (11.5%)

0 (0.0%)

03:52 pm

Title:

Area:
entries

Summary:
see title

Description:
I'd like to be able to link to youtube accounts with the DW tag. Currently it's not possible because youtube uses /user and not /users.

Open to: Registered Users, detailed results viewable to: All, participants: 45

This suggestion:

Should be implemented as-is.
26 (57.8%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
3 (6.7%)

(I have no opinion)
16 (35.6%)

0 (0.0%)

### Add a new HTML tag to allow navigation across multiple entries in a single tag

09:03 pm

Title:
Add a new HTML tag to allow navigation across multiple entries in a single tag

Area:
tags, entries

Summary:
Across the web, multi-part series often have a section of navigation links to enable readers to find their way across multiple pages, articles, etc... First/ last page, prev/ next, list all pages/ articles... there's lots of different ways to make it easier for the reader. What I propose is to add a new HTML tag, like <cut>, that will auto-generate some navigation links when included in an entry.

Description:
This suggestion is based on an idea that I had on LiveJournal last year [ http://suggestions.livejournal.com/1107879.html?thread=17520039#t17520039 ]. The idea is that when an author has written something in several parts, whether that is fanfiction, how to articles, a travelogue, or a guide, the existing tag navigation is often insufficient for a reader to browse the entire series.

Say I've written several different entries about my experiences traveling in Scotland. I could just rely on the reader to click on the "Scotland 2012" tag and find all the entries. If I have more entries in this tag than fit on a single page, the reader might miss some. Alternatively, I could edit every entry in the series whenever I publish a new entry, making sure to link to the next in the series, and maybe the latest, and possibly make sure that each entry in the series links to all the others. But that's a lot of work, and it gives a high likelihood for error.

So what I suggest instead is a custom HTML tag that will auto-generate navigation links. At the end of any entry in my series I could add a tag like <series tag="scotland 2012">. This would be displayed in the entry like so:
scotland 2012
First - Prev - Next - Last
Subject of 1st entry
Subject of 2nd entry
Subject of 3rd entry
* Subject of 4th entry, the one currently being read
Subject of 5th entry

If the series contains more than five entries, the fifth and subsequent entries should be hidden behind a link to save space. In addition, there could be several options. Perhaps you can include a title, so instead of saying "corruption" the navigation link header might read "Bribery in City Hall". Maybe the author would like the articles displayed in reverse-chronological order. Or maybe the author wants to include the date/time stamps along with the entry subject line.

One advantage of this approach is that no new UI is needed. All of the links are included as part of the entry, instead of attached to the entry, so no new buttons are necessary. And since the links are auto-generated, authors only have to remember to add the 'series' tag once, when they first write the entry, instead of having to constantly update every entry in the series.

Poll #14594 Add a new HTML tag to allow navigation across multiple entries in a single tag
Open to: Registered Users, detailed results viewable to: All, participants: 45

This suggestion:

Should be implemented as-is.
19 (42.2%)

Should be implemented with changes. (please comment)
11 (24.4%)

Shouldn't be implemented.
8 (17.8%)

(I have no opinion)
7 (15.6%)

0 (0.0%)

### Add a CSS Class to Comment Count on View Month Page

10:00 pm

Title:
Add a CSS Class to Comment Count on View Month Page

Area:
styles

Summary:
Right now there is no CSS class for the comment count shown after each post on the View Month Page (this page and all pages like it): http://exampleusername.dreamwidth.org/2013/01/. I've had to add sort of wonky CSS to compensate for that. The CSS doesn't target anything specific so in my case it messes things up (for instance, on my DW, it results in comment count text displaying both too small and too big - yes, all at the same time - which could be my own error, but still). So my suggestion is to simply add a separate span class for the comment count on the View Month page so it can be styled independently of other elements on the page.

Description:
Right now there is no CSS class for the comment count shown after each post on the View Month Page (this page and all pages like it): http://exampleusername.dreamwidth.org/2013/01/. I've had to add sort of wonky CSS to compensate for that. The CSS doesn't target anything specific so it messes things up (for instance, on my DW, it results in comment count text displaying both too small and too big - yes, all at the same time - which could be my own error, but still). My suggestion is to simply add a separate span class for the comment count on the View Month page so it can be styled precisely and independently of other elements.

Poll #14590 Add a CSS Class to Comment Count on View Month Page
Open to: Registered Users, detailed results viewable to: All, participants: 33

This suggestion:

Should be implemented as-is.
17 (51.5%)

Should be implemented with changes. (please comment)
2 (6.1%)

Shouldn't be implemented.
1 (3.0%)

(I have no opinion)
13 (39.4%)

0 (0.0%)

11:43 pm

Title:

Area:
styles, entries

Summary:
When you mark a comment as an official admin/mod hat comment, it applies the admin-post class to the comment's comment-wrapper, but the same does not happen when you mark an entry as official. The entry-wrapper does not gain a admin-post class. I suggest that it does so you can use css to format those posts separately from others.

Description:
When you mark a comment as an official admin/mod hat comment, it applies the admin-post class to the comment's comment-wrapper, but the same does not happen when you mark an entry as official. The entry-wrapper does not gain a admin-post class. I suggest that it does so you can use css to format those posts separately from others. Personally, I'd love to use this as a way to call more attention to those specific entries without having to use a .poster class and have everything marked by a specific user stand out.

Open to: Registered Users, detailed results viewable to: All, participants: 37

This suggestion:

Should be implemented as-is.
24 (64.9%)

Should be implemented with changes. (please comment)
1 (2.7%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
12 (32.4%)

0 (0.0%)

### Small change for filter option when posting an entry

02:50 pm

Title:
Small change for filter option when posting an entry

Area:
Post an entry

Summary:
Right now, in order to designate an entry as viewable by a certain filter, one must select 'Custom' from the 'Show this entry to:' dropdown menu. Only then do the individual filters show up as checkboxes. I think it would be clearer if the option said something like 'Access Filter', or if the filter checkboxes were visible from the get-go.

Description:
Well, I'm not sure how much more I can say about it! Just that it's not very clear to a first-time user that there are Filters, and I remember I was a bit confused as to the wording of that dropdown menu option myself. If it's just a text change, it's a pretty minor thing and I don't think there are any drawbacks or problems.

On the other hand, listing out the filters and their checkboxes right up front would also solve the issue of clarity, and streamline the selection of a filter. I never really saw the point of having filters hidden until you select 'Custom', from a user's point of view. But I understand that it's probably more complicated, codingwise, to (e.g.) have the checkboxes right there and make the dropdown automatically jump to 'Custom' when the user clicks a checkbox.

Poll #13651 Small change for filter option when posting an entry
Open to: Registered Users, detailed results viewable to: All, participants: 31

This suggestion:

Should be implemented as-is.
6 (19.4%)

Should be implemented with changes. (please comment)
13 (41.9%)

Shouldn't be implemented.
3 (9.7%)

(I have no opinion)
9 (29.0%)

0 (0.0%)

### Markdown info in comment notifications

07:23 am

Title:

Area:

Summary:
Responses to comment e-mails are formatted in Markdown, but this is not mentioned anywhere. I suggest adding a short sentence about this to the e-mails, something like "this comment will be formatted using Mardown (link to FAQ, including how to escape)"

Description:
Responses to comment e-mails are formatted in Markdown, but this is not mentioned anywhere. I suggest adding a short sentence about this to the e-mails, something like "this comment will be formatted using Mardown (link to FAQ, including how to escape)"

Poll #13639 Markdown info in comment notifications
Open to: Registered Users, detailed results viewable to: All, participants: 44

This suggestion:

Should be implemented as-is.
30 (68.2%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
14 (31.8%)

0 (0.0%)

10:00 pm

Title:

Area:
search

Summary:

Description:
Hiragana, katakana, and kanji should be added to the new comment search ability!
Many people write in these.

Poll #13637 Other alphabets to add
Open to: Registered Users, detailed results viewable to: All, participants: 42

This suggestion:

Should be implemented as-is.
28 (66.7%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
14 (33.3%)

0 (0.0%)

### Add an "are you sure?" dialog to the ban user process

07:22 pm

Title:
Add an "are you sure?" dialog to the ban user process

Area:

Summary:
Right now, it is easy to hit "Ban User" unintentionally and not know it. A dialog asking if you're sure would be helpful.

Description:
Right now, "Ban user" is one of the options that appears when you hover your cursor over a user's icon. The option is right above "View Journal," which makes it easy to hit accidentally.

If you click "Ban user," the option changes to "Unban user" -- but no other changes happen on the screen. It is easy to assume you just missed the "View Journal" button and click again without noticing the dialog change.

Right now, it is way too easy to ban someone unintentionally and never find out. If the banned person is polite about the ban and leaves you alone -- you'll never know why they unfriended you and went away.

An "are you sure?" dialog would make sure you didn't leave a user banned by accident. It would only add one step to banning people, so hopefully it wouldn't impair the usefulness of the feature for people who actually want to ban someone.

I think the extra dialog would be easier than sending a notification that you've banned so-and-so, although that's another option. I just don't want to ban someone and not know about it.

Poll #12915 Add an "are you sure?" dialog to the ban user process
Open to: Registered Users, detailed results viewable to: All, participants: 80

This suggestion:

Should be implemented as-is.
68 (85.0%)

Should be implemented with changes. (please comment)
1 (1.2%)

Shouldn't be implemented.
1 (1.2%)

(I have no opinion)
10 (12.5%)

0 (0.0%)

### On the system default footer for crossposts, make the word OpenID a link to information about OpenID

12:53 am

Title:
On the system default footer for crossposts, make the word OpenID a link to information about OpenID

Area:
crossposting

Summary:
According to http://www.dreamwidth.org/manage/settings/?cat=othersites the current default footer for crossposted entries is
<span style="font-size: smaller;">This entry was originally posted at <a href = "%%url%%">%%url%%</a>. Please comment there using OpenID.</span>".

I suggest changing it to
<span style="font-size: smaller;">This entry was originally posted at <a href = "%%url%%">%%url%%</a>. Please comment there using <a href="http://www.dreamwidth.org/openid/">OpenID</a>.</span>

Description:
I believe that many people, particularly users of LiveJournal who don't try to use their LJ as their main cross-site "internet identity", may not understand that the phrase "Please comment there using OpenID" at the end of a crossposted DW post using the default footer means they are likely to be able to comment on that post at Dreamwidth without creating a DW account by using their LiveJournal account via OpenID. They may not have any idea what OpenID is or that they already have one (or several) OpenID identities that they can use with minimal hassle. I base this assumption on the fact that I've had reasonably clueful LJ friends post anonymously to my DW posts and "sign" them in the body or subject line with their LJ identity rather than post them using OpenID (based on the type of comments, this is not a situation where it's likely someone is impersonating someone else).

Turning the word OpenID in the footer into a link to http://www.dreamwidth.org/openid/ would give readers a way to find out more about what OpenID is (and a place to log in using it) without cluttering up the footer with additional explanatory text. I am making the assumption that the amount of detail to include in the system default footer has been previously considered and that it's been decided not to include a lengthier explanation of OpenID in the text of the footer itself (I can see arguments both for and against this).

Note: I have no idea what the system default footer crosspost text actually is right now. I've changed mine around several times and am assuming the text at the bottom of http://www.dreamwidth.org/manage/settings/?cat=othersites is accurate. If it's not, I have an additional suggestion of updating that page to accurately reflect whatever the system default footer currently is, ideally by pulling the correct string automatically if this is not currently done.

Poll #12914 On the system default footer for crossposts, make the word OpenID a link to information about OpenID
Open to: Registered Users, detailed results viewable to: All, participants: 55

This suggestion:

Should be implemented as-is.
41 (74.5%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
14 (25.5%)

0 (0.0%)

10:52 am

Title:

Area:

Summary:
Use the same mechanisms used for post-by-email to allow comment-by-email. That is, comments by email should only be allowed from your registered address(es), and you should have to enter a PIN.

Description:
Currently DW allows post-by-email (http://www.dreamwidth.org/manage/emailpost) but doesn't allow you to reply to comments by email. This proposal adds commenting while avoiding some of the security problems that Livejournal (allegedly?) has with their reply-form-in-the-email solution.

Basically, we just add an option to the "mobile post settings" saying "Also allow comments by email". When commenting by email, you would have to put the PIN in the text of the comment. We could specify eg. that it should be the first line of the comment:

PIN: blahblah

A simple regexp should be able to strip PINs from comments and then check them against the user's actual PIN and make sure it's the right one.

The comment notification email should include a message to the effect of "Want to reply via email? Set it up here." (if you aren't registered for email replies) or, "To reply by email, simply reply to this message and include your PIN as described here" (with a link to the help or whatever).

Open to: Registered Users, detailed results viewable to: All, participants: 48

This suggestion:

Should be implemented as-is.
28 (58.3%)

Should be implemented with changes. (please comment)
1 (2.1%)

Shouldn't be implemented.
1 (2.1%)

(I have no opinion)
17 (35.4%)

1 (2.1%)

### Add "view my entries in this community" to post-entry-creation page for communities

03:11 pm

Title:
Add "view my entries in this community" to post-entry-creation page for communities

Area:
community membership, workflow: entry posting

Summary:
When you successfully make an entry in a community, add the link to view the rest of your entries to the little menu.

Description:
There's a list of suggested/possible/common actions to take after posting an entry, and I noticed on a recent change, that for successful posting in a community, the "edit my entries" link was removed -- for good and sufficient reason, because making that specific link work with communities was basically just not on from a developer perspective.

Something that currently exists and is relevant is the http://community.dreamwidth.org/?poster=username link, which locates all of the users entries to that community.

It would not be particularly development-difficult to add this link to the list of common possibilities, and it could help drive discovery of that really fascinating and useful feature.

Also, if someone needed to edit their past entries to the community, the entries would be listed right there.

Poll #12338 Add "view my entries in this community" to post-entry-creation page for communities
Open to: Registered Users, detailed results viewable to: All, participants: 49

This suggestion:

Should be implemented as-is.
40 (81.6%)

Should be implemented with changes. (please comment)
4 (8.2%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (10.2%)

0 (0.0%)

### Replace the existing spaces between the brackets in the comment form to non-breaking spaces

11:12 pm

Title:
Replace the existing spaces between the brackets in the comment form to non-breaking spaces

Area:
Comment Form Design

Summary:
Same as title.

Description:
Some layouts in Dreamwidth—especially the non-fixed width types—don't specify a width for the brackets in the comment form, so the brackets get wrapped like this.

(http://z5.ifrm.com/30174/148/0/f5154599/SS1.jpg)

I presume this is an oversight, since the brackets do align correctly when viewed in site skin.

(http://z5.ifrm.com/30174/148/0/f5154600/SS2.jpg)

Hence, I suggest to replace the existing spaces between the brackets to non-breaking spaces.

(http://z5.ifrm.com/30174/148/0/f5154601/SS3.jpg)

- A better looking comment form

- May break some users' layouts
- May break some Dreamwidth layouts

Poll #12199 Replace the existing spaces between the brackets in the comment form to non-breaking spaces
Open to: Registered Users, detailed results viewable to: All, participants: 40

This suggestion:

Should be implemented as-is.
23 (57.5%)

Should be implemented with changes. (please comment)
1 (2.5%)

Shouldn't be implemented.
2 (5.0%)

(I have no opinion)
14 (35.0%)

0 (0.0%)

Edit: Images are now fixed.

### Put plurk.com on the whitelist for embeds

01:56 pm

Title:
Put plurk.com on the whitelist for embeds

Area:
Entries

Summary:
Allow embeds from plurk.com on entries and/or profiles.

Description:
I run a roleplaying game here on Dreamwidth, but much of my playerbase uses <a href="http://plurk.com">Plurk</a> for OOC contact. As such, we have a mod account on Plurk to supplement posts in our OOC community for player information. However, not all players have or use Plurk. While we strive to put everything on the OOC community, occasionally things are posted on Plurk that they might not see. Plurk has a built-in widget for iframe embeds; if these are added to the whitelist we could post it here on Dreamwidth.

Poll #12198 Put plurk.com on the whitelist for embeds
Open to: Registered Users, detailed results viewable to: All, participants: 74

This suggestion:

Should be implemented as-is.
47 (63.5%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
1 (1.4%)

(I have no opinion)
26 (35.1%)

0 (0.0%)

### Allow "Use the time when entry is posted" to be set as default

02:37 pm

Title:
Allow "Use the time when entry is posted" to be set as default

Area:
posting entries

Summary:
Allow "Use the time when entry is posted" to be set as default when posting entries.

Description:
It is clear from reading "Get rid of restrictions on future-dated posts" [http://dw-suggestions.dreamwidth.org/1387122.html] that there are many users who are passionate about posts being timestamped when the Create Entries page was first opened, not when composition was complete. However, there are others of us who are just as passionate that entries should be timestamped at the moment of posting, *not* at the moment (days, hours, or even just minutes ago) that we started writing the post, unless we explicitly choose otherwise.

Therefore, I would like it to be possible to set "Use the time when entry is posted" as default, or if this is not possible, then at least for the Create Entries page to remember the previous setting.

Poll #12195 Allow "Use the time when entry is posted" to be set as default
Open to: Registered Users, detailed results viewable to: All, participants: 63

This suggestion:

Should be implemented as-is.
44 (69.8%)

Should be implemented with changes. (please comment)
9 (14.3%)

Shouldn't be implemented.
2 (3.2%)

(I have no opinion)
8 (12.7%)

0 (0.0%)

### Remove unnecessary whitespace from embedded objects

12:42 pm

Title:
Remove unnecessary whitespace from embedded objects

Area:
Entries

Summary:
Currently Dreamwidth adds an extra 50 pixels of blank space to embedded objects in entries to avoid problems with nesting iframes. I want to remove that extra whitespace by fixing the iframe style instead so that the nesting does not cause problems. This will give users more control over entry flow/layout.

Description:
Currently Dreamwidth adds an extra 50 pixels of blank space to embedded objects in entries. I assume this was done because if a user embeds an iframe object in an entry, the Dreamwidth code puts that iframe inside another iframe, and then if the two iframes are the same size, you get scroll bars because the body tag in the outer iframe has a margin of 8px around it (in my browser; other browsers may add other margin sizes). Thus, someone wrote some code to add an extra 50px to the width and height of the outer iframe object.

Unfortunately, this leads to an extra 42px of whitespace below the embedded object (in addition to the 8px of whitespace above and to the left and right). Visually this looks like a bunch of extra line breaks under an embedded object, and makes it frustrating when one is, for example, trying to add text after that object (as an explanation/comment, etc.), because it will show up several lines below. It makes it harder for users to control the visual layout of their own entry because there is no way to get rid of this unnecessary whitespace.

My solution is a patch I have already successfully tested out on my Dreamhack account. It will remove the extra 50 pixels of blank space. Instead, the outer iframe's body tag will be given a style with a margin/padding/border of 0. Then both iframes can have the same height/width. There won't be problems with scrollbars and there won't be lots of unneeded whitespace. As with an image or anything else that can be inserted in a Dreamwidth entry, users will be able to control how much space they want around embedded objects.

Poll #12194 Remove unnecessary whitespace from embedded objects
Open to: Registered Users, detailed results viewable to: All, participants: 48

This suggestion:

Should be implemented as-is.
30 (62.5%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
18 (37.5%)

0 (0.0%)

### Get rid of restrictions on future-dated posts

03:00 am

Title:
Get rid of restrictions on future-dated posts

Area:
posting

Summary:
DW doesn't allow you to post a future-dated post, and then follow it with a present-dated post. There are probably other restrictions along these lines. I suspect they are all there for historical reasons that don't matter any more, and I propose we get rid of them.

Description:
I came across this bug when crossposting from my Wordpress blog using JournalPress. My Wordpress blog (and my DW, for that matter) both have their timezones set as Australia/Melbourne, which as you probably know is almost as far in the future as it's possible to be without being a hobbit. So, I posted post A from my wordpress blog, and it was crossposted. Then I went to post another post, locked to my access list, directly on my DW. I was greeted with this error message:

<blockquote><strong>Error updating journal:</strong> Incorrect time value: You have an entry which was posted at 2012-10-01 02:02, but you're trying to post an entry before this. Please check the date and time of both entries. If the other entry is set in the future on purpose, edit that entry to use the "Don't show on Reading Pages" option. Otherwise, use the "Don't show on Reading Pages" option for this entry instead. </blockquote>

Initially I was going to submit some kind of bug report, but then I got to thinking... why is this limitation there at all? It has the whiff of something that was done for historical reasons, back in LJ's early days, and hasn't been revisited.

Why do we care about future-dated posts anyway?

Before sticky posts, people used to post future-dated posts (eg. dated 10 years in the future) so they would always show up at the top of their journal. This has been superseded by the sticky post feature, though I suspect some people may still use the old technique.

<user name="azurelunatic">, on IRC, suggested that it might also have something to do with people's computers having really wacky times set on them. I can see this being a problem a decade ago, but I think almost everyone's computer these days using <a href="http://en.wikipedia.org/wiki/Network_Time_Protocol">NTP</a> to automatically set the time, yes? So this would be a much rarer thing than it used to be.

I don't actually have a good feeling for what the solution is here, but I wanted to raise this suggestion to ask:

1) what benefit is there to limiting posting in this way?
2) do those benefits still apply, or are they historical only?
3) can we just get rid of it?
4) if not, can we modify it so that only egregious badness is prevented, but posting from a third-party client in another timezone is permitted?

For the purposes of voting, please consider the suggestion to be "get rid of future-date limitations on posts to the greatest degree possible."

Poll #11813 Get rid of restrictions on future-dated posts
Open to: Registered Users, detailed results viewable to: All, participants: 56

This suggestion:

Should be implemented as-is.
24 (42.9%)

Should be implemented with changes. (please comment)
7 (12.5%)

Shouldn't be implemented.
10 (17.9%)

(I have no opinion)
13 (23.2%)

2 (3.6%)

### Make pressing "enter" on Links List save changes

06:22 am

Title:
Make pressing "enter" on Links List save changes

Area:
Customize Journal Style

Summary:
If you're managing your links list (http://www.dreamwidth.org/customize/options?group=linkslist) and have your cursor inside one of the text boxes and press enter, it activates the More Links button rather than the Save Changes button. I propose that this be changed.

Description:
When I push the enter key while my cursor is in a textbox, I expect it to activate the Save Changes button. I obviously can't speak for everyone, but that's pretty universal behavior for most forms.

If most people prefer the current behavior and would rather it be kept, can the page at least be forced to, when you hit the More Links button, remember unsaved information in the textboxes so users won't have to re-type what they already had there?

Poll #11755 Make pressing "enter" on Links List save changes
Open to: Registered Users, detailed results viewable to: All, participants: 49

This suggestion:

Should be implemented as-is.
25 (51.0%)

Should be implemented with changes. (please comment)
4 (8.2%)

Shouldn't be implemented.
1 (2.0%)

(I have no opinion)
18 (36.7%)

1 (2.0%)

### Screen comment edits when comments are screened

08:15 pm

Title:
Screen comment edits when comments are screened

Area:

Summary:
Right now, if I set comments to screened-if-not-in-my-circles and I unscreen a comment, then the author edits a comment, the edit appears immediately without being screened.

Description:
I have screening enabled by default in my journal for comments from people not on my access list. Suppose "Alice", who's not on my access list, leaves a comment, and I unscreen it. If "Alice" edits the comment afterward, her edit appears immediately -- I don't have to unscreen the new edited version.

This is weird. When I saw this happening, fortunately the edit was just a typo fix. But in general, a commenter could abuse the editing feature to sneak in an edited version of the comment that the journal author wouldn't have unscreened.

I think when someone edits a comment in a context where screening is active, their edit should be like a new screened comment: that is, the old version should appear until the journal owner unscreens the edit (at which point the old version goes away).

Poll #11717 Screen comment edits when comments are screened
Open to: Registered Users, detailed results viewable to: All, participants: 53

This suggestion:

Should be implemented as-is.
27 (50.9%)

Should be implemented with changes. (please comment)
9 (17.0%)

Shouldn't be implemented.
2 (3.8%)

(I have no opinion)
15 (28.3%)

0 (0.0%)

## Profile

Dreamwidth Suggestions

S M T W T F S
1
23456 7 8
9 101112131415
16171819202122
23242526272829
30

No cut tags