So as the post-upgrade dust settles, one of the big things still left on our usability TODO list is implementing inline reply and moderation for the site. A quick survey of our developers is that no one here really is super experienced in writing JavaScript code, so I'm putting a call for help to find someone to help implement and write this. For anyone getting interested in SN development, this appears to be a straightforward task. Here's the official requirements for the feature.
- A user should be able to post and moderate comments without a seperate page load
- If JavaScript is disabled for whatever reason, the site must degrade to the current click-to-post functionality. We don't want to force people to enable JS if they don't wish to. Dynamically rewriting the DOM to change links may be necessary, but this can be discussed
- The rehash API must be extended to add this functionality; this should be relatively easy and straight forward; we have parts of the original AJAX code so this functionality may already be in place.
-
Contact me, or paulej72 on IRC, or post a comment below if you're interested in helping.
This discussion has been archived.
No new comments can be posted.
Help Wanted: Implementing Inline Reply and Moderation
|
Log In/Create an Account
| Top
| 79 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(Score: 4, Insightful) by aristarchus on Thursday June 04 2015, @10:08AM
no one here really is super experienced in writing JavaScript code,
There may be, possibly, a reason for this?
If JavaScript is disabled for whatever reason, the site must degrade to the current click-to-post functionality.
And for many, this is not a degrade, it is the grade! So sorry, not able to help. Again, what is the argument for this functionality?
(Score: 3, Insightful) by Ryuugami on Thursday June 04 2015, @10:25AM
Again, what is the argument for this functionality?
Some people consider the current system a pain in the ass, and may be willing to enable Javascript just to get that increase in usability. Personally, I'm on a fence. I post rarely enough that I don't think I'll enable it, but I'd like to have the option to. Options are nice.
BTW, I'd say this is exactly what JS should be used for: increased usability. If only the same thing could be achieved without it... or if we could enable only a limited subset of JS without all the security-nightmare parts. Something like a limited implementation that just silently fails when JS tries to access HDD or whatever.
If a shit storm's on the horizon, it's good to know far enough ahead you can at least bring along an umbrella. - D.Weber
(Score: 5, Insightful) by Gravis on Thursday June 04 2015, @10:32AM
Some people consider the current system a pain in the ass,
because it is! changing page for every little action is annoying because you lose your place and it kills any focus you might have had.
(Score: -1, Troll) by Anonymous Coward on Thursday June 04 2015, @10:38AM
Have you considered the more likely possibility that you have attention deficit disorder? Sorry I will try to abbreviate so you do not lose your focus before the end of a sentence.
U got ADHD bro. LOL
(Score: 2) by Tork on Thursday June 04 2015, @05:32PM
🏳️🌈 Proud Ally 🏳️🌈
(Score: 0) by Anonymous Coward on Thursday June 04 2015, @07:17PM
So basically, you've never used a command line, a text mode editor like Emacs or vi, or any other user interface that requires you to remember commands to use it effectively. Get off my lawn, child, and take your graphical toys with you.
(Score: 2) by Tork on Thursday June 04 2015, @08:48PM
🏳️🌈 Proud Ally 🏳️🌈
(Score: 2) by monster on Friday June 05 2015, @12:56PM
Some actions are much easier to do with a UI than with command line. Things like "Take this file, this one, and that, but not this other one" can be made in a breeze with a proper UI while requiring a lot of extra steps using just a command line.
Command line is great and clearly superior for some things, on par for others, and definitely not the proper tool for some. If you can't see that then you aren't a neckbeard, just an old geezer.
(Score: 2) by Gravis on Friday June 05 2015, @12:07AM
That's the first time I've heard the "ADD Defense" in response to bad UI design.
ahh, so you have been spared from listening to Gnome 3 developers.
(Score: 0) by Anonymous Coward on Thursday June 04 2015, @12:42PM
Any modern browser (say, = 5 years old) will let you ctrl-click on links. You should try it some time.
(Score: 4, Insightful) by kbahey on Thursday June 04 2015, @02:38PM
As someone who browsers with javascript disabled, this has not been an issue for me. Just right click and open in a new tab, and do your thing there, and close the tab. You are back to the page you were at. I have been doing this for a long time with SN and other sites that it is second nature to me.
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning [2bits.com].
(Score: 2) by Ryuugami on Friday June 05 2015, @08:49AM
Unfortunately, this doesn't work with the "moderate" button, which I use much more often than "reply".
My work-around (if you can call it that) is to glance to the scroll bar when clicking moderate, so I can quickly scroll back to the general vicinity of where I was...
(BTW, at least in Firefox, middle-click or ctrl+left click both open links in new tab. I don't know if it works in other browsers.)
If a shit storm's on the horizon, it's good to know far enough ahead you can at least bring along an umbrella. - D.Weber
(Score: 2) by NCommander on Friday June 05 2015, @02:56AM
We already use quite a bit of javascript for improved threading. The entire expand/remove comment interface vanishes (or more specificly, doesn't get drawn) if JS is disabled.
Still always moving
(Score: 2) by NCommander on Friday June 05 2015, @03:31AM
My understanding of the DOM makes it incredibly difficult to do just that; you simply have too rich an API with everything interlocking with each other. What someone SHOULD do is redesign the basic JS library to be less braindead, and get it standardized and implemented. Pretty sure it will be a cold day before that happens.
Still always moving
(Score: 3, Insightful) by wonkey_monkey on Thursday June 04 2015, @11:45AM
There may be, possibly, a reason for this?
Yes. The reason is that no one at Soylent really is super experienced in writing JavaScript code.
What are you trying to imply? That Javascript is an obscure, forgotten language?
And for many, this is not a degrade, it is the grade!
You're welcome not to avail yourself of the additional functionality, but I doubt you speak for the majority or anything close to it.
If you don't want to use Javascript, these changes should have no effect on you.
Again, what is the argument for this functionality?
Because it's faster and much less frustrating for the user.
I don't know where this luddite attitude (in general) against Javascript comes from. You can argue for all kinds of reasons why it's a bad thing philosophically or from a security standpoint to allow code to run in your browser and muck about with the DOM, but if you seriously can't see how much more useful and usable Javascript can make a website, then it sounds like you're just being willfully obtuse.
What if you want to refer to other comments (either in or outside of the ancestry of the comment you're replying to), for example?
What about moderation? I would certainly be more inclined to do it if it didn't involve losing my place on the page.
Not to mention the bandwidth savings. This page, for example, with a just few comments on it, is 40k. The page I'm currently on, typing this reply, is about 18k. Then I like to preview my comment, which is probably about the same. Then I hit submit - a few more k to tell me I've posted my comment. Then I go back to the page to read more comments - another 40k.
That could be reduced by a huge amount through judicious use of Javascript and AJAX requests.
systemd is Roko's Basilisk
(Score: 0, Disagree) by Anonymous Coward on Thursday June 04 2015, @12:50PM
Not to mention the bandwidth savings. This page, for example, with a just few comments on it, is 40k. The page I'm currently on, typing this reply, is about 18k. Then I like to preview my comment, which is probably about the same. Then I hit submit - a few more k to tell me I've posted my comment. Then I go back to the page to read more comments - another 40k.
By the same token, we could also strip all the markup, I mean, no-body ever sees those crazy things in the ''. I'm sure we can strip them and just serve plain TXT.
And then there's the stylesheets, goodness, so much bandwith, let's get rid of them.
We can save even more bandwidth by not doing images as well, those are +18kB each as well.
All in all, I think we should go back to gopher:// [gopher]
ok, had enough? Do you realize why you sound dumb yet?
(Score: 2) by wonkey_monkey on Thursday June 04 2015, @01:28PM
Except my suggestion reduces bandwidth and improves - or at the very least does not impact - the usability or presentation of the website. Which is what you makes your extrapolation dumb.
systemd is Roko's Basilisk
(Score: 2) by monster on Friday June 05 2015, @01:00PM
If the JS version doesn't show a preview, that sounds like reduced functionality to me.
(Score: 2) by wonkey_monkey on Friday June 05 2015, @03:48PM
I never said it shouldn't.
systemd is Roko's Basilisk
(Score: 2) by monster on Friday June 05 2015, @04:25PM
Fair enough. I was just talking from experience from other sites with that behaviour.
(Score: 2) by NCommander on Friday June 05 2015, @03:33AM
You joke about gopher but we have some code to implement a gopher version of this website (https://github.com/SoylentNews/rehash/tree/master/plugins/Gopher). One of these days, I might actually finish that April Fools Joke ...
Still always moving
(Score: 2) by martyb on Thursday June 04 2015, @12:53PM
It's not ideal, but I've been using this workaround on that other site and here for years. If your browser supports multiple tabs, Open the comment you wish to moderate in another tab[*], apply moderation, and then close that tab.
[*] For example, the comment to which I am replying currently displays in its header:
Right-click on #192007 [soylentnews.org] and select open in new tab. Perform your moderation in *that* tab and then close it when done. Your place in *this* tab is unaffected.
It may not be ideal, but I've certainly found it effective and hope that others will, too.
Wit is intellect, dancing.
(Score: 4, Informative) by sudo rm -rf on Thursday June 04 2015, @01:41PM
Right-click on #192007 and select open in new tab.
Even simpler: middle click. Maybe there are browsers that don't support this, but the usual suspects do.
I only mention it, because many people don't know the power of the middle mouse button;)
(Score: 2) by maxwell demon on Thursday June 04 2015, @02:57PM
I've already had mice where the wheel was so sensitive that it was hard to middle-click without at the same time scrolling, which of course is not good if you try to middle-click a link. So the power of the middle mouse button very much depends on the quality of your mouse.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by schad on Thursday June 04 2015, @04:44PM
It can be a little fidgety, but with practice you'll get it right about 90% of the time. And it's not like anyone dies if you scroll by accident (I hope).
The real objection -- and I'm surprised nobody has brought it up yet -- is that middle click in X means "paste selection." In a browser it means paste-and-go.
You can also use ctrl+left click.
(Score: 2) by maxwell demon on Thursday June 04 2015, @04:50PM
Spoken like someone who never had a really bad mouse. I can assure you, with the wrong mouse you'll be lucky to get 50%.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by schad on Thursday June 04 2015, @05:09PM
Quite possible. I'm a PC gamer so I do research mice before I buy them.
(Score: 2) by monster on Friday June 05 2015, @01:20PM
At least on Firefox, ctrl+click is the same as middle-click.
(Score: 2) by danomac on Thursday June 04 2015, @05:03PM
Or, even easier, just choose the moderation from the drop down in the comment and keep reading/moderating the thread/comments. When you get to the bottom of the comments, you'll see a Moderate button outside the comments section that will commit all moderations at once.
(Score: 2) by aristarchus on Thursday June 04 2015, @05:09PM
I don't know where this luddite attitude (in general) against Javascript comes from.
Umm, experience? That and, um, bad experience. Nothing luddite about it.
But thanks for the explanation of the possible benefits. I primarily use javascript as a canary. I deploy Noscript, and if a page will not function without allowing javascript, I do not go there, if I have a choice.
(Score: 0) by Anonymous Coward on Thursday June 04 2015, @10:10AM
Throw more cloud at the problem! You just need bigger fluffier clouds!
(Score: -1, Troll) by Anonymous Coward on Thursday June 04 2015, @10:17AM
I run a web-site and there are too many page-loads and links and people clicking on things! I just don't understand how a WEB of PAGES that are LINKED together could cause me so much server load! My god, man, how is this happening?????
(Score: 2) by TLA on Thursday June 04 2015, @10:48AM
if I had the patience I'd learn, but at the same time I'm too afraid of breaking something.
(I know, right? I just up and said there's something I don't know!)
Excuse me, I think I need to reboot my horse. - NCommander
(Score: 5, Informative) by sudo rm -rf on Thursday June 04 2015, @10:54AM
I'd like to see a feature which could improve usability a lot and requires no JS at all:
Every comment already has an achor (a-tag) with the attribute name="[comment id]".
So when replying to a comment or moderating, the redirection url can include the anchor (#).
Example:
If i replied to the first comment on this page (name="191977"), the redirection url after submitting should be someting like https://soylentnews.org/meta/article.pl?sid=15/06/03/2213230#191977 [soylentnews.org], so that the browser takes me to the place I have been last. Same goes for moderation. It would be especially useful in long discussions.
(Score: 3, Informative) by maxwell demon on Thursday June 04 2015, @12:35PM
The same could be used for the parent link whenever the parent comment is already displayed in the thread: There's no need to load the parent in a new page then; just repositioning the page using a link to the anchor is sufficient (that is, have as link target just e.g. "#191997"). If one really wants the comment in a separate window, that functionality is still just one further click away (namely by clicking on the comment number).
This would also help reduce the server load since a simple repositioning creates exactly zero load to the server; the browser does it all locally.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by urza9814 on Thursday June 04 2015, @03:44PM
If you want to go back to where you were, try the browser's back button ;)
(Score: 2) by NCommander on Friday June 05 2015, @03:29AM
We've looked at this before, its made more difficult by the simple fact that we don't know if a comment would be visible given a users preferences. I can think of a couple of ways to make it work though ...
Still always moving
(Score: 3, Informative) by quadrox on Thursday June 04 2015, @11:12AM
I was wondering when inline replies and moderation were coming, I'm looking forward to this feature.
I have some experience doing similar stuff with JavaScipt - I am not an expert, but I think I'm easily up for the task. The biggest problem is that I am already busy with all kinds of other projects, so I am not sure how soon I could have something working.
If there are no other volunterers however, I would be happy to help!
(Score: 2) by mrcoolbp on Thursday June 04 2015, @03:09PM
Cool quadrox, I'll let the boys know, thanks!
(Score:1^½, Radical)
(Score: 1) by jamestrexx on Thursday June 04 2015, @11:30AM
Is this also the reason why I can't change comment thresholds with Links2?
When I try to change this I only get to see the page header. Although I just found out if I change the threshold, then click on [reply] instead of [change] the amount of comment do get changed. o.O; I don't get a reply form though. That only when replying to a comment.
(Score: 2) by NCommander on Friday June 05 2015, @03:28AM
That sounds like a bug ... I'll try to reproduce it.
Still always moving
(Score: 1) by jamestrexx on Saturday June 06 2015, @08:29PM
My first thought, but since it involves a text browser I wasn't sure.
Thanks :-)
(Score: 1, Insightful) by Anonymous Coward on Thursday June 04 2015, @12:00PM
I realize many people are willing to trade some liberty and security for convenience. Many people don't realize that some people aren't.
(Of course since SN is free software the liberty part does not apply here.)
(Score: 3, Insightful) by kaganar on Thursday June 04 2015, @02:31PM
The answer to "this can be a dangerous tool" shouldn't necessarily be "let's not use it ever," but there's a certain contingency of people on the web who treat Javascript with that mentality. You don't have to loan your chainsaw to everyone who visits your house or even put gas in it when you do.
(Score: 2) by Immerman on Thursday June 04 2015, @03:12PM
The problem with Javascript, is that there's (currently) no convenient way to enable it just for the "good uses". If I enable Javascript for the limited-risk functionality on /., Soylent, etc. the floodgates are pretty much opened for any malicious exploits on any other site I visit.
It would be nice if you could set your browser to "disable Javascript for all non-whitelisted sites" (presumably with an "enable Javascript for this site" button somewhere convenient), and/or a "Disable unsafe/invasive Javascript" option that would disallow all functions that potentially expose personal information or allow tampering with the PC. If the major browsers all agreed on a "safe function set" we could hope that honest javascript writers would tend to avoid the unsafe functions so that their scripts would run on secured browsers.
(Score: 5, Insightful) by maxwell demon on Thursday June 04 2015, @03:50PM
That's what NoScript does.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by maxwell demon on Thursday June 04 2015, @03:23PM
The main problem with JavaScript is that you can do bad things using a 100% bug free implementation. That's basically because it's a Turing complete language with internet access.
I think it would be nice if besides the options of "allow JavaScript" and "deny JavaScript" there would be a third option, "allow a reasonably safe subset of JavaScript".
Only buggy image decoders.
I wouldn't run an OS that I downloaded from a random web site on the net.
Would you rely on the security of a smartphone that a stranger gives you?
I think most phones are reasonably secure against wiretapping by random people. The three letter agencies, that's of course another matter. If I wanted to hide something from those agencies, I surely wouldn't talk on the phone about it.
Sure. And how is that related to the topic? You don't accidentally transfer your money to a bank by just walking by, do you?
As the rest gets even more unrelated, I stop here.
With JavaScript, the analogy is not that you are using a chainsaw, the analogy is that someone enters your house with a chainsaw. While there are some cases where it makes sense to enter a house with a chainsaw, it is certainly a bad idea to let any random stranger enter your house with a chainsaw.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by francois.barbier on Thursday June 04 2015, @12:02PM
I might be able to help, having been programming JS for more than a decade now...
If you are interested, I can send (in private) a URL or two about stuff I worked on, for confirmation.
(Score: 2) by mrcoolbp on Thursday June 04 2015, @05:01PM
Nice. I'd encourage you to hop into IRC [soylentnews.org] and mention NCommander, much easier to coordinate these things in a real-time chat.
(Score:1^½, Radical)
(Score: 0) by Anonymous Coward on Thursday June 04 2015, @12:45PM
If JavaScript is disabled for whatever reason, the site must degrade to the current click-to-post functionality. We don't want to farce people to enable JS if they don't wish to.
As long as you allow the 'degradation', I don't care... I'm not enabling JS and if you make that the only way to comment, I will stop commenting (and stop visiting).
That being said, I'm sure someone will take issue with this comment and reply something along the lines of "good, you won't be missed".
(Score: 5, Funny) by francois.barbier on Thursday June 04 2015, @01:01PM
Good, you won't be missed
(Score: 0) by Anonymous Coward on Thursday June 04 2015, @06:17PM
Most of the visitors of this site probably browse without javascript enabled. There are a lot of reasons [stackexchange.com]. My own reason is mostly to do with security, which is why I'm only willing to enable it in Internet Explorer at work (because that was the browser given to me by IT, as configured by IT, so they are responsible for its security).
A secondary reason for me to disable javascript is to prevent animation, since I have adult ADHD, which makes animated pages very difficult to read. Disabling javascript disables most animated advertisements, and gif animation can be disabled manually. Unfortunately, CSS animation is getting more prevalent, so I'm still looking for a solution to that.
Would you really not miss any of the commenters here who browse without javascript? Before you answer, you should look at some of the other top level comments in this discussion. There are a lot of people here who don't use javascript.
(Score: 0) by Anonymous Coward on Thursday June 04 2015, @08:46PM
NoScript is your friend. Using it to selectively enable Javascript blocks 99% of ads, and those that still display aren't annoying. Not that SoylentNews has ads anyway, but even on the green site I've enabled Javascript for their domains, but don't see any ads because I don't have any Javascript enabled for the advertisers domains.
It can be a pain getting some sites working with NoScript, but if you block all Javascript anyway, you likely wouldn't be bothered by that as those sites wouldn't work anyway.
And personally, I wouldn't expect most IT departments to configure things correctly for security, most just focus on getting things to work and unless they are mandated to use some security feature, they will throw security out the window if they think it will help get something working. But maybe your IT can competently manage security.
And personally, I wouldn't expect most IT departments to configure things correctly for security, most just focus on getting things to work and unless they are mandated to use some security feature, they will throw security out the window if they think it will help get something working. But maybe your IT can competently manage security.
(Score: 3, Informative) by mrcoolbp on Thursday June 04 2015, @03:15PM
From TFS:
If JavaScript is disabled for whatever reason, the site must degrade to the current click-to-post functionality. We don't want to force people to enable JS if they don't wish to.
(Score:1^½, Radical)
(Score: 1, Insightful) by Anonymous Coward on Thursday June 04 2015, @01:24PM
Uh, no, stop breaking your potential to satisfy javascript disabled users. If you want to know what you can do standard?
NOTHING
Javascript is really the monkey grease these days. Honestly I'd like to see one site that doesn't function like shit to appease the lowest common denominator.
(Score: 3, Informative) by mtrycz on Thursday June 04 2015, @01:42PM
It's right there in TFS: current functionality will be left unmodified for people who don't want JS, but those who do want it will be able to use it.
I'd like it, and feel that this whole thread is filled with people that are too eager to open their mouth and a little too little eager to read.
In capitalist America, ads view YOU!
(Score: 0) by Anonymous Coward on Thursday June 04 2015, @01:50PM
I read the article, but it becomes too complex without javascript.
I posted a comment below yours that has the code needed to go ahead and do what's necessary.
Trust me, I'm a web developer!
https://darrencaldwellwebdesign.ca [darrencaldwellwebdesign.ca] :D
(Score: 2) by mrcoolbp on Thursday June 04 2015, @03:19PM
You are mis-understanding. The current functionality will remain completely un-changed for those with javascript disabled. I.e. we will use JS for the inline commenting, and for those with it disabled functionality will revert back to exactly what we have now.
(Score:1^½, Radical)
(Score: 2) by janrinok on Thursday June 04 2015, @03:32PM
(Score: 2) by bryan on Thursday June 04 2015, @04:26PM
You get a certificate warning on SN's own dev site: https://dev.soylentnews.org/ [soylentnews.org]
(Score: 2) by mrcoolbp on Thursday June 04 2015, @04:52PM
True, but we trust ourselves = )
(Score:1^½, Radical)
(Score: 2) by janrinok on Thursday June 04 2015, @06:04PM
(Score: 3, Interesting) by TheRaven on Friday June 05 2015, @06:45AM
sudo mod me up
(Score: 2) by aristarchus on Thursday June 04 2015, @05:48PM
Trust me, I'm a web developer!
Mandatory "Princess Bride" response: "No good, I've known too many Web Developers!"
(Score: 0) by Anonymous Coward on Thursday June 04 2015, @01:47PM
I'll pretend you didn't say anything about disabled javascript, because there's limits to what I can do.
Fix
//INITIAL FLIP FROM REG MODE TO NORMAL MODE
$(document).on('click','body>.content>.webpage>.content .editableArea',function(e){
var target=$(this);
var replacement='
';
target.replaceWith(replacement);
var evt = e ? e:window.event;
if (evt.stopPropagation) evt.stopPropagation();
if (evt.cancelBubble!=null) evt.cancelBubble = true;
});
//NOW TO FLIP BACK, THE PROBLEM
//IS SOME PEOPLE DON'T UNDERSTAND THAT THE VALUE IS HELD NOT IN HTML, BUT IN A MEMORY ONLY VARIABLE
//IN FACT THERE SHOULD BE A BLOB OF THESE VARIABLES FLOATING THAT EACH PAGE DRAWS ON TO RENDER
$(document).on('click','.button.saveComment',function(e){
target=$(this).parent();
val=$(this).parent().find('textarea').val();
memoryVariable.thisCommentThread.ThisComment=val;
//now you can either reload the page, or re-render this area and it appears with new value
renderPage();
});
(Score: 0) by Anonymous Coward on Thursday June 04 2015, @01:59PM
Oh yes, and I almost forgot, reloading your website sucks balls, so here's how to reload the data async everytime one of us comments
$(document).on('click','.button.submitComment',function(){
var val=$(this).parent().find('textarea').val();
var soylentIO=io.connect('/soylent');
soylentIO.emit('new comment');
});
// here is the server side which receives the comment
var soyIO=io.of('/soylent');
soyIO.on('connection',function(socket){
soyIO.on('new comment',function(comment){
//now here is the magic, one person posts, and it broadcasts to all of us connected
soyIO.broadcast('a new comment has been added',comment);
});
});
//back to the client side
soyIO.on('a new comment has been added',function(comment){
memoryVals.thisThread.push(comment);
renderPage();
});
(Score: 2) by urza9814 on Thursday June 04 2015, @03:57PM
I'm pretty sure this can be done using only CSS3 with a single clever :after selector.
I mean it's not really proper use of CSS, and it might be a little ugly, but since all I'm seeing in the comments are arguments over whether or not Javascript is an acceptable language, maybe I'll take a shot at hacking something like that together this weekend...
(Score: 2) by mrcoolbp on Thursday June 04 2015, @04:57PM
If you can make it work without JS, more power to you. That would be ideal (I think, I'm not on the dev team). Doing it with CSS has been mentioned before but no one has stepped up to the plate yet.
(Score:1^½, Radical)
(Score: 2) by wonkey_monkey on Thursday June 04 2015, @05:15PM
I'm pretty sure this can be done using only CSS3 with a single clever :after selector.
Which "this" is it that you're referring to? Posting comments?
How would you do that with CSS3 and no Javascript?
systemd is Roko's Basilisk
(Score: 3, Interesting) by urza9814 on Thursday June 04 2015, @05:56PM
Replace the reply button with a checkbox element that just looks like a button. Then you add an ::after selector to the checked checkbox (ie, reply button is pressed) and you should be able to throw the entire comment form in a content block on that selector. So when you click the button, the reply form appears right below it. Use attr() to get the comment ID and put that into the form element so it knows where to submit it.
It *would* still need to take you to a new page when it actually posts, but then you've just gotta update the redirect to drop you back where you came from.
I'm not 100% sure this would work, but it seems feasible at first glance anyway...
(Score: 3, Informative) by VortexCortex on Thursday June 04 2015, @08:33PM
I'm pretty sure this can be done using only CSS3 with a single clever :after selector.
Displaying a form, yes, but submitting the form will then take you to a new page, and you'll reload the entire page again to read the topic more and perhaps post again (and reload). JS allows for XMLHTTPRequest (note: XML here being a misnomer), which can POST data to the server and the response can contain (X)HTML to insert (your posted comment) allowing one to keep scrolling and perhaps reply to another post all without reloading the entire page again. This has been dubbed AJAX. It's is why JS is preferable to a purely CSS option. CSS only approach would be no different than the current features except a bunch of mostly unused hidden forms would litter the HTML source (since gzip, defalte is an Accept-Encoding according to SN's headers they wouldn't contribute much to bandwidth, just page complexity). You'd eliminate one minor "reply" page load, but reducing the main comments page load is the target -- After posting, the varnish cached page will be invalid, and thus need reloading; To avoid page regeneration per each reply: When the cached page actually gets regenerated could be delayed, and you wouldn't see your post immediately which you would if JS were used. The localstorage object could be used with JS to (re)insert your post inline on the now invalid cached page if you reload it before the page is regenerated (Localstorage is like a client side only cookie that doesn't clutter the HTTP requests).
I use CSS where it makes sense, and JS where it makes sense. For instance I could fill the page with tons of hidden IFRAMEs that contain forms which would allow similar inline posting as JS w/ XMLHTTPRequest (the form replacing itself with the comment after submitting), but that would mean loading a page with those CSS hidden elements would generate a ton of requests back to the server (one for each IFRAME). A more clever CSS3 trick would be to have a single IFRAME post form that repositioned itself to where it was needed, but the problem with that is CSS visibility doesn't affect which form elements are sent to the server so the server wouldn't have a way to discover which post you're replying to -- A couple of lines of JS in an onClick() function could change the hidden postID field's value of that single IFRAME to match the current post you're replying to (and cancel the default action of the "reply to this" action, for graceful degradation), but since you need JS, might as well generate the reply form on the fly too. So, that's why JS is used.
Furthermore, if people knew the annoyances one can create with purely CSS (including content pop-overs), not to mention browser exploits that use only CSS, then they might feel about CSS the same as they do JS. It reminds me of the "anti cookie frenzy", during which I sold solutions with URL munging and/or cache-based tracking and/or server side browser fingerprinting, so the "terrible tracking" tokens were still there even though most fools felt better about disabling the feature we explicitly created to end the insanity of URL munging, etc. The fundamental problem is everyone knows Code is Data, but few realize Data is Code. Even in image data: It's is essentially stored as opcodes for an image codec to "execute" (though conceptually it's in a VM). This is why rendering videos, images or applying web page styles can result in a remote code execution vuln -- Loading a page, applying styles, displaying an image, playing a video is all essentially executing untrusted (op)code on your system. CSS has become so complex it is really no better than JS on the security front (less so, IMO; It's just targeted for exploit less [like the win vs mac vs lin security situation]). CSS is a bit more limited in what it can do than JS (but CSS can do enough to be just as annoying). If more people had JS disabled, most annoyances could easily migrate to CSS (I even prototyped a Great Cannon like attack using HTML & CSS3, so if you can inject HTML or CSS code (or change the style sheet & HTML of a site, say on Wordpress), then you can pull off a similar DDOS as the Chinese Great Cannon [schneier.com] did without actually leveraging a security vulnerability or requiring scripting to be enabled, because style "scripting" (CSS) and hypertext "scripting" (HTML) are enabled).
Yes, disabling JS puts an end to some annoyances, but this is only because the authors of annoyances know most people have JS enabled. Completely eliminate JS from the web, and you'll see plugins emerge that disable CSS features instead. We should do what we can without JS, but when it's needed it's not a big deal to use it. Those that blacklist JS in general should probably whitelist sites like SN which use JS responsibly and aren't purposefully annoying. You do expose more attack surface having JS enabled, but if the SN site is compromised it can serve up malicious images, CSS, or even specially crafted HTML (or sometimes just unicode itself) to run an exploit in your machine. More to the point: Disabling JS for security is just theater; If you're "security conscious" then use a VM for browsing and be done with these damn headaches your security theater causes both yourself and developers who cater to said theater you insist on. I'm not saying there aren't valid non-security reasons for disabling JS, or (most of) CSS when browsing the web.
Now, what I'm actually more interested in doing is porting the reply text validation from the server side Perl into JS so that if JS is enabled the "Preview" button wouldn't have to generate any server side request at all. It would still have to be validated server side, of course, but it would further reduce the server load by avoiding a round trip for preview and any simple errors (like leaving out a subject) or the garbage filter.
(Score: 1) by meustrus on Thursday June 04 2015, @04:14PM
I'm got a lot of JavaScript experience and *everything* I do is designed to degrade gracefully if there's no JavaScript. It's usually my #1 requirement before what the JavaScript is supposed to do, especially since most people don't appreciate the JavaScript isn't always available. How can I get involved?
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 2) by mrcoolbp on Thursday June 04 2015, @04:51PM
Best bet is to jump into IRC [soylentnews.org].
(Score:1^½, Radical)
(Score: 3, Interesting) by bryan on Thursday June 04 2015, @04:40PM
Inline comment replies [pipedot.org] (March 2015) and navigation-less comment moderation [pipedot.org] (March 2014) have been enabled on Pipedot for some time now.
(Score: 2) by mrcoolbp on Thursday June 04 2015, @04:55PM
Your effort in bringing pipedot to life as a one-man-show with many great features is pretty awesome bryan, much respect. I especially like the highlighting of new comments. If I wasn't so busy helping SN I would support pipedot more (I did buy one of your usb sticks and still check in from time to time).
(Score:1^½, Radical)
(Score: 2) by bryan on Thursday June 04 2015, @05:19PM
I can't take all the credit. Pipedot has some really amazing editors (and commenters) that continue to contribute despite the site's small size.
(Score: 2) by GungnirSniper on Thursday June 04 2015, @05:22PM
And you have a mobile site, something that I don't believe Rehash has.
Tips for better submissions to help our site grow. [soylentnews.org]
(Score: 0) by Anonymous Coward on Friday June 05 2015, @06:48AM
Separate mobile sites are bad. A site should work on both from the same URL. All to often Wikipedia links go to the mobile version which just isn't good for my desktop. I'm sure many mobile users feel the same about links to the desktop version.
The link should lead to the content, and the version should be decided by the web browser depending on the system accessing it (and possibly user preferences to allow overriding the default decision).
(Score: 0) by Anonymous Coward on Friday June 05 2015, @08:44AM
I of course meant "web server" here …