Help with Box Selector

I've been working on a box selector and I'm stuck. I would like the box to turn red if you click on a box and 10 have already been selected, then display the message "You have already selected 10", then fade that away back to the text that was in the box. I would also like to be able to uncheck already selected boxes after this message comes up in case someone wants to pick a different option. At this point, the box just disappears but I want all their options to stay.

Could someone help me?

https://jsfiddle.net/pizzastick/gqr655sc/2/

 

Here's a working example (at least I think it's what you wanted): https://jsfiddle.net/gqr655sc/7/

 

That's perfect thank you!! If I have text in each box though say "Box 11", pulled from a database, once the "You've already selected 10" comes up, how do I make it revert back to "Box 11". Sorry I should have put text in there, but that is exactly what I was looking for!

Thanks so much!

 

You don't really need to with my solution, since the existing text in the box will still be there (what it does is it drops a new div-container above the box already there, and removing it again) - so anything already present in the box in the HTML-code should still be there.

 

Hmmm. Thank you! Maybe it's the way I'm displaying the text, but once I click on it and it displays "You've already selected 10" it fades back to normal color and the box is empty. I'll keep trying though! Thanks

 

Sorry, my bad. I was just thinking wrong - here's a new example, doing what you asked: https://jsfiddle.net/gqr655sc/9/

 

That's exactly it. Wow thank you so much. Great help

 

Honestly, that approach is SO full of holes and issues I pity anyone who would piss on a website with it. Why do I say this?

Graceful degradation and accessibility -- or more specifically the utter and complete lack of it!

The VERY first thing I'd do is make it so that what you have there is a FORM since the ONLY legitimate reason to be chosing boxes should be to send those choices somewhere -- and you aren't going to do that with DIV. Those should be input[checkbox] and LABELS! That same way their submit handler server-side should recheck the number and return it to the client if it exceeds ten -- that way when scripting is disabled/blocked/told to go *** itself by the user, your page will still be useful. The scripting would then hook the input's onchange event (with the stupid blur/focus fix for IE8/earlier) -- in legacy browsers I'd just let the checkboxes show, in modern browsers I'd hide the inputs, use the :checked psuedoclass and let the natural mechanism of a LABEL with a for attribute change the input as appropriate. While I normally dislike them, this is a scenario where I'd use the data- attributes to pass how many they are, so the script can be generic instead of hard-coded to the page should you want to re-use it or have multiple fieldsets performing the same way.

<form method="get" action="#">

	<fieldset class="checkLimit" data-checkLimit="10">
	
		<h2>Select only 10 items</h2>
		
		<input type="checkbox" name="item[]" id="item0" value="0">
		<label for="item0">Describe this</label>
		<br>
		<input type="checkbox" name="item[]" id="item1" value="1">
		<label for="item1">Describe this</label>
		<br>
		<input type="checkbox" name="item[]" id="item2" value="3">
		<label for="item2">Describe this</label>
		<br>
		<input type="checkbox" name="item[]" id="item3" value="3">
		<label for="item3">Describe this</label>
		<br>
		<input type="checkbox" name="item[]" id="item4" value="4">
		<label for="item4">Describe this</label>
		<br>
		<input type="checkbox" name="item[]" id="item5" value="5">
		<label for="item5">Describe this</label>
		<br>
		<input type="checkbox" name="item[]" id="item6" value="6">
		<label for="item6">Describe this</label>
		<br>
		<input type="checkbox" name="item[]" id="item7" value="7">
		<label for="item7">Describe this</label>
		<br>
		<input type="checkbox" name="item[]" id="item8" value="8">
		<label for="item8">Describe this</label>
		<br>
		<input type="checkbox" name="item[]" id="item9" value="9">
		<label for="item9">Describe this</label>
		<br>
		<input type="checkbox" name="item[]" id="item10" value="10">
		<label for="item10">Describe this</label>
		<br>
		<input type="checkbox" name="item[]" id="item11" value="11">
		<label for="item11">Describe this</label>
		
	</fieldset>
	
	<div class="submitsAndHiddens">
		<input type="submit" value="Order">
	</div>
	
</form>

Code (markup):

Would be the semantically correct markup for that -- something that should have been made and working both client and server side LONG before you even THOUGHT about throwing scripttardery at it!

Again, the unwritten rule of JavaScript: "If you can't make the page work without JavaScript FIRST, you likely have no business adding scripting to it!

Server side it would be easy to check how many from that output by the very nature of [] names and checkboxes -- checkboxes that aren't selected don't send their value server-side, and [] are turned into arrays, so you can just pull count($_POST['item']) to see how many there are.

Gimme a few minutes and I'll belt together the CSS, and then the JS for handling that. The "count" would be added by the scripting since it's non-functional scripting off. Good rule of thumb: if it's scripting only it has NO business in the markup! See why HTML 5 having CANVAS and PROGRESS tags is jacktarded BS as are all the stupid empty DIV for things like lightbox people piss on their HTML with -- same goes for those idioitic "onclick" or "onsubmit" type attributes that honestly should have been made obsolete a decade ago.

 

... and this is how I'd go about it:
http://www.cutcodedown.com/for_others/pizzaStick/template.html

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

is wide open for access to the gooey bits.

Modern browsers with JS disabled the fancy styling will still work AND you can submit the data server-side for processing and/or access it like it was a normal form. (which should be the point of this I'd think...). Older browsers get normal checkboxes and labels scripting or no. Scripting and modern you get all the bells and whistles. Keyboard accessible (something you'd waste endless time getting to work with DIV, assuming you even could), gracefully degrading, blah, blah, blah...

In the CSS
http://www.cutcodedown.com/for_others/pizzaStick/screen.css

I put the 'modern' styling in a media query so as to only target CSS3 capable browsers. Seemed like a smart move. Set the label cursor to the hand/pointer so users know it does something, and like PoPSiCle did I added the box-shadow hover state, with position:relative so it will be visible over it's kin. I trigger off the active state which means if you use the mouse the last one clicked on stays selected, that's a 'issue' you can either leave be (big deal) or if it bothers you add a 'mouseout' in the scripting that blurs the checkbox.

I used generated content to make the 'fancy' checkboxes -- looked like you were planning on using images there and you could just as easily place those in that generated element instead of the UTF-8 character and border I used.

In the scripting:
http://www.cutcodedown.com/for_others/pizzaStick/library.js

I put it all in a self-invoking function to isolate it's scope reducing the odds of namespace collisions to near zero, passing document to it as "d" just for shorthand.

Rather than the jQ garbage I just added a few simple common library functions; you need more than 15k of library functions for an entire site you're probably doing something wrong. (you need more than 48k of JS for an ENTIRE website, you probably need to back the **** away from the keyboard)

The event handlers are attached dynamically as is the count, the actual count being tracked in a property added to the fieldset allowing you to have multiple instances of this on one page with the class as the trigger. The span containing the count is also stored as a property of the fieldset so as to speed access, and node-walking is used to access the label and parent fieldsets on the fly.

... and I added that goof-assed blurFocus garbage to make IE8 and earlier actually behave.

You'll notice I push the labels onto an array and shift them off for the time-out, that way if the user is quickly clicking across a bunch they don't conflict. Likewise I save the original label text as a made-up attribute on the label so if the user clicks repeatedly we don't have a conflict. We COULD make a span with the error text in it and absolute position it, but that's a headache better avoided even if it might be prettier.

Or at least, that's how I'd go about it. Again, make it functional/accessible without scripting FIRST, THEN enhance it with the JS... but to be fair that's why I DON'T use jQuery and why I start out with content and functionality as if CSS and JS don't even exist BEFORE I even THINK about playing games with either of them. Again, "If you can't make the page work without JavaScript FIRST, you likely have no business adding scripting to it!" -- which is why some server-side code to back that up would be a 'must-have' in my book as well. Functionality FIRST, appearance SECOND, and scripttardery far, FAR, FAR in the back.

 

Wow this is great thank you very much! I have much to learn I guess. This was my intention to submit it. Thanks for your insight and then also showing me the solution. You were very helpful to me.

 

Hi deathshadow,

Your code really helped me and it's working well! I'm running into one issue where I'd like to display the count outside of the form in a div instead of within the form. Do you know if that's an easy tweak?

 

You can pretty much make a span anywhere like say:

<span id="fieldCount"></span>

Then change this line:

fs.countElement = make('span.fieldCount', header);

to this:

fs.countElement = document.getElementById('fieldCount');

You could also just change the parent element of the 'make' procedure from 'header' to some other element on the page.