Is there a way to select an element by TWO input criteria with CSS?

Hey guys! So I need to select what elements to display within a container in my custom character sheet using two input criteria. The HTML is dummied up below... <input type='hidden' value="" name="attr_veRegion" class="sheet-veregchk"> <input type='hidden' value="" name="attr_vItmLoc01" class="sheet-velocchk"> <div class="sheet-div1">Some content</div> <div class="sheet-div2">Some different content</div> <div class="sheet-div3">Blah Blah</div> <div class="sheet-div4">Four score and seven years ago...</div> What I need is to select by a combination of these two hidden input criteria in a manner lamely demonstrated by bad pseudo code below.  /* Conceal the items at start */ .sheet-div1,.sheet-div2,.sheet-div3,.sheet-div4{ display:none; } /* The Reveal */ .sheet-veregchk[value="5"] as well as .sheet-velocchk[value*="Superstructure"] then ~ .sheet-div1{ display:block; } Anyone with better knowledge of tweaking CSS have any ideas? Thanks in advance for your help! Michael

I haven't tried this, but you should be able to do something like: .sheet-veregchk[value="5"] + .sheet-velocchk[value*="Superstructure"] ~ .sheet-div1 { display:block; }

I normally bypass this issue by having a sheet worker construct the value of a single attribute, and just use that single attribute.

Finderski has the direct answer to your question. But, really the better solutions are to: Use GiGs suggestion Use the Roll20 JQuery implementation and show/hide these with the toggling of a class on the item. #2 is my new preferred method, and looks something like this: HTML <input type='checkbox' value="1" name="attr_veRegion" class="sheet-veregchk"><!--Made these checkboxes for demonstration purposes only --> <input type='checkbox' value="1" name="attr_vItmLoc01" class="sheet-velocchk"><!--Made these checkboxes for demonstration purposes only --> <div class="sheet-div1 conditional-display--type conditional-display">Some content</div> <div class="sheet-div2 conditional-display--type conditional-display">Some different content</div> <div class="sheet-div3 conditional-display--type conditional-display">Blah Blah</div> <div class="sheet-div4 conditional-display--type conditional-display">Four score and seven years ago...</div> CSS .conditional-display:not(.conditional-display--active){ display:none; } You then have a sheetworker to trigger the toggling of the class: //We use a sheet:opened listener as well so that this styling gets applied at sheet load as well. on('sheet:opened change:veRegion change:vItmLoc01',()=>{//Not using the event obect, cause we don't need it for this getAttrs(['veregion','vitmloc01'],(attributes)=>{ $('.conditional-display--type').removeClass('conditional-display--active');//I'm using the conditional-display--type class to specify which conditional displays we want to affect with this change. if(!+attributes.veRegion && !+attributes.vItmLoc01){ // If both unchecked, display div1 $('.conditional-display--type.sheet-div1').addClass('conditional-display--active'); } if(+attributes.veRegion){ // If veRegion checked, display div2 $('.conditional-display--type.sheet-div2').addClass('conditional-display--active'); } if(+attributes.vItmLoc01){ // If vItmLoc01 checked, display div3 $('.conditional-display--type.sheet-div3').addClass('conditional-display--active'); } if(+attributes.veRegion && +attributes.vItmLoc01){ // If both checked, display div4 $('.conditional-display--type.sheet-div4').addClass('conditional-display--active'); } }); }) The logic I put in that sheetworker is just placeholder to demonstrate the technique. I prefer this technique for several reasons: It makes our CSS much less complicated It prevents our CSS from bloating explosively as we add more and more conditionally displayed areas. It gets the logic out of our CSS, and into the JS where it belongs. EDIT: This does have some differences from option #1. Notably, the display change is client side only, and will not affect what other users of the sheet see until they close the sheet and reopen it. Depending on what you are developing this can be a feature (e.g. the player is no longer yanked all over the sheet's sub sheets when a gm goes looking through their sheet) or a bug (e.g. this is a party owned vehicle sheet and everyone needs to see the new layout) EDIT2: Fixed using camelCase in the sheetworker listener. This is one of the primary arguments for using snake_case or kebab-case for attribute names instead of camelCase.

Thanks, everyone, for your input. I'm going to try some of these out! You guys are awesome! @Finderski  , nice! I will try that. Didn't know the "+" sign operated like that. (my CSS skills are weak sauce) @Scott C . , I like your implementation. I think I'll try that as well and see which works smoother. But regarding bloat, doesn't it cause bloat either way? My sheetworker bloat is pretty heavy with this sheet, so in this case I was looking for a CSS solution. But you have a point about CSS not being the place for logic (though, actually, I kind of wish this weren't true. God how I'd love some "if" and "else," or even a "<" and ">" in there at times! lol). @GiGs  , you are, of course, right. That would have probably been the better way to handle it. You are wise. I am starting to picture you as the all knowing Budda of Roll20! :D  Thanks for the wisdom. My implementations are usually klunky and poorly thought out, while yours  (and Scott's apparently!) are typically elegant. Finderski said: I haven't tried this, but you should be able to do something like: .sheet-veregchk[value="5"] + .sheet-velocchk[value*="Superstructure"] ~ .sheet-div1 { display:block; }

I am flattered by that view (I don't know about all-knowing - Scott definitely knows more than me!). Regarding sheet worker bloat: this is not something to worry about. I generally emphasise reducing bloat in my sheet workers, but this is purely an aesthetic decision (and I increase it for clarity in some cases too). The main thing to be wary of is any functions that only work by contacting mechines outside your own - which mainly means getAttrs, setAtts, and getSectionIDs. The async functions are async because they have to contact roll20's servers and then wait for a response. Too many of those functions can cause lag. Everything else is dependent on the power of your own machine, and in practice, you cannot really overload that with character sheet code. The takeaway is: write code that works for you, and it does not matter how bloated or inefficent it is. Just keep those async functions to a minimum where possible.

Seconding everything GiGs said about what sheetworker bloat to be worried about. You can also  streamline the jquery application sheetworker through clear and consistent naming schemes and combining it with GiGs' suggestion of a single view controller input to store the sections that should currently be visible. How exactly that works depends a great deal on how you've set up the basic infrastructure of your sheet. EDIT: And something to think about, it's actually easier to cause performance issues with bloated CSS than it is with bloated sheetworkers.

I did not know that. Thanks for the info. I always thought CSS had a pretty fast implementation since it’s handled by your local browser. Food for thought. Thanks again guys! And GiGs, I know you’ve always been down on multiple entries for SetAttr, advocating combining them instead. Now I know why. When possible, I try to do that. I’ll be even more stringent in that regard now that I have the logic behind it. GiGs said: “… which mainly means getAttrs, setAtts, and getSectionIDs. The async functions are async because they have to contact roll20's servers and then wait for a response. Too many of those functions can cause lag. ” Scott C. said: “… something to think about, it's actually easier to cause performance issues with bloated CSS than it is with bloated sheetworkers.”

Michael P. said: @Finderski  , nice! I will try that. Didn't know the "+" sign operated like that. (my CSS skills are weak sauce) It works in this case, because the two inputs are right next to each other. If they were not, the CSS would need to be slightly different...just wanted to clarify that, because + does mean AND in the way described in your original post.  It simply means right next two.  But you can string multiple things together...

Yeah. I looked up the spec on "+" for CSS when you suggested that, and I realized it was just fortuitous in this case. But thanks for the heads up! Finderski said: Michael P. said: @Finderski  , nice! I will try that. Didn't know the "+" sign operated like that. (my CSS skills are weak sauce) It works in this case, because the two inputs are right next to each other. If they were not, the CSS would need to be slightly different...just wanted to clarify that, because + does mean AND in the way described in your original post.  It simply means right next two.  But you can string multiple things together...