006, eager, scorel by atrata, happy

My draft for suggestions

Edit 2006-06-28: Posted to suggestions. Let the ridicule begin. (Well, if it makes it past the maintainers.)

I made a post in lj_style the other day to find out whether other people think the current behaviour of entries with disabled comment posting is logically flawed. It was suggested that I take it to suggestions, and since that's rather a public forum, I thought I'd draft it here first so that people can do a little criticizing and I can do a little tweaking, hopefully lessening my chances of being slaughtered when I post over there. So comments much appreciated!


Do not hide pre-existing comments when disabling comment posting

Short, concise description of the idea

Right now, if you disable comment posting on an entry, none of the comments are shown when you view that entry in the bml entry page (aka simple comment page) and in many S2 layout entry pages. The entry looks like it never received any comments, even if prior to the disabling it had received many.

I propose that entries that have had comment posting disabled should still display all the comments that were made prior to the disabling.

Full description of the idea

Entries that have had comment posting disabled should still display all the comments that were made prior to the disabling. Current behaviour is to hide all comments once comment posting is disabled.

This is odd behaviour that has some problems. First, it isn't really logical. The comments still exist, and when you decide to disable comment posting, you don't necessarily want to prevent people from reading existing comments, you may simply not want to receive any more responses. The assumption cannot really be made that everyone who disables comment posting also wants to hide all existing comments. Those are two separate actions. In fact, the second of those actions is generally done through comment screening.

Second, it is misleading. Right now, it is easy for people to assume that disabling comments is like screening comments, since the comments are not visible in most views; however, there are several S2 layouts (Bloggish, Dear Diary, Quite Lickable, Smooth Sailing, s1short) that display comments even on entries that have disabled comment posting. So if you switch your style to one of those, you can view the entry with style=mine and reveal all comments. Additionally, with a little bit of S2 knowledge and a paid account, you can edit any existing layout to make it mimic that same behaviour. This comment hiding is not really screening at all, and as such it is dangerously misleading. Post authors may assume that they've hidden comments from everyone, but there will still be people out there who can read them all.

When you come right down to it, disabling comments on a post is very like freezing a comment thread -- you are preventing the addition of any more replies. It should not have any kind of screening component, since that is a separate action entirely. If you want to hide comments, you should be screening them -- that's what screening is for.

An ordered list of benefits

1. Disabling comment posting will have the more logical result of doing only that one thing, with no additional side effects.

2. There will be more consistent behaviour between bml entry pages and custom S2 entry pages, as well as more consistent behaviour among the various S2 styles.

3. People will no longer be misled into thinking that disabling comments is a secure way of hiding comments from view.

An ordered list of problems/issues involved

1. I have been told that the original reason for this behaviour might be related to S1. In S1 you must show the post and read comments links together or not at all -- you cannot remove the post link without also removing the read link. Since disabling comments required removing the post link, then the read link had to go, too, and accordingly the comments were hidden on the entry page. To me, this seems like we are now catering to a flaw in S1 that really ought to be fixed, but I know very little about the workings of S1, so I'm not sure how feasible it would be to solve that. It may be that the only way to resolve this in S1 is to always show the read and post link whenever there are comments on a post, regardless of whether comment posting has been disabled, and then when someone clicks the post link, they are given an error message that comments have been disabled.

2. The usual issue exists, of course, of having someone go in and make all the necessary code changes.

3. It's possible that some people may be upset by:

a) Whatever is done to solve the S1 problem.
b) The new behaviour, since they are used to having comments be invisible (to *most*) when comment posting is disabled.

An organized list, or a few short paragraphs detailing suggestions for implementation

1. On the entry bml page, show any existing comments even when comment posting has been disabled. Likely will require quite a few modifications to the comment display and reply link logic.

2. In the S2 code, change the logic for setting the show_readlink variable so that it is set to true when public comments exist or when the viewer can see any screened comments -- remove the condition that comments must be enabled.

3. In the S2 system layouts, ensure that all the layouts use the show_readlink and show_postlink variables to determine when to show the read and post comment links, and also ensure that in the code for the custom entry pages the comments get displayed even when commenting has been disabled.

4. Deal with the S1 read and post links in some way.
006, eager, scorel by atrata, happy

The Boxer: Smilies in Posts and Comments

The code in this tutorial will cause simple punctuation smilies like :) and :( to be replaced with images of your choosing when they are displayed in posts and comments. It is adapted (without permission) from absolut's component_help tutorial Adding Smilies to your post/comments. As in that original tutorial, the code here uses some search and replace code by mageboltrat that can be found here. This tutorial only works if you are viewing your journal in your own style. Your friends won't be able to see the images if they read your entry on their friend's list.

Collapse )
006, eager, scorel by atrata, happy

Flexible Squares: Sorted Multi-Level Tags in Sidebar

This code is currently a disaster, but it does seem to sort of work (always a challenge for me when I'm tossing around nested arrays). It's still full of clumsy debugging stuff, even, but I wanted to post it before I accidentally delete the layer. Basically allows you to specify a sort order for any levels of a multi-level tag list. Any levels that aren't specified in the custom sort order fall into alphabetical order after the custom sorted levels. Lord knows who would ever want to do this, but maybe one day someone will ask, and then at least I'll have some code to work with.

Collapse )
adora by atrata, industrious, awake, 001, elegant

Flexible Squares: Sorted Bi-Level Tags in Sidebar

This is a first effort towards answering todeskun's s2flexisquares post. Not sure if it's the best way, and there may be some unecessary inefficiency in there. Could interested parties please give it a once-over? If you had better ideas for solving this problem, I'd like to know about them, and implement those instead. I have been known to overlook the obvious. :)

ETA: I think this code doesn't allow enough sorting -- it only sorted top-level tags. Please see Attempt #2.

Collapse )
listening, helmut by atrata, 003, chatty, alert

Semi-Threaded Comments

So a recent post in Flexible Squares got me to thinking once again about the problem of long comment threads either expanding too far to the right in Firefox, requiring lots of horizontal scrolling, or becoming terminally squished in IE since it doesn't understand min-width. I was wondering if the primary format of long threads is a single long chain, where each comment has only one reply. If that's the case, why does each comment in that chain need indentation? If it isn't branching off into new threads, shouldn't it be just as easy to understand if no indentation were used at all? Thus I created a semi-threaded comment display, which indents a comment only when it is not the only reply to its parent*.

Hmm, reading this over, I find my own description entirely useless. Best link to an example. This comment has some fairly long chains, leading to a bit of comment squish. Viewed with semi-threading, though, it exhibits far less squish. But is the comment progression still understandable?

* Actually, that is the slightly simplified logic. It also always indents depth 2 comments to allow all the top level comments to be easily identified.