Some thoughts
There's no need for asterisks or colons to distinguish replies from each other. Each post is already self-contained.
- Nod.
- Though
- I
- Can
- Still
- Use
- Them : )
- Use
- Still
- Can
- I
Which, I'll agree is nice, for possible formatting needs within a message.
But (to use an example) - someone posts to a talk page a copy from the associated main page something they want help with (for example, a piece of an article at Wikipedia), for various reasons.
No one would be able to edit that.
Or perhaps it's help with some template coding.
No one would be able to help with that either.
Talk pages are used for more than just "talk".
Ad of course, this doesn't deal with things like turning a section and its sub threads into its own subthread.
Or for that matter, if for no other reason, due to people's current indoctrination due to existing online message boards, the talk pages won't be threaded at all, but just be a hodge podge of posts.
When that happens (and it does even now on some article's talk pages), someone typically (hopefully) comes along and tries to make sense of the posts, threads.
Since Wikipedia (at least) is based on the consensus model, having posts threaded all over the place is gonna be hell on whoever has to "close" a discussion to say that consensus is determined.
And that's another thing.
How will discussions be closed?
And can multiple threads be closed simultaneously as part of that closure?
I'm sincerely not trying to be difficult here (I do like the concept), but I'd like to see the implementation be workable so that it's not a hindrance to communication in any way.
Maybe a test could be to see how liquid threads would look if you look at archives at wikipedia of talk:ambox, talk:Darth Vader, Wikipedia talk:RFA, the several village pumps and administrators' noticeboards. Maybe the various RfCs on T1.
I mean, looking at VP (technical) I don't see how that would work with this.
Unless the intent is to "push" discussions off of talk pages and onto main pages, like the noticeboards...
Which is my other concern.
If this becomes even a little too complicated for the new user, it could promote edit warring. since it would be easier to say something brief in an edit summary than go to the talk page.
Oh and one more thing. let's say that I look at this lengthy post, and decide to split it into several sub threads for individual commenting (I'm not, this is just a "what if") - How would I do that with this system? Would it require ten windows simultaneously open to copy paste the sections, and creating several threads at once? Or at least successively?
Now I realise that I'm mostly looking at this from a wikipedia/media perspective.
But I'm hoping these things can be resolved.
"Oh and one more thing. let's say that I look at this lengthy post, and decide to split it into several sub threads for individual commenting (I'm not, this is just a "what if") - How would I do that with this system? "
Good question. After some time using the extension on Portuguese Wikibooks, I still don't know a good way to do this. Does anyone have suggestions for this?
Great points - I summarized some of them in a feature request here: Talk:LiquidThreads_3.0
The issues you raise - not /requiring/ js, and supporting refactoring - are the main things keeping me from supporting LQT for large wikis.
