Get ids of checked checkboxes

I figured out how to show them as an alert, but I would like to list them below the checkboxes:

http://jsfiddle.net/UqrYJ/203/

<input type="checkbox" id="1"> <label>First</label><br>
<input type="checkbox" id="2"> <label>Second</label><br>
<input type="checkbox" id="3"> <label>Third</label><br>
<input type="checkbox" id="4"> <label>Forth</label>

Code (markup):

$("input:checkbox").change(function() {
    var someObj = {};
    someObj.showid = [];
    $("input:checkbox").each(function() {
        if ($(this).is(":checked")) {
            someObj.showid.push($(this).attr("id"));
        }
    });
    alert(someObj.showid);
});

Code (markup):

 

Close but can it be done as:
You clicked 1
You clicked 1 2
You clicked 1 2 3
or You clicked 1 4 2
etc. etc?

Sorta show them as a list rather than replacing one id with the other.

 

Wow. That's exactly what I needed.

 

1) ID's can't start with numbers. First character must be alpha... so that's invalid gibberish markup.

2) wouldn't it be more effective to pull it's VALUE?

3) Assuming all those checkboxes are in their own fieldset (which they likely should), wouldn't it be easier to kick that jquery BS to the curb?

<form method="get">
	<fieldset id="selections">
		<input type="checkbox" name="firstValue" value="1">
		<label>First</label><br>
		<input type="checkbox" name="secondValue" value="2" checked>
		<label>Second</label><br>
		<input type="checkbox" name="thirdValue" value="3">
		<label>Third</label><br>
		<input type="checkbox" name="fourthValue" value="4">
		<label>Forth</label>
		<div>You Selected: <span id="selectionsResults"></span></div>
	</fieldset>
</form>

Code (markup):

Gimme a few to get over to the workstation and I'll upload a working demo. Should only be a handful of lines of JS not counting the comments. (and I'll comment the **** out of it)

 

Ok, is this what you were thinking?

http://www.cutcodedown.com/for_others/qwikad/selections/template.html

as with all my examples the directory:
http://www.cutcodedown.com/for_others/qwikad/selections/

is wide open for easy access to the gooey bits and pieces. I put a commented and uncommented version in there. Without comments it's only 3 bytes over 1k, and that's WITH a small function library to do the DOM stuff and attach events. (again you need more than 16k of 'library' you're doing something wrong... yes jQuery, go put on the dunce hat and sit in the corner).

I made one of the elements start out selected to test that the script can pick that up. IDEALLY that should also be being set server-side and/or perhaps if it's scripting only functionality, the display element be added by the script.

Really this is a STUNNING example of how jQuery prevents people from learning how to do a blasted thing properly and just blindly trust something that has NO business being trusted.

It's like REALLY, is getElementsByTagName and "for i<length" REALLY so blasted hard people?!? Sure as shine-ola easier to understand than the uselessly vague daisy chaining asshattery of jQ.

WHY do people use that crap? Is it just ignorance?

In any case you go through the commented version:
http://www.cutcodedown.com/for_others/qwikad/selections/library.commented.js

Pretty simple. Helper lib. Pull the "document.get" ahead of time to save time later, create a function to poll the inputs in that fieldset and populate the span, attach onchange/onclick to the inputs dynamically, then call that polling function once to check if we started with any marked off. Since it's loaded right before </body> the DOM is already built, so we don't even need to dick around with domDocumentReady or onload.

A more robust version would likely attach itself by class instead of ID so you could have multiple instances, creating the message div itself and attaching the span as a property of the fieldset, so the event handler could do event.target.parentNode to pull where to plug in the changes as well as the list of inputs... Be more portable that way and again, let you do it multiple times per page instead of hardcoded for one page and one set of ID's.

 

Just tossed together that more advanced version, no commentation as yet, just a proof of concept for using a class on a fieldset as the trigger, with the DIV and SPAN generated by the script.

http://www.cutcodedown.com/for_others/qwikad/selections/advanced/template.html

As before:
http://www.cutcodedown.com/for_others/qwikad/selections/advanced/

open for easy access. Added some more lib functions but it still only grew to 2.3k in size... which is pretty svelt given what it's doing.

I could do it in a lot less code by dropping some legacy support, but as written this SHOULD work all the way back to IE 5.x so...

Went with three fieldsets to show off the multi-fieldset support, two in the same form, one in a separate form -- each working independently off the same codebase so, hey, good thing.

 

@deathshadow Super!!! So much to choose from now.

As I was playing with it I realized that all those values disappear once the page is refreshed. I tried to add local storage:

$(":checkbox").on("click", function () {
    localStorage.setItem($(this).attr("id"), $(this).prop("checked"));
});
$(":checkbox").each(function () {
    var status = localStorage.getItem($(this).attr("id"));
    $(this).prop("checked", status === "true" ? true : false);
});

Code (markup):

And although the boxes stay checked on refresh, the values go to "You Selected: nothing". Is there a way to keep showing the selected values even if the page is refreshed?

And lastly can you also add an unselect all checkboxes link or button? I will probably have 50 boxes showing at any given time, so it would be handy to have that option.

I like this demo http://www.cutcodedown.com/for_others/qwikad/selections/template.html as "You selected" option shows within the div rather than within the javascript which can be useful for me.

 

Well, in terms of persistence page refresh isn't really something that you should do (be warned FF will do it and no other browsers will) -- it's a form, what matters is persistence when it's SUBMITTED to a server. You use form elements, that's what they are usually for. That said, you COULD store their current state in the cookies. or localstorage if you want consistent over refreshes. The other option would be to update the values on the server with ajax when there's a change, so that when a refresh is done the server has those values already.

Hmm.... This AND your other thread with the massive cookies for storing the history would REALLY benefit from localstorage. I'm a bit busy today, but if I have time tonight (my non-24 makes when I'm available/awake all sorts of fun, particularly with my new meds COMPLETELY screwing it up more) I'll see about setting up localstorage functionality on both of those.

Localstorage is nice because it's NOT sent to the server and sent back with the headers for EVERY single blasted file request on the domain. In the case of your other thread, localstorage is easier to work with too as there's less sanitation/escaping of values to deal with.

... oh and a mass deselect is easy, though the number of "changes" that would trip could send some browsers off to "scripting neverland" -- so a flag to say "only update once" might be in order.

... and that "advanced" version actually makes the same elements on the DOM -- the DIV and SPAN just like the normal one are there, it's just GENERATED by the script. It's usually good practice to have things that only work scripting on be made in the scripting, NOT the markup -- since without scripting they serve no real purpose. That's why as form elements you double-check on submit server-side since if you can't make it at least functional without scripting FIRST, you probably shouldn't have scripting on it.

Though there ARE exceptions to that rule -- scripted games, some admin interfaces, and of course web apps operate under slightly different rules. Really it comes down to what type of website or web application this is going into as to what's the best approach. REALLY if this is for a "normal" website, I wouldn't be doing any of this.

 

I need this to store favorite ads. Someone adds a bunch of ads to favorites by checking the checkboxes. The results are stored within <span id="selectionsResults"></span> until that user decides to unselect them. That's why I need an unselect all option and the values to keep showing when the page is refreshed.

Whenever you can, I'd really appreciate you figuring this out for me.

PS Are you usually awake at like 2-3 am? It was like 2 am this morning when I was awake for some reason.

 

Actually I was half right. That local storage does keep the values showing. Ha. Didn't in the test drive. So that's off the table.

So, what I need is a de-select all option.

Oh, and lastly. How do I make the result show as an html output? I tried: nodeReplace = document.write(output, result.length ? result.join(', ') : 'nothing'); but it's crewing me all over the place. What am I supposed to do there? Wasn't sure how to use innerHTML in this case either.

 

Be warned even in supported browsers, sometimes localStorage will just flat out refuse to run or work. It's STILL not a perfect solution and a fallback plan should be a must-have. That means cookies or storing it on the server.

Select all should go on the list too.

You don't. You're working in JavaScript which in all but the rarest of cases means you have little business using innerHTML, and NO business EVER using document.write. Both are outdated methdologies for adding stuff to a page client side. EVERY time you use either of those (with a possible workaround for innerHTML by creating a dummy element) you are forcing the browser to reparse the ENTIRE markup and rebuild the DOM from scratch. This can in older browsers accidentally remove attached methods, it takes longer, and it can open the door to XSS exploits unless you are DAMNED careful sanitizing what you're outputting. WORST OF ALL, if you call document.write on an event after the page has finished loading, IT WILL ERASE THE ENTIRE DOCUMENT AND CREATE A NEW ONE.

Check it: (normally I would NOT write a script this way, but it's a demo)

<!DOCTYPE html><html lang="en"><head><meta charset="utf-8">
<title>Document.write is STUPID</title>
<script>function test() { document.write('Haha, your content is gone'); }
</head><body onload="test();">
<h1><code>document.write</code> is STUPID!</h1>
<p>
  When this document finishes loading, we call <code>document.write</code> and it will erase the ENTIRE document to replace it with the new text. <code>document.write</code> should ONLY be used during page load and not AFTER. This is another strike against using it entirely on top of it hanging all asset loading (scripts, style), DOM parsing, and forcing a reflow of the document from top to bottom.
</p>
</body></html>

Code (markup):

Generally speaking, much like putting SCRIPT in the head or STYLE in the HTML, don't use document.write -- you're just hanging the page load, opening possible security holes depending on what you're writing, and sucking down extra CPU time for no good reason. Worse you CANNOT use it once the HTML has finished loading as it will erase the entire document. There is only ONE remaining real-world purpose it serves, and that's dynamically loading a script at load-time -- and generally speaking if you need to do that, you're probably doing something wrong.

InnerHTML is equally flawed though the issues are slightly different as it is at least "non-blocking",and there are workarounds to use it. I still won't use it unless I REALLY have to because markup in the scripting is just as big a steaming pile of rubbish as putting the various "onevent" attributes in the markup. (something ELSE I highly advise against using). The ONLY time I do use it is when doing a AJAX load of something like help instructions for a script -- and if I do that I created a dummy element like a DIV with document.createElement, then plug the innerHTML into that DIV. The Parser will run on that DIV and not the page, then once that's done I append that DIV to the page with appendChild.

That's gibberish, nodeReplace is a FUNCTION, not a variable. You don't assign a value to it.

See, when HTML is parsed by the browser for rendering the elements in it are added to what's called the "DOM" -- Document Object Model. The DOM is what functions like getElementById and getElementsByTagName works on. You should NOT be forcing the browser back to the parser just to add elements to the document. WORSE, when you use it the DOM is written BACK into being markup so that's even ANOTHER slow step.

Let's say we had a DIV with the id of "test".

<div id="test"></div>

... and we wanted to add a paragraph to that. First you need the element:

var test = document.getElementById('test');

If you were working 1990's style innerHTML would work thus:

test.innerHTML = '<p>This is a test</p>';

.... while that's simple and easy, it's also slow. It's why ~98% of the time you see that in JavaScript (like the idiotic asshat bullshit known as jQuery) the code is inept rubbish that should be pitched in the trash.

The DOM is a bit more complex, but it works WAY faster since we bypass the parser and just add our stuff directly to what the browser is using to draw the page.

First, we need to empty out all child nodes of the element. Easiest way to do that is to simply loop while the element has a firstChild, removing said child elements.

while (test.firstChild) test.removeChild(test.firstChild);

If you dig into my library, you see I have a nodeFlush function that does this.

	function nodeFlush(e) {
		while (e.firstChild) e.removeChild(e.firstChild);
	}

Code (markup):

We then want to add the new node. First we have to create the paragraph:

var p = document.createElement('p');

Then we need to add the text to that element. Text has it's own "node type" called a "textNode", hence:

p.appendChild(document.createTextNode('This is a test'));

Basically that creates the new text node, and appends it as a child of paragraph created by P.

THEN we need to add that new paragraph to the markup. This too takes "appendChild"

test.appendChild(p);

TECHNICALLY we could append the P before we add it's content, works in either order.

If you dig into my functions, you'll find a nodeAdd method"

	function nodeAdd(e, node) {
		e.appendChild(typeof node == 'object' ? node : d.createTextNode(node));
	}

Code (markup):

This does a handy trick of checking if the node we are adding is an object. If it is, that object is added directly. If not, we assume it's text and add it with createTextNode. (I use the "d" trick in a self executing function to pass document, it's faster as it makes it local scope and it's less code. Win/win. Learned that trick from some scripts Google uses.)

The nodeReplace function simply wraps those two. It flushes the element, then adds our node as the new child.

	function nodeReplace(e, node) {
		nodeFlush(e);
		nodeAdd(e, node);
	}

Code (markup):

Finally I also use a helper function called "make" -- the version I have here is the "simple" version which doesn't do full attribute support since I rarely need it. attachEvent or simply using the onevent method after creation is usually sufficient for event handles, and I rarely if EVER declare style from my scripting since that's CSS' job, not JavaScript's. (there ARE exceptions to that -- progress bars for example where width is conveying meaning)

	function make(selector, parent, content, attributes) {
		var
			s = splitSelector(selector),
			e = d.createElement(s.tag);
		if (s.id) e.id = s.id;
		if (s.classes) e.className = s.classes;
		if (parent) parent.appendChild(e);
		if (content) e.appendChild(
			typeof content == "object" ? content : d.createTextNode(content)
		);
		if (attributes) for (attr in attributes) e.setAttribute(attr, attributes[attr]);
		return e;
	}

Code (markup):

splitSelector just breaks a selector into an object of {tag, id, classes}. If no tag is declared it defaults to a DIV.

As above, we use it to createElement using a tag, then we add the ID if the ID is set, the class if the class is set, if the "parent" is set we append this new element to that parent tag, if the content is set we assign that content, then we iterate the attributes object (if set) to set those attributes. Finally it returns a handle to the new element. If you dont want a parameter to run you can either pass false, or omit it if it's at the end.

So, if we were to try and add a paragraph to #test using these methods:

nodeReplace(test, make('p', false, 'This is a test'));

Which, despite all the helper functions / library stuff, is STILL faster than innerHTML and less disruptive to how the page works... and the bigger the page and more DOM elements the page has, the more true that is. There's a reason the number of elements on a page is also working it's way into various page speed and optimization tools, and even some search engines have started penalizing pages with too many elements. Too many elements == slower scripting functions; a page with two or three hundred DOM elements can take as long to do a getElementsByClassName -- or worse jQuery's idiotic $('.something') -- as it does for a less bloated website to even load all it's assets.

Again, just because something looks simpler or easier, and you see all sorts of people doing it -- that doesn't make it good practice, or something you should be doing in your scripts. Generally speaking a LOT of people sleazing out JS these days don't know the first damned thing about JavaScript much less HTML or CSS, so they are not just writing crappy bloated scripts, they're opening security holes and aren't qualified to even know if something like jQuery is pointless trash or not, or even when to and when NOT to use scripting.

... and in MOST cases, the answer is NOT to.

Now that said, (I'm sure you'll need more clarification on that, moving to DOM from 'sleaze markup into the page' is a big jump -- time for the big boy pants) before I dive into making more changes I kind of have to ask, what's the real world usage scenario for this? I'm just not getting it.

Why would ANYONE want to load a page filled with 50 or so adverts and checkboxes, where their selection ONLY effects that site, ONLY works on the pages that have the checkboxes, and ONLY works on the browser and machine they happen to be seated in front of? I'm just not seeing how this would EVER provide ANYTHING resembling useful functionality or even a page people would visit in the first place. LocalStorage only works (when it decides to work, which is to say Chrome, Edge and **** everyone else) in that one browser on that one machine on that one site. They switch browser, they switch machine, that data doesn't exist. It's why this type of stuff usually is NOT stored client-side.

Can you better explain the "end game" of this page, because I'm REALLY getting the feeling this is treading into "Why the ***** does this even exist" territory. I'm thinking I'm either not seeing the entire picture, or you're not grasping what "client side" means and all that it entails.

Basically, what's the POINT of all this? I'm not seeing it.

 

Oops, almost forgot:

I have non-24 sleep wake syndrome, to the tune of NORMALLY maintaining a 26 hour day. (well, 25 hours and 56 minutes by the sleep study)
https://en.wikipedia.org/wiki/Non-24-hour_sleep–wake_disorder

As such I typically sleep an hour longer and am awake an hour longer. I've had this my whole life but only got diagnosed a few years ago, it's why I'd have good weeks where I could get endless work done, and bad weeks where I was having borderline narcolepsy and was NOT the most pleasant person to be around since every 8 days I effectively had the symtomology of jet-lag when trying to maintain a 24 hour schedule.

Sadly, even the adjusted schedule that's been keeping me far more friendly and functional (can't you tell?) has been throws awry by some new medications to help deal with the fact I am enduring constant painful headaches, that can be so bad I wake up at what would be my 3 in the morning (which could be any hour of the day) screaming loud enough to wake the neighbors three houses down. We're trying 20mg of Amitriptyline at bedtime to try and act as a preventative pain reliever, and when I wake up with the bad ones I can take a nice 50mg Sumatriptan.

Sumatriptan is fun since I've had the prescription for two weeks, you can only get 9 pills (@50 each is 450mg) a month as it's a restricted substance, and I've already had one of the more fun side effects -- Sulfhemoglobinemia. Big long fancy word for "blackish green blood" -- a fun surprise when also a type 1 diabetic and you go to test the next morning. Jab myself with the lancet, look down and it's like "Wow, I'm either Vulcan, a Darkspawn, or dying" -- turned out to be none of the above and just a normal side effect... That I should NOT be having with so low a dose.

They offered me oxycodone to help with the pain too, but I don't like to go there. Hate how those make me feel even if they kill the pain. Laugh is I was taking something similar as a child as I had these as a pre-teen but they went away in adolescence. After my nice little week long hospital stay back in February thanks to a nice big seizure and black-out episodes that followed, the headaches I'd not felt in 30 years were back. NOT a happy camper.

Oh did we mention the as yet undiagnosed siezure disorder and medication induced parkinsonism? Thankfully 1500mg of Keppra a day is holding that at bay.

On top of that, doctors and other offices I have to deal with aren't exactly on my schedule... Picture every other week having to get up at 2AM to go be poked and prodded... That's me at 3 in the afternoon twice a week.

In any case, when I'm going to be awake this coming week? YOUR GUESS IS AS GOOD AS MINE! On forum software like SMF that have charts based on posting time mine is good for a laugh as it's pretty flat straight across.

Sorry for the life medical history (actually that's about a THIRD of it), but hey... you asked...

 

Wow, with all that medical history, it's no wonder you sometimes come across as a bull in a china shop. Feel sorry for you man. Glad you're functioning the way you are. Very sharp and stuff.

 

@deathshadow Your points are all valid and I don't quite know myself whether or not it's going to work the way I want it to work, BUT I still want to give it a try. For that reason I am only asking you to help me with this one thing. Will you consider editing this script http://www.cutcodedown.com/for_others/qwikad/selections/template.html to make the output show as HTML? The checkbox values will have tags similar to: value="<a href='<?php echo $url; ?>'><?php echo $row['adid']; ?></a>" and so it's paramount for me to have an HTML output. Thanks!!

 

Uhm, silly question, is this "HTML" actually supposed to be HTML as in parsed by the browser, or something the user could copy/paste from?

I would NEVER put it into the markup as "HTML" and there's NO legitimate reason to. There is NO usage scenario at ALL where ANY benefits exist on doing write or innerHTML vs. DOM manipulation so that insistance makes ZERO sense.

Unless you were trying to do something like populate a textarea with markup so the user could copy/paste from it.

Other than that usage case, I don't get why that would be so "paramount" a thing to have.

Not sure what you mean by "the checkbox values will have" since they can't have markup in them (well, unless you escape it)... or more than one value unless you add some escaping/parsing to it. Really I'd not be wasting bandwidth making huge 'values' that have markup in them, I'd be passing just the URL and whatever the content of that URL would be either as JSON directly to the script off an index in the value, or escaped with delimiters in the value. You want "markup" elements like anchors or images, build them on the dom from the scripting.

An actual sample of the data (instead of the PHP and some variables with vague names that mean nothing to me) could help clarify things.

 

OK, without confusing you even more and without you trying to explain to me that I am dumb and know nothing about any of this (I know that!!) can you JUST make the script do an HTML output? I know it's easy and possible (especially since it's your script).

Again, the thing is I may not even use that script in the given scenario. I was just trying to explain in different ways what I was trying to accomplish. Can you, please?

 

Just as an example of what I mean, assuming this was to be anchors wrapping images (you mentioned it's adverts so...) would passing it as:

echo 'value="', rawurlencode($url), ':', rawurlencode($imageUrl), ':', rawencode($imageAlt), '"';

Code (markup):

Be viable on the server side? Then the method for adding them to the markup would be:

function checkInputs() {
	nodeFlush(output);
	for (var i = 0; i < inputs.length; i++) {
		var parts = inputs[i].value.split(':');
		make('a', output, make('img', false, false, {
			src : decodeURIComponent(parts[1]),
			alt : decodeURIComponent(parts[2])
		}), { href : decodeURIComponent(parts[0]) });
	}
}

Code (markup):

Untested, but theoretically sound. If they'd all be getting the same basic markup, that's how it should be done. REALLY "markup" for something like this shouldn't be stored in the database, which is why the content of those $row values is... troubling.